Циклические связи баз данных. Хорошо, плохо, Исключения?

Question

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

У меня есть дизайн для системы заказа, не обращая внимания на все, что не относится к этому примеру, я оставил с:

• CreditCard
• Заказчик
• Заказать

Я хочу так, чтобы

• Cust гомор может иметь кредитные карты (0-п)
• Клиентов имеют заказы (1-п)
• Заказов имеют один клиент (1-1)
• Заказов одна кредитной карты (1-1)
• кредита карты могут иметь один клиент (1-1) (уникальные идентификаторы, чтобы мы могли игнорировать уникальность номера куб.см, муж/жена может поделиться куб.см экземпляров ECT)

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

Эффективно это создает круговую конструкцию между тремя таблицами.

Возможные решения: Либо

Создание круговой дизайн, дать ссылки:

• куб.см ссылка на заказ,
• клиент ссылка на сс
• клиента реф заказать

или

исх 0

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

По существу, оба модели одинаковы, но переводить по-другому, мне нравится последний вариант лучше всего на данный момент времени, потому что он кажется менее круглым и более центральным. (Если что даже имеет смысл)

Мои вопросы,

• Что делать, если какой-либо плюсы и минусы каждого из них?
• Каковы подводные камни круговых связей/зависимостей?
• Является ли это допустимым исключением из правила?
• Есть ли какая-то причина, по которой я должен выбрать бывшего над последним?

Спасибо и дайте мне знать, если вам что-то необходимо разъяснить/объяснить.

--update/Edit--

Я заметил ошибку в требованиях я заявленных. В принципе, выпал мяч при попытке упростить вещи для SO. Для Платежей есть еще одна таблица, которая добавляет другой слой. Улов, Заказы могут иметь несколько платежей, с возможностью использования разных кредитных карт. (если вы действительно хотите узнать даже другие способы оплаты).

Сформулируйте это здесь, потому что я думаю, что основная проблема остается прежней, и это действительно добавляет еще один уровень сложности.

Answer 1

Клиент может иметь 0 или более кредитных карт, но ассоциация является динамичной - она ​​может приходить и уходить. И, как вы указываете, кредитная карта может быть связана с несколькими клиентами. Таким образом, это становится таблицей n: m, возможно, с столбцом флага для «active».

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

Answer 2

Хм?

У клиента есть несколько кредитных карт, но только текущий. В заказе есть одна назначенная карта. Когда клиент что-то делает, его карточку по умолчанию проверяется первым, иначе он может изменить свою основную карту?

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

• Заказчик: ид, текущая карта
• Кредитные карты: идентификационный номер, номер, customer_id
• Заказ: идентификатор, Card_id, customer_id

Edit: Ой, забыл поле, спасибо.

Answer 3

Я думаю, что проблема заключается в моделировании заказа. Вместо одного ордера есть одна кредитная карта, заказ должен быть связан с более чем одной кредитной картой, из которой только один активен в любое время. По сути, заказ и кредит - это многие ко многим. Чтобы смоделировать это в БД, вам нужно ввести таблицу ассоциаций, скажем, PaymentHistory. Теперь, когда заказ требует новой кредитной карты, вы можете просто создать новую кредитную карту и связать ее с заказом и пометить ассоциирующуюся PaymentHistory как активную.

Answer 4

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

Это пригодится, когда вы меньше всего этого ожидаете.

Answer 5

Это год, но есть моменты, которые стоит сделать.

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

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

КЛИЕНТЫ СЧЕТА: Единственным исключением было бы, если кто-то открыл учетную запись и предоставил информацию о своей кредитной карте для использования в последующих покупках. В таком случае изменения информации о кредитной карте будут происходить за пределами транзакции - в рамках процесса управления учетной записью.

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