Аргументы для составного PK в dish? Это что-то типа какое-то "первое блюдо" называется и стоит также как некое "второе блюдо"?

Если какой-то такой экзотики не предусматривается, то dishid - PK, dishtypeID - FK, как следствие из menu dishtypeID тоже убираем...

aL MIRВсем приветы!
Что скажите по этой модели? Может предложите лучшее решение?
Обеды сотрудников

aL MIR Че та я совсем запутался ,
а как быть если нада предварительно составить меню на определенную дату, тогда всем сотрудникам добавляем "пустой" обед (count=0)?

Сколько раз говорено - ФОРМУЛИРУЙТЕ НОРМАЛЬНО УСЛОВИЯ ЗАДАЧИ !

Сейчас всплывет "Ой, а как я узнаю из какого отдела сотрудники едят по талонам а из какого за наличные?"

aL MIRНе всплывет, если именно Вы не хотите отвечать (помочь), не отвечайте, никто не заставляет.


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

По сути. Любопытно взглянуть на скриншот екселя - это такая простыня, где в первом столбце список сотрудников, а в первой строке список всех 6-8 блюд за неделю? И в каждом пересечении фамилии с блюдом стоИт 0 или 1/2 или 1? Во дела-а-а!..

Все равно стало понятней, сейчас поделюсь соображениями

Предлагаю так:

menu (реальное меню по дням - что было доступно для заказа)

menuid pk
dishid fk
menudate
count (если необходимо отслеживать лимит заказа - сколько супа наварили в этот день)
cost (цена за единицу блюда если она может со временем меняться, иначе оставляем в dish )

dinner (оплата конкретного сотрудника на конкретную дату)

dinnerid pk
emplID fk
dinnerdate
payment (сколько заплатил)

dinner_detail (оплата конкретного сотрудника на конкретную дату)

dinnerdetailid pk
dinnerid fk
menuid fk
count (кол-во порций конкретного блюда)


ну где-то так в первом приближении...
Правда при таком раскладе я бы таблицу dinner переименовал - она больше отражает факт_оплаты. Или вообще отделил бы эти сущности - оплату и сам обед, т.к. может быть оплата без обеда, а обед без оплаты. Это если в последней таблице вместо dinnerid fk сделать emplID fk.
Решать Вам

а отчеты, понятное дело расчитываются хранимыми процедурами.

да, ну и, конечно, по всем таблицам наложить ограничения целостности... я уж не стал вдаваться в эти подробности, например
в menu
dishid + menudate - уникальный ключ

ShtockА это то "а отчеты, понятное дело расчитываются хранимыми процедурами" тут причем?Селектом что-ли не вытащить?
Хранимая процедура не может содержать select?
Лично я отчеты ВСЕГДА реализую хранимками, но давайте и я спрошу Вас - Ваш "селект" откуда вызывается - из клиента? из вьюхи? из хп?
Или я утверждал, что буду пользоваться в хп одними делитами?

Хотелось всего лишь подчеркнуть для автора ту мысль, что для отчетов (пункт "нужно" в ТЗ) никаких дополнительных структур в модели данных создавать не нужно.

aL MIRSgt.Pepper стоимость блюда конечно может меняться, и может хранить не сколько сотрудник заплатил а оплатил ли обед (блюда входящие в обед) те ДА или НЕт ?
Т.е. отсекаем варианты,
1) что обед стоит 105 рублей, а он заплатил 100? Типа "ладно, завтра больше на пять заплатишь"
2) что он просто заплатил деньги за вчерашний неоплаченный обед НЕ_ОБЕДАЯ_СЕГОДНЯ
?

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

aL MIRPS Блин
Сильно сказано!

По сути - классическая бухгалтерская задача. Одна сторона счета дебетовая (таблица КтоЧёКогдаСожрал), вторая кредитовая (таблица КтоЧёКогдаПлатил). Подсчитываются дебетовый и кредитовый оборот за период, один из другого вычитается, выводится сальдо - остаток, который сотрудник недоплатил или переплатил. Это так, на пальцах...
На самом деле в реальных бухсистемах чаще, конечно, обороты из обеих таблиц хранятся в одной - журнал операций/проводок и т.д.

aL MIRВсе понял - буду рыть(думать) в этом направлении.
А сейчас все таки останавлюсь на варианте оплачен или нет ВЕСЬ обед...

ок, не возражаю )))
успехов