Как организовать структуру заказов в БД (общепит)?

Question

[lexstile]

Есть следующая структура таблицы:

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

Вопрос в следующем - стоит ли вообще отказаться от поля quantity и каждую позицию хранить отдельной записью?
Проблема 1: частичная оплата подобных позиций, придется, как минимум, хранить еще одно поле с количество, сколько позиций оплачено, а сколько еще нет.
Проблема 2: частичное удаление, придется декрементировать текущую запись, вместо того, чтобы просто удалить по идентификатору.
Проблема 3: статистика, гораздо проще организовывать статистику по отдельным записям, нежели еще учитывать различные счетчики.
....

Если я откажусь от поля quantity и буду просто дублировать одинаковые позиции отдельной записью, как минимум, логика работы станет проще.
Не будет проблем, которые описал выше.
Но будет больше записей в БД, думаю, что этот показатель не должен превышать 20-30% от первого кейса.

Вопрос в том, как правильно организовывать подобное?
И какой кейс предпочтительнее?

Что выбрать - +30% записей (проблема производительности) или усложненную логику?

Comments

[Adamos]

+30% записей (проблема производительности)

Кто вам это сказал? Проблема производительности может возникнуть, если вы без необходимости увеличите количество записей на два-три порядка. И то не факт, зависит от того, как с ними работает система.
В целом вы прекрасно описали классические проблемы преждевременной оптимизации.

[N]

Такая структура - классика...
Выше правильно сказали... - на данном этапе - всё норм.

[lexstile]

Adamos, то есть, можно смело отказываться от поля quantity? :)

[Adamos]

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

[lexstile]

N, как я понял, Adamos выше описал как раз наоборот, чтобы хранить каждую позицию отдельной записью без поля quantity, т. к. оно не имеет смысла.
Что я начал раньше времени оптимизировать.

[N]

lexstile, Мне кажется он имел ввиду, что при любой схеме в данном случае пока беспокоиться не о чем...

А конкретно по вопросу:
Я бы лучше сразу хранил кол-во...потому что при выводе списка заказа, например нужно будет отобразить кол-во одинаковых...и начнётся пляска с GROUP BY и т.п. ...хотя с полем "кол-во" тоже в придётся поплясать...
Вообщем как удобнее, так и делай на данном этапе...

[Adamos]

N, я имел в виду, что нужно беспокоиться не о компактности хранения (БД с этим успешно справится сама), а об удобстве работы.
Если по работе записи приходится разделять (упомянутая ТС раздельная их оплата, например) - нет смысла искусственно создавать трудности, их объединяя. Когда понадобится объединить - опять-таки у БД с этим проблем не будет, "помогать" ей, городя самопальные костыли, просто глупо.

[N]

Adamos, Ну я примерно это же и имел ввиду...))

Вообщем как удобнее, так и делай на данном этапе...

[mystifier]

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

[lexstile]

mystifier, вот про копейки очень интересно, спасибо за совет, даже не подумал

А по поводу, думаю, будет в основном до 10 одинаковых позиций, чаще 2-4 (а группировать действительно нужно будет, но как мне показалось из дискуссии, группировка и наличие дополнительного количества записей в БД - это единственные "проблемы" (в кавычках)).

Если будут десятки-сотни-тысячи одинаковых позиций

[Adamos]

lexstile, про копейки совсем неинтересно. Тип DECIMAL делает все преобразования в целое и обратно за вас, никакие дополнительные танцы не требуются.

[lexstile]

Adamos, извините, что снова вопрос.
Не интересно - лучше оставить так, как есть?
Или вы имели ввиду что-то другое?
Пока только заметил, что decimal сам округляет (пример: 4.499 -> 4.50), но когда делаешь SUM, в сумме получается не 2 знака после запятой.

[Adamos]

lexstile, а откуда мне может быть известно, как оно у вас "есть"? Вы вместо схемы приложили скриншот с неизвестно чем неизвестно откуда. Для сумм фиксированной точности в БД используется DECIMAL.

Answer 1

[Илья Голец]

Что-то мне подсказывает, что (скорее рано, чем поздно) возникнет задача построить отчет по отказам. В этом случае я бы эту таблицу оставил как есть, но добавил ещё таблицу с отказами, с полями "заказ, блюдо, количество, пользователь, дата".
Из бонусов — в обе таблички данные будут только добавляться, можно подбирать тип БД, который умеет в быструю вставку, с репликацией чуть проще...

На счёт частичной оплаты не понятно — зачем вообще такое, почему недостаточно оплачивать всё и сразу. И зачем отслеживать какие именно позиции оплачены.

Comments

[lexstile]

Благодарю за ответ.

Да, эта задача есть в бэклоге - рано или поздно к этому придем, но это большая отдельная тема.
Как я понимаю, отказы могут быть как от заказа, так и от отдельного блюда, то есть, будет, как минимум, две таблицы. Плюс, нужны причины отказа - тоже для статистики.

задача построить отчет по отказам.

Когда несколько человек за одним столом в рамках одного заказа оплачивают только свои позиции.

На счёт частичной оплаты не понятно — зачем вообще такое, почему недостаточно оплачивать всё и сразу.

[Илья Голец]

будет, как минимум, две таблицы.

Да, наверное, так. На счёт причин отказа —тут вопрос к будущим пользователям/заказчикам. Возможно, они ещё захотят как-то ревизировать кухню и понимать, на каком этапе приготовления произошел отказ и был ли фактический расход продуктов.

Кстати, посетила мысль — при готовке на кухне одно блюдо, разбитое на отдельные строки, надо будет снова склеивать — готовка, скорее всего, будет происходить сразу на все N тарелок.

несколько человек за одним столом в рамках одного заказа оплачивают только свои позиции

Если вы хотите формировать раздельные счета, то тут могут быть раздельные заказы, чтобы при вводе заказа сразу указывать, где чье блюдо и по запросу счета печатать сразу несколько. Ключевой вопрос — как вы будете принимать оплату. Если у каждого отдельно, то по закону каждому нужно выдать чек ККМ. А в нём должны быть указаны позиции с ценами. Тогда будут раздельные строки и, возможно, сущность «группа заказов». Но тут возможна путаница — официант повесит блюдо не на того человека. Или придется после выполнения заказа официанту построчно заказ разделять. Тут к эксперту по предметной области вопрос, как лучше. См. чуть ниже я про ТЗ пишу.

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

Про ТЗ ;)
В общем, моя рекомендация — задокументировать все бизнес-процессы с возможными вариантами исключениями. И все печатные формы. Тогда можно будет провести встречную верификацию — по каждой сущности и каждому полю увидеть, в каком процессе они создаются и в каком отчете выводятся. Если не выводятся, эти поля можно удалить.

Вот что я обычно пишу в ТЗ:

1. Список сущностей и их свойств (станут таблицами и колонками)
   
2. Потоки данных — какие процессы создают, изменяют и читают сущности
   
3. Бизнес процесссы. Подпункты: цели, триггер (что стартует процесс), входы и выходы (сущности), основные шаги (штатный процесс), исключения (на каком шаге стартует альтернативный процесс и его шаги, прочие параметры (например, время отклика, разные ограничения и т.п.)
   

При описании бизнес-процессов обязательно указывать актора (система/официант/пользователь/клиент и т.п.). Фразы типа "загружается меню" запрещены ("приложение отображает на экране меню из внутреннего кэша").

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