СергейБрон,


СергейБронопыта в создании БД нет :(
- Если это курсовая, то сделайте самый простой вариант с десятком таблиц и сдавайте - главное чтобы была логика и видно было, что вы в теме и сделали сами...
- Если не курсовая, то лучше освоить и внедрить готовое решение...
- Вот вкратце ТОЛЬКО некоторые проблемные вопросы и их тонкости - ибо Сложность и способы создания проекта зависят от выбранной модели общепита:
1). С калькуляцией или без.
2). С обслуживанием или нет.

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

Калькуляция я бы это даже не знаю как назвал (черная дыра, бермудский треугольник и т.д.) заключается в том, что есть понятие ингредиент (картошка, лук, перерец, масло, молоко, мясо и т.д.) которые мы закупаем для своего общепита и этот же ингредиент входит в разные блюда с величинами Брутто и Нетто. Соответственно при закупке продуктов количество ингредиентов на складе (Брутто - с кожурой и отходами) увеличивается, а при продаже блюд количество ингредиента - уменьшается по Брутто согласно калькуляционной карте блюда. Это дело как правило никогда не бьет и периодически приходится подкручивать остатки списанием и т.д. ибо повару по барабану что в калькуляции стоит 500 гр. свежих помидор (у него помидоры закончились и он налил в борщ кетчупа, а вместо свежей свинины бросил банку тушенки), соответственно уже по 4 м ингредиентам остатки не бьют...

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

Вот только те азы крупными мазками, которые нужно учитывать по любому, ну и плюс дальше к этому ваши тараканы сверху: заявки, меню по дням, журналы... ну, общем если с нуля делать - то проще сразу застрелиться....

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

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

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

Прямо республика "ШКИД".... такого никогда не будет - меню составляет обычно шеф-повар, и если один из студентов захочет рябчиков с ананасами - то тут же будет послан куда подальше... все блюда делаются исходя из технической возможности (духовые шкафы, пароварки, кофе варки с брикетами, возможность доставки готового ассортимента и прочее), в лучшем случае будет меню на неделю вперёд утвержденное шеф поваром столовой, а студенты смогут только выбирать либо сосиски на завтрак либо омлет... либо борщ на обед либо суп... нужно реально смотреть на вещи... ну и естественно, если студент готов выложить за обед 5 000 р. то можно ему и рябчиков припереть из ресторана напротив, и то это будет по предоплате, если начальник столовой не полный идиот... а студент наоборот - конченный дебил и не не может сам сходить в ресторан напротив....

СергейБронСтуденты могут питаться дифференцировано, т.к. один и тот же студент может позавтракать в одной столовой, пообедать во второй и поужинать в третьей или может вообще не питаться в этот день. По итогам дня нужно будет подсчитать сумму затраченных денег на питание по каждой столовой в отдельности (составить товарные накладные).

Если бы я был директором общепита - то с такой системой у вас бы была только предоплата, как раз для тех, кто решил не питаться в этот день или не смог - я же на него уже приготовил....

СергейБронСитуация такова: Есть список студентов, которые ставятся на питание. Эти студенты могут питаться в разных столовых (в каких столовых питаются определяем мы в заявке), в разных столовых может быть утверждено разное меню (по дням недели и по завтрак-обед-ужин). Студенты могут питаться дифференцировано, т.к. один и тот же студент может позавтракать в одной столовой, пообедать во второй и поужинать в третьей или может вообще не питаться в этот день. По итогам дня нужно будет подсчитать сумму затраченных денег на питание по каждой столовой в отдельности (составить товарные накладные).
Ни обслуживание, ни остаток не учитывается.

Ну тогда нужно плясать примерно от этой картинки... прошу не судить строго (экспромт и бе проверки) + комментарии приветствуются... Весь русский тест только для понимания (рекомендую заменить английским)... можно для полноты нарастить хребет дополнительными полями. Смысл в том, что студент делает заказ на определенный День и час блюд из конкретной столовой при условии, что это блюдо есть в меню этой столовой на указанный день и час.... фу...

vmag,

+ сам файл для продолжения тут

СергейБрон,

Этот вариант (выше) с минимумом избыточности, по этому сложнее кодинг, например понятие меню там это группировка по Дата ....- .... Завтрак_Обед_Ужин. Можно вносить изменения в схему, добавляя избыточность и тем самым конкретизируя понятия, например в схеме ниже пункт Меню это не собирательное понятие, а отдельная запись (например завтрак 21 числа) к которой через связующую таблицу привязаны блюда

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

Так происходит сейчас, но меня мучает вопрос, что если у студента будет возможность выбора между двумя равнозначными товарами (скажем между гороховым супом и борщем, т.е. товарами разными по себестоимости), но в пределах одной суммы.
Скажем студенту дается на завтрак 65р., на них он может купить:
1 вариант: гречку за 30р, сок за 20р, бутерброд за 15р, или
2 вариант: овсянку за 35р, чай за 10р, шоколадку за 20р.

Тут трудно что то сказать... любая схема проверяется на практике и корректируется... знаю точно что найдется однозначно вредный студент (и даже не один), который захочет не варианты 1 или 2 а тупо выберет гречку, чай и два бутерброда кто-то забежит на 5 минут и набьет карманы одними шоколадками... ну и наверное не стоит навязывать столовым меню (тем более по договору), иначе вы будете брать на себя ответственность что кто то чего то не стал есть, а кому то чего то не хватило... ну и логически наверно не корректно, что договор со столовой заключен ни с кем (обычно это две стороны с подписями и печатями), а блюда привязаны к договору ? ведь столовая кормит не только ваших студентов и наверняка у нее есть блюда мимо вашего договора (блюда обычно примотаны к столовой) Вам должно быть виднее (иногда очевидное может быть на практике не реальным и наоборот)