Какова наилучшая разбивка типов статуса заказа для корзины «Заказ» ТАБЛИЦА? - PullRequest
2 голосов
/ 17 ноября 2009

Я видел несколько разных схем корзины покупок с разными таблицами для типа статуса заказа / типа доставки / типа оплаты.

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

Ключевым моментом, конечно, является то, что сколько бы столбцов я ни использовал - они должны представлять взаимоисключающие вещи.

Я думаю о чем-то вроде:

OrderStatus - сводный статус PaymentStatus - Оплачено / Неоплачено / Частично оплачено / Ошибка ShippingStatus - Не отправлено / Частично отправлено / Доставлено / ДоставленоByHand

Каков наилучший способ разобраться в этом - должен ли я иметь «сводный» статус, представляющий также общий «читаемый человеком» статус, а также отдельные статусы для каждой независимой части процесса?

Ответы [ 2 ]

4 голосов
/ 22 декабря 2009

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

  • Таблица заказов (OrderID, OrderStatusID, ...)
  • Таблица OrderStatus (OrderStatusID, Имя)

OrderStatus будет иметь такие значения, как: * 1, «Платный» * 2, «Неоплаченный» * 3, "Отправлено" * 4, «Не отправлено»

Важной частью является определение того, какие статусы действительно взаимно исключают другие статусы. Например, приведенные выше примеры строк, вероятно, не очень хороши, так как вы могли бы иметь заказ, который был бы «оплачен» и «отправлен». Если это так, то вы можете разделить OrderStatus на PaymentStatus и ShippingStatus (как вы намекали).

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

1 голос
/ 17 ноября 2009

Это действительно очень зависит от полной функциональности самой корзины. Я бы посоветовал следовать SDLC, чтобы дать вам более четкое представление о том, с какой функциональностью вам понадобится начать, чтобы получить более четкое представление о том, какие данные (таблицы / поля) вам необходимо хранить в базе данных.

Вот несколько ссылок, с которых можно начать:

http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle

http://www.computerworld.com/s/article/71151/System_Development_Life_Cycle

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

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

http://en.wikipedia.org/wiki/Database_normalization

Надеюсь, это поможет!

...