Добрый день всем! Интересует мнение участников сообщества по следующему вопросу.

Допустим у нас есть такие сущности как, "Подукты" (Food), "Блюдо" (Dish), "Меню"(Menu). Соответсвенно связи такие:
- в одном блюде м.б. несколько продуктов, один продукт может использоваться в нескольких блюдах;
- в одном меню м.б. несколько блюд, одно блюдо м.б. в нескольких меню;
Соответсвенно такие таблицы:
FoodFoodID (PK)Name

DishDishID (PK)Name

DishFoodDishID (FK_Dish_DishID1)FoodID (FK_Food_FoodID)

MenuMenuID (PK)Name

MenuDishMenuID (FK_Menu_MenuID)DishID (FK_Dish_DishID2)
Понятно что когда блюдо сформировано из каких-то продуктов и включено в несколько меню, и возникает потребность изменить блюдо (например убрать какой-то продукт), то блюдо изменится во всех меню, куда оно включено. По тому же принципу, если само блюдо исключить из меню (а например само меню тоже м.б. куда-то назначено, например на какие-то столики в ресторане) , то оно исключится у всех столиков.
Это не есть гуд, необходимо чтобы, можно было иметь стандартный набор типовых блюд и меню, но после назначения эти объекты "жили своей жизнью", чтоб их можно было изменять и "кастомизировать" как угодно. Отсуда вытекает потребность в так называемых "Типовых блюдах" и "Типовых меню".
И я плавно выхожу на сам вопрос.
Каким образом, это лучше (правильнее что-ли, или классически) организовать?
Есть два подхода:
1) Дублируем все таблицы например с постфиксом Lib, считаем что там у нас хранятся "типовые" элементы и связи, при назначении элемента, копируем из типовой таблицы в реальную, после этого можно крутить скопированное как хочешь.
2) Чтобы не дублировать таблицы создаем дополнительно поле Type (в таблицах сущностей), и туда записываем значения например R - реальный, T - типовой. Соответсвенно, когда пользователь хочет просмотреть, например, типовые блюда или меню, выбираем записи с типом Т. Если реальное меню или блюдо выбираем записи типа R.

Работать будет и так, и этак, поэтому интересуют разные аспекты реализаций, например:

1. Удобство и наглядность при разработке. В первом случае гораздо удобнее писать и потом понимать код. По опыту знаю, что когда запросы простые и решение кажется стройным, а объекты "почти похожи" и прекрасно нормализуются в одну таблицу, и процедуры и методы общие, то со временем при расширении системы, такие вещи обрастают кучей каких-то проверок условий, появляется высокая сложность и высокая связанность (тронешь тут рухнет там).
2. Масштабируемость, расширяемость - вдруг при расширении у типовых или реальных объектов появятся отличающиеся поля. Удобнее первый способ. А если появятся дополнительные характеристики и там и там, в одну таблицу внесешь в другую забудешь - тогда удобнее второй.
3. Быстродействие - например, если будет много записей, как реальных, так и типовых (допустим порядка 500.000), то удобнее когда они разделены, ведь зачем выполнять тот же поиск по лишним данным, когда можно четко определить в какой таблице нужно искать. Будет быстрее.
4. Избыточность в схеме данных - зачем плодить много таблиц, когда объекты отличаются только типом? Да и держать больше таблиц в голове при разработке - повышает сложность.

В общем выбирал-выбирал, думал-думал и решил узнать ваше мнение. М.б. есть стандарные, "классические" подходы или аргументы , чтоб просмотреть весь список аргументов и решить что важнее. А может есть вообще другие подходы...

П.С. Только не говорите что "все зависит от задачи" и "выбирайте что нужно именно в вашем приложении" =) Может просто какие-нибудь мысли на тему....

Cat2
Типовые могут переходить в реальные и наоборот.

Такое в общем-то не нужно...Но даже если будет нужно, так же просто перенести в таблицу типовых из реальных... Все равно простым апдейтом типа с R на Т не обойдешься, потому как, допустим мы в реальном меню, изменили тип блюда на типовое, таким образом у нас в реальном меню получилась ссылка на типовое блюдо, и мы нарушаем "историчность" действий, так если мы в будущем изменим состав типового блюда, он поменяется где-то в прошлых меню куда ранее был включен. В любом случае придется копировать строки разница только из таблицы в саму себя или в другую таблицу...
Cat2
Быстродействии более определяется правильными индексами, а не объемами.
500 000 - это, в общем-то, немного.

