ПМСМ на первый взгляд все нормально, просто я бы сделал иерархический классификатор для блюд,или хотя-бы связал блюдо и его тип через m:n, так как кроме первое/второе обязательно всплывет горячее/холодное,а базу корежить из-за этого неправильно, а блюдо одновременно обладает этими двумя свойствами.

сделайте табличку Статус и заполните ее значениями "Заказан", "Доставлен" и т.д. и делайте на нее ссылки в нужных местах для сотрудников.

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

раз всплыло понятие "файлик разрешен для редактирования до 13 часов" появляются блокировки бизнес-уровня.Поэтому необходимо как-то их обеспечить,например через те же статусы пунктов меню.Например,статус пункта меню "Подтвержден" больше редактировать нельзя, "Заявлен" еще можно править,"Отгружен"-отправили клиенту.Тогда еще вспылывает одна таблица с полями Суррогатный ключ, Ссылка на соотв пункт меню (тут Вам должен был бы пригодиться сурогатный ключ для Блюдо-Человек, которого нет), Ссылка на табличку со статусами, дата установки.Понятно дело предыдущие статусы менять нельзя.МОжно только добавлять новые и то только до статуса "Отгружен"-пункт меню завершил свою жизнь.И отчетность как раз надо строить по пунктам типа "Отгружен":можно делать историю пунктов меню для аналитики например частоты смены позиций меню. В общем "фантазия ON".

А это то "а отчеты, понятное дело расчитываются хранимыми процедурами" тут причем?Селектом что-ли не вытащить?

на "Лично я отчеты ВСЕГДА реализую хранимками, но давайте и я спрошу Вас - Ваш "селект" откуда вызывается - из клиента? из вьюхи? из хп?"

я посмотрю на требования по безопасности и с вероятностью 90% буду делать select на клиенте,который в свою очередь будет ползти на view сервера.


P.S. Вы работаете с MSSQL (плохих чувств к нему никаких не имею)?Как показал мой опыт отчеты из хранимок очень любят ценители данной СУБД.

to Sgt.Pepper:
1.собственно я не на что не намекаю,а говорю о своем опыте работы с реальной системой,в которой часть скд реализованна во view и необходимо пользоваться стандартными средствами нашей системы.
2.У моей субд проблем с безопасностью лично мной не обнаружено (Oracle10G)
3.встроенное ср-во разработки клиентской части заточено под select из таблиц,поэтому с select из процедур просто никогда не заморачивались.

Г-н Sgt.Pepper,если Вы хотите поговорить о системе контроля доступа-создавайте ОТДЕЛЬНЫЙ топик.Я готов поговорить.Данный топик о вкусной и здоровой пище и я не считаю,что его надо зафлеймивать.

Но:
0.по поводу 90%-для некоторых вопросов используются временные таблицы Oracle (это несколько другая вещь чем в MS),поэтому для тех отчетов,на которые не хватает сил написанием select данные помещаются в эти таблицы,контроль доступа к которым опять таки реализован средствами Oracle.
1.по поводу "select из процедур не заморачиваюсь"-да,не заморачиваюсь,и что в этом такого.если мне не нужен инструмент я его не применяю,особенно если я не вижу преимуществ перед альтернативными способами решения проблемы
2."Никак обосновать не захотели. А ведь считается что неоправданное перекладывание логики на клиента есть не очень гуд. Ну, например, послезавтра чуть изменится логика формирования отчета - будете переписывать клиента и апгрейдить до нового релиза все 127 рабочих станций?
Или проще переписать логику ХП на сервере, а на клиенте "exec MyStoredProc" не потребует изменений?.."
Во-первых,не вижу проблемы обновления релиза всех 215 рабочих станций.Проблема была решена 3 года назад.
Во-вторых,если Вы внимательно читали,то я обращаюсь ко view,которое с таким же успехом и поправлю.
В третьих,если в отчете изменится кол-во входных параметры, то и Вы и я будем править клиента (если конечно у Вас не построена система вызова хранимых процедур на клиенте с использованием словаря системы,где описаны входные и выходные параметры-правда в таком случае работа не менее геморойна).
3.вся схема безопасности в нашей системе построена на основе системы безопасности Oracle-самопала нет никакого, причем за ее настройку (что логично) несет ответственность специально обученный пользователь Офицер доступа, так что если он даст права на все бизнес-сущности и операции с ними (права надо раздавать на них, а не на таблицы) пользователю-значит так надо.Любой же пользователь,который входит в систему имеет право только на CONNECT,а дальше работает уже СУБД,поэтому я не могу дать гостю права на все таблицы.

P.S. Со свое стороны считаю флейм законченным.Спасибо за внимание.