Несколько идей для вас:
Вы используете термин table
для обозначения таблицы людей, которые заказывают вещи.Поскольку это может сбивать с толку в моем ответе, давайте использовать термин customer
для обозначения таблицы, полной клиентов, которые размещают заказы.
Сначала вы должны решить, как структурировать свою базу данных и таблицы..
Одна идея состоит в том, чтобы иметь две таблицы SQL: (a) таблица блюд (закусок, десертов, напитков и т. Д.) И их цены, (b) таблица транзакций.(Каждое заказанное блюдо является отдельной транзакцией, поэтому для каждого клиента будет несколько транзакций)
Каждая транзакция (одна строка) будет включать:
a.транзакция - индекс - последовательный - автоинкремментированный - УНИКАЛЬНЫЙ (первичный ключ)
b.ID транзакции - invoice_number - может быть просто ГГГГММДД_ЧЧММСС
c.table_num - целое число (идентифицирует клиента (клиентов), которые сделали заказы)
d.блюдо - блюдо, которое было заказано
. При печати счета-фактуры выполняется поиск в таблице Tn всех элементов, связанных с ID транзакции # 123.Упрощает добавление новых заказов.
При желании вы также можете иметь таблицу SQL с сессий , которая может ссылаться на все транзакции, связанные с одним обедомсессия.По сути, это будет запись каждого заполненного счета.У вас могут быть такие поля, как:
a.SessionIdx - уникальный индекс, автоинкремент, первичный ключ
b.SessionID - номер счета-фактуры - будет транзакцией_num в таблице транзакций
c.дата / время
d.количество клиентов
e.Способ оплаты
Также обратите внимание, что вы захотите сделать эту реляционную базу данных, что просто означает, что вместо написания названия блюда и цены на блюдо, в их собственных полях в таблица транзакций - вы просто добавляете dish_id (из таблицы SQL блюд).Затем будет опрошен стол с блюдами, чтобы узнать название блюда и цену блюда.Облегчает обновление вещей. Однако вы также можете сохранить исторические цены, чтобы при обновлении цен вы не теряли исторические данные о ценах.