Согласен. Это я не конкретные цифры говорю, а в общем. Но допустим у нас есть сеть ресторанов, в кажддом например по 100 столиков на каждый столик по три варианта меню бизнес-ланчей (бл), в каждом бл по три блюда, в каждом по сколько-то наименований продуктов, допустим есть возможность планировать меню, например на три месяца... И если идет активная работа с такой таблицей...то например для вывода списка типовых блюд затратится гораздо меньше времени если они будут в типовой таблице...
Это не голословно говорю, есть схожая реализация системы плниарования работ а-ля ЕРП (цикл-работ - этапы цикла - атрибуты этапа). Вот когда куча циклов, в каждом куча этапов, распланированных на три года вперед, каждый этап ежедневно, а нем еще неколько атрибутов и каждое значение атрибута - список строк, то например простое получение значения атрибута для конкретного этапа занимает определенного цикла, занимает около 10 секунд (БД MS SQL, и индексы там впорядке и запросы уж оптимизировали-оптимизировали да не выоптимизировали=) ). Учитывая что каждая таблица сама по-себе имеет не большие объемы (чуть меньше миллиона самая большая таблица, остальные около 50-200тыс).

Bely
Далее... если меняем конфигурацию типовых блюд, то необходимо отработать ситуацию, что вчерашний заказ должен показывать ВЧЕРАШНЮЮ конфигурацию блюда.
Соответственно - делаем историю конфигурации блюд.

История организуется "автомтически" если каждое блюдо в реальном меню которое было предоставлено после копирования из типовых "живет своей жизнью". Тут что с избытком таблиц, что с введением колонки типа, если копировать - будет организована такая модель. Если организовывать какие-то специальные "исторические" таблицы - будет еще хуже...

Bely
Чтобы легко ссылаться одновременно на типовые блюда и на специальные - их проще поместить в отдельную таблицу, навесить на эту таблицу поля с датой (датами) когда дествовала такая конфигурация.

Тогда чтобы например удалить из борща сметану произойдут следующие действия:
- Выбрать все записи связей продуктов и блюда по ИДшке борща
- Создать копию этих записей за исключением той связи что мы хотим исключить
- Пометить старые записи как старые установив дату или иную метку.
Доустим у нас 100 раз за месяц люди конфигурировали таким образом борщ (не, борщ так не конфигурируют, например пиццу=), допустим из 10 ингридиентов), теперь даже чтобы выбрать актуальную конфигурацию, придется просмотреть 100*10 записей...это для примера, просто нехорошая получается зависимость...

Bely
Копировать каждое блюдо для каждого одиночного заказа - я бы не стал.

Тогда каким образом организуем историю?..

Bely
PS: а официантам скорее всего будет проще к заказу у блюда ввести ТЕКСТОМ что в нем поменять, вместо того, чтобы проводить переконфигурацию всего блюда :)
Иначе он будет проводить у компьютера больше времени, чем за обслуживанием столиков.

А если босс жмот и желает потом в отчете доподлинно посчитать сколько человек раз заказал борщ без сметаны (и почему ее нет на складе если без нее заказывали=)) или сколько добавок сыра было в пиццу...Тут уже текстом не сделаешь...

Bely
PS2: возможно, что к конкретному заказу блюда можно просто прицепить список чего "убрать/добавить/как приготовить". Официант будет выбирать только из фиксированного не очень большого списка (без соли, жарить с кровью, приготовить well done итд.)
Иначе можно будет заказаться омлет без яиц, но с рисом , не жарить а варить (получится рисовая молочная каша).

Да это очень хорошее решение. Оно как раз бы идеально вписалось не нарушая баланс: загрузки официанта у компа, удовлетворение требований учета дополнительных продуктов и даже решило бы проблему "омлета из каши".

Только вопрос не в конкретной реализации системы, а именно в концептуальном подходе. Как лучше всего такое сделать. Будь то планирвоание и учет меню в ресторане, планирование-учет этапов работ, тренировок в фитнесс клубе.
Пример с меню я привел из чисто умозрительных соображений, чтобы была понятна примерная суть объектов, хотел внначале вообще написать Таблица1, Таблица2, но не хотел путать всех абстрактными понятиями, для наглядности взял систему меню.

drop_db
Отличающиеся поля не появятся если добавить штук 6-10 полей attribute1, attribute2,...
кот. могут быть null. Если надо что добавить - писать в них.

Давайте сразу 100 добавим..мало ли..много будет полей добавляться...вопрос не в том что будет добавляться или нет, может вообще ничего добавляться не будет.. Просто привел какие-то критерии оценки 1 или 2 схемы..просто как пример, как мое мнение, чтоб другие соответсвенно свои какие-то идей высказали.

За ответы всем спасибо, в целом все склоняются к варианту с колонкой "Тип", я так понял...
Может еще какие-нибудь коменты или идеи?

Bely
Да, с историей проблемы нет.
Зато на каждый заказ блюда у нас появляется его копия.
Т.е. мы создаем при каждом заказе отдельный экземпляр блюда. Если у нас в день, 1000 заказов, в месяц 30*1000, из которых 100 в месяц специальных, то остальные 29900 экземпляров - близнецы, для которых мы будем хранить ВСЮ информацию по блюду, а не только ссылку на блюдо.
.....
Таблица экземпляров блюд будет пухнуть гораздо быстрее.

Утверждение основано только на том что из 1000 меню "кастомизированных" только 0.03%... Допустим в пиццерии, особенно при доставке, "кастомизирован" каждый второй-третий заказ (я говорил вообще про меню, но черт с ним, пусть будут еще и заказы)...Тогда схема с историей - накладна...

Bely
> Тогда каким образом организуем историю?..

Как всего.
Ищите по форуму - 100 раз обсуждалось.

Не надо переворачивать вопрос с ног на голову. Я спрашивал не: "Эй, ребата, как тут мне историю сделать?", а уточнял Ваш ответ в свете сделанных коментариев, как Вы предложили это сделать. Посылать в поиск я тоже умею...

Но даже не в этом дело, почему-то обсуждение свелось к вопросу быстродействия, это было приведено как "одно из"... Например если это программа для учета заказов для той же небольшой пиццерии, то зачем городить огород и ставить производительность во главу угла, я бы выбрал например простоту кода, ясность логической модели (которая ведет к удобству поддержки, сокращению времени на разработку и минимизации ошибок), а не сомнительные исторические таблицы, где сложность реализации не оправдана. Зачем заказчику ждать пока я напишу ему маткад, когда он просил калькулятор... В общем, почему-то не рассматриваются другие аспекты разработки ПО...

Bely
Нет хороших и плохих решений вообще, нет серебрянной пули.
Потому что специфика программ разная.

SomewhereSomehow
П.С. Только не говорите что "все зависит от задачи" и "выбирайте что нужно именно в вашем приложении" =) Может просто какие-нибудь мысли на тему....


Просил вроде не съезжать на прописные истины...

2Bely:
- Я хочу сделать обеденный стол, только вот не знаю, круглый или квадратный, может кто-нибудь рассказать про преимущества того и другого?
- Я бы сделал стол при помощи досок и ножовки!
- А как именно вы бы его сделали?
- Воспльзуйтесь поиском!
=))
Bely
1)Если вы собираетесь сделать программу одной пиццерии, то вы можете сделать 2-3 таблички, пару форм и 1 отчет. Пусть работают.
2) Но вот пришел второй чел из другой пицеррии - и понимаете, что для него придется программу переписывать на 80%, потому что он работает ПО другому.
3) Вы решили продавать свою программу (как Р-Кипер), но тут оказалось, что мир гораздо шире, чем Вам казалось. И никто не хочет менять свою работу только потому, что вы пытаетесь продать им свою программу

...No comments =))

По теме:
Все-так решил выбрать реаизацию с дополнительной колонкой типа, признака стандарных блюд/меню...Самому не нравится плодить лишние таблицы... Ну а по мере развития уже буду смотерть, в случае чего, всегда можно разнести на несколько таблиц, все данные для этого будут.
Всем спасибо за ответы, хоть отдельные личности и пытались умничать/ерничать =)
Тему можно закрывать.