СергейБрон,


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

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

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

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

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

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

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

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

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

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

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

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

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

vmag,

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

СергейБрон,

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

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

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

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

3309vmag,
это - ваше ?
- из жЫзни ?

vmagНу тогда нужно плясать примерно от этой картинки... прошу не судить строго (экспромт и бе проверки) + комментарии приветствуются... Весь русский тест только для понимания (рекомендую заменить английским)...

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

СергейБрон,

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

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

Ну а если студенты сами платят - тогда вообще не понятно зачем все это...

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

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

Если бы не было таких проблем - то все очень просто:
1. В вузе ставится сервак и на нем разворачивается сайт, в котором доступ юзеров по логину/паролю (возможно только в раздел питание). Юзеры это и есть питающиеся таким образом студенты и только они (фамилия, логин, пароль)...
2. На сайте в разделе питания есть меню по столовым, после авторизации можно выбрать себе завтрак,
обед и ужин в любой столовой на завтра или на неделю...
3. Админ (столовая) после печати заявленного на завтра, например сегодня в 18.00 (это и есть накладная) блокирует распечатанный день и готовит на него еду (например на завтра), ну а кто не успел сделать заказ до 18.00 - тот опоздал и приходите завтра... соответственно студент может сделать заказ на завтра или его изменить только до 18.00 сегодня, а на последующие дни - легко...
4. Если таким студентам еще выдать и пластиковые карты типа банковских (цена вопроса 20 р. штука, только нужно брать с черной полосой а не с серой как в эльдорадо), то на кассе читая их карт-ридером - можно еще и контролировать кто поел а кто нет и что поел (бикнул, получил то что заказывал ибо оно высветилось а мониторе, заодно и отметился что поел)...
Ну и всё... чтобы сделать заказ нужен минимум интернет и телефон с браузером, для малоимущих или интернет кафе или письменная заявка в профком ответственному лицу...
Такая база как вы хотите - это не то... в этой идее мало жизни, а вот в том что выше гораздо больше
смысла - это уже нужно не одному вам, а нужно всем (не сделал заказ - не поел).... нет логина и пароля - на халяву не поешь...

vmag,

Продолжение и итого...

- базу всю можно сделать в акесе как макет а потом перенести на MySql.
- приложение на акесе (линкованное на MySql) оставить по экземпляру в вуз и в столовую
для корректировки меню, студентов и получения документов.
- написать на PHP модуль авторизации и заказов для студентов и выложить на сайт.
- Схема базы такая:
Слева на право Столовая к ней подчиненная Блюдо к ним подчиненная Меню (День, час)
Справа на лево Группа к ней подчиненная Студенты.
По середине стыкуются таблицей Заказ - см. выше мой рисунок 1 или 2
- договор в схему нет смысла тащить - его хватит на бумаге в сейфе, там все равно будет всего два пункта: типа кто, кому, сколько и когда платит + что цены на блюдо не могут повышаться в год более чем на ___ %
- сначала сделать без дисконтных карт и без контроля посещаемости дабы просто проверить жизненную необходимость...

СергейБронКоличество питающихся определяется на каждый день отдельно, т.е. сегодня могут питаться 20 человек, завтра 25 , а после завтра 15 и например из 20 человек на завтрак стоят 10, на обед - 20, на ужин - 15


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

Проще дать в каждую столовую одну и ту же заявку (на бумаге) типа: Эти 25 студентов (список прилагается) могут есть бесплатно в пределах суммы 100 рублей за один прием пищи (или разная цена если обед дороже), ибо за них платит ВУЗ, а студентам выдать именные листы контроля (по недельно), в которых столовая будет ставить штампик, что студент позавтракал сегодня или пообедал, дабы он не поел (поели за него) несколько раз в разных столовых и закрыть эту тему...

СергейБронРазночтений не вижу.

Разночтений и нет, просто из-за 25 человек, которые то будут есть, то не будут такой сыр-бор...