Приветствую всех!

У меня проблема с проектированием БД (попросил друг, не смог отказать). Попробовал разные варианты схемы, но сам запутался, получилось не то, что надо, а сплошные сложности с реализацией. Попробую объяснить проблему.
Есть некое кафе, продающее разные блюда. Покупают различные ингредиенты, складируют их, ну и потом ежедневно расходуют на приготовление того или иного блюда, а в конце происходит продажа. Есть также различные расходные материалы, что-то вроде салфетки, зубочистки и т.д., их также покупают в большом количестве и потом ежедневно расходуют (не продают). Есть ещё такие вещи, которые не проходят процесса приготовления (как бы стадию производства), а продают клиентам в таком виде, в каком получили от поставщика. К примеру, напитки Coca-Cola, Pepsi в бутылках и т.п. Само собой разумеется, нужно расходовать со склада методом FIFO, т.к. ещё и нужно учитывать срок годности ингредиентов и прочих вещей.

Что я пытаюсь сделать?
Создаю таблицу по «приходам ингредиентов» (закупка):
1) Уникальный код прихода
2) Дата прихода
3) Код ингредиента
4) Цена поставщика
5) Количество
6) Срок годности

Создаю подчинённую таблицу по «расходам ингредиентов»:
1) Уникальный код прихода
2) Дата расхода
3) Вид расхода ==> (продажа, списание из-за истёкшего срока годности, брак и т.д.)
4) Дата расхода
5) Количество

Ставлю ограничение с помощью триггеров о том, что расход не может быть произведен раньше прихода, ну и общее количество расходуемого материала не должно превышать прихода.

Далее.
Создаю таблицу рецепт, где указываю, какие ингредиенты и в каком количестве необходимо для приготовления блюда. Эта таблица нужна будет как что-то вроде «нормы расходов».

Ещё создаю таблицу для учёта «приготовления блюда»:
1) Уникальный код
2) Дата приготовления блюда
3) Код рецепта ==> (в таблице «Рецепт» есть код блюда и код ингредиента)
4) Количество

При добавлении записи в таблицу «Приготовление блюда» триггер должен добавить автоматически нужную запись в таблицу «Расход ингредиентов», причём уже тут начинаются сложности. Если ингредиента не хватает по одному приходу, то часть нужно перебросить на следующую закупку. Т.е. допустим, 01.09.2016 купили 100 единиц некоего ингредиента и 08.09.2016 ещё раз 100 единиц, в течение недели расходовали 90 штук, это означает, что от первой закупки осталось 10 штук. 08.09.2016 нужно расходовать 20 штук: 10 из предыдущей закупки от 01.09.2016 и 10 из закупки от 08.09.2016г.

Ну и это ещё не все. Дальше больше! Продажа.
Продают то они не только блюда, которые они сами и приготовили, но и напитки. Поэтому нижеследующая таблица по продажам не решит эту проблему:
1) Дата продажи
2) Код блюда
3) Порция
4) Количество

«Продажа» живёт отдельной жизнью, она никак не связана с «приготовлением блюда», но как списать напитки и тому подобные вещи?
Чтобы иметь «под рукой» остаток на складе, думаю ещё нужно создать отдельную (по сути вычисляемую) таблицу «остаток на складе», где должны быть поля «DATE_FROM» и «DATE_TO». Таблица должна позволить получение информации об остатке на любую дату, чтобы не проводить вычисления со дня основания кафешки. 
Вот такие проблемы.
Может у кого есть светлые идеи?
Заранее благодарю за дельный совет по решению данной проблемы.

P.S.
Пробовал уже обкатать эту схемку в тестовой базе, как я писал сложности с реализацией. Слабенькая схема получилась.

Господа, спасибо за ответ

Dimitry SibiryakovНе просто слабенькая, совсем никакая. Оторванная как от предметной области так и от жизни.
ФИФО по блюдам на поточном производстве? Не смешите меня. Как повар будет учитывать
расходуемую муку, например? По граммам? У него нет ни способов, ни времени, ни желания
этим заниматься. ...

Ну там реально с FIFO все нормально. Каждое утро кладовщик (он же снабженец в одном лице) выдаёт со склада всё то, что просит повар, при этом старается не выдавать новые ингредиенты если есть старый запас. А скоропортящиеся ингредиенты вообще стараются не тариться, используют в основном день в день.

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

Кот Матроскин У "расхода" должна быть ссылка на родительскую операцию - "приготовление блюда", "продажа", "списание" и т.п., (соответственно, то что Вы называете "тип расхода" уместнее будет в этой родительской операции).
Что Вы имеете ввиду? "Расход" должен быть главным, а "приготовление блюда", "продажа", "списание" подчинённые таблицы или наоборот? Во втором случае я в "расходе" должен держать отдельные поля "код приготовления блюда", "код продажи", "код списания", чтобы связать их с этими таблицами?

Кот Матроскин...
Вообще имхо Вы пытаетесь сделать все сразу, а задача вполне разбивается на несколько отдельных несложных подзадач. Скажем, на первом этапе я бы не думал про таблицу "актуальные остатки на на складе" - при желании ее вполне можно прикрутить потом.
ОК. Я решу эту проблему в самую последнюю очередь. Пока отложу, хотя этот момент очень и очень важен для снабженца.