Повторяющиеся заказы

Question

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

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

Небольшая предыстория бизнес-процессов.
- Клиент закажет товар и при оформлении заказа укажет, является ли он разовым или еженедельным / ежемесячным заказом.
- Клиент укажет место, в котором можно забрать свой заказ (это место относится только к заказу)
- Если стоимость заказа> 25,00, то он принимается, в противном случае он отклоняется.
- Это заполнит таблицы orders_test и order_products_test соответственно

• У сотрудника на заднем плане будет сформирован отчет о доставках за день на основе этих двух таблиц.
• Они смогут распечатать его, и он сгенерирует список того, какие предметы отправляются в какое место. На основании следующих критериев.
• date_of_next_scheduled_delivery = текущая дата
• оставшиеся_доставки> 0
• Как только они будут удовлетворены списком доставки, они нажмут кнопку «Процесс доставки».
• Это отрегулирует таблицу order_products_test следующим образом
• Вычесть 1 из оставшихся поставок
• Вставить текущую дату в date_of_last_delivery_processed
• В зависимости от частоты доставки (то есть один раз, еженедельно, ежемесячно) будет меняться date_of_next_scheduled_delivery
• Значения статуса в таблице order_products_test могут быть активными, удерживаться или отменяться с истекшим сроком действия

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

Answer 1

Несколько мыслей, хотя и не обязательно завершенных (есть много вопросов к вашему вопросу, но, надеюсь, эти пункты помогут):

• Я не думаю, что вам нужно отслеживать оставшиесяпоставки.У вас есть только 2 варианта - одноразовый заказ или повторяющийся заказ.В обоих случаях нет смысла рассчитывать оставшиеся поставки.Он никогда не используется.

• С точки зрения отслеживания следующей даты доставки, вы можете просто отслеживать день заказа.Если это повторяется - ежемесячно или еженедельно, независимо от этого - все рассчитывается с этой первой даты.Большинство систем БД (MySQL, SQL Server, Oracle и т. Д.) Поддерживают более чем достаточную гибкость вычисления даты, так что вы можете вычислить это на лету, в отличие от поддержки такого известного расписания.* Если место доставки относится только к заказу, я не вижу смысла в создании отдельной таблицы для него - это функционально зависит от заказа, вы должны хранить его в той же таблице, что и заказ.Для большинства систем электронной коммерции это не так, потому что они склонны связывать список мест доставки с учетными записями, о которых они сообщают вам при заказе более одного раза (например, Amazon).

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

• Не называйте свои таблицы суффиксом "_test" - это сбивает с толку.