mephДобрый день,

я пишу небольшой проект в учебных целях и у меня возник вопрос относительно того, как обычно поступают камрады в боевых условиях.

Структура БД довольно тривиальная, думаю тут все понятно без дополнительных объяснений.

Я привык исходить из того, что БД является фундаментом приложения, и ее не изменяют в угоду удобству. Но мне рекомендуют воспользоваться другим подходом: подстраивать БД под юзер стори.

Например, такая юзер стори: сотруднику в магазине нужно найти где находится товар#1. Запросы на скуле писать не комильфо, нужно использовать средства ORM. Предложение заключается в том, чтобы довавить колонку store_id в таблицу product_location, тогда мы сразу получить store_location_id.

Мне эта идея кажется неправильной, так как мы дублируем store_id. Подскажите, удобство все-таки решает, и БД должна опираться на юзер стори в первую очередь или сначала 3 НФ, а потом все остальное?

Вы бы хоть код классов привели помимо картинки со структурой БД.

Интересуют не размышления в теории, а как этот вопрос решается на боевых проектах.



В боевых проектах нарушается даже 1НФ.

Подходов к проектированию, по большому счету, 2:
1) DB first - это то как вы привыкли: сначала БД, потом все остальное.
2) Model first - это то как вам посоветовали (ORM подход): сначала модель, а как сохранять - вопрос вторичный.

веселье начинается когда нам надо получить обратно все что мы там насохраняли)))

авторМне эта идея кажется неправильной, так как мы дублируем store_id.
Правильно кажется) Вносить избыточность конечно можно и так делается сплошь и рядом, только надо 100 раз подумать и отдавать полный отчет себе в том, зачем это сделано.

авторЗапросы на скуле писать не комильфо, нужно использовать средства ORM.
Native SQL queries - вполне себе средства ORM. HQL в конце концов есть. Не надо прятаться от реляционной структуры данных, тем более если вам она ближе.

На  HQL примерно как-то так:

mad_nazgulmephЯ привык исходить из того, что БД является фундаментом приложения, и ее не изменяют в угоду удобству. Но мне рекомендуют воспользоваться другим подходом: подстраивать БД под юзер стори.

Вот поэтому я всегда говорю "ORM - зло!"
Если мы храним данные в СУРБД, то данные должны хранится по реляционным правилам.
А вот "юзер стори" должны хранится в объектах сервера приложений и потом сохранятся в БД.
В этом ORM не помогают, а только мешают.
Т.о. как только идет конфликт м/у "юзер стори" и СУРБД, то выкидываем ORM и пишем запросы и код, которые делают преобразование из одного в другое.

Че так радикально-то?)) Ну да, когда надо посложнее, то все ручками на SQL/HQL и вся магия ORM испаряется. ORM - для CRUD рутины и с этой задачей вполне справляется.

Новичок ООП.dimonz80В боевых проектах нарушается даже 1НФТы ври да не завирайся.

Верить тебя никто не заставляет. Не видел такого - ну и хорошо. Нервы целее будут)