Круговые базы данных отношений. Хорошо, плохо, исключения?

Question

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

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

• CreditCard
• Клиент
• Заказать

Я хочу это так,

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

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

Фактически это создает круговую схему между тремя таблицами.

Возможные решения: Или

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

• cc ref на заказ,
• ссылка клиента в куб. См.
• клиент ref на заказ

или

• ссылка клиента в куб. См.
• клиент ref на заказ
• создайте новую таблицу, которая ссылается на все три идентификатора таблицы, и поместите уникальные в ордер, чтобы только один cc мог быть текущим для этого ордера в любое время

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

Мои вопросы,

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

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

- Update / Edit -

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

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

Answer 1

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

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

Answer 2

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

Answer 3

Хм?

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

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

• Клиент: id, текущая карта
• Кредитные карты: id, номер, customer_id
• Заказ: id, идентификатор карты, идентификатор клиента

Редактировать: Упс, забыл поле, спасибо.

Answer 4

Это год, но стоит кое-что сделать.

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

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

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

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

Answer 5

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

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