Вопрос дизайна базы данных (FK для разных таблиц)

Question

Рассмотрим корзину для покупок, позволяющую клиентам использовать переменные платежные системы.

Каждая система имеет свой набор параметров: система A имеет такие атрибуты, как ссылочный идентификатор, xml-ответ, идентификатор транзакции, система B имеет идентификатор транзакции и статус, а система C (чек) имеет только дату платежа.Статусы также различаются в каждой системе.

На странице выбора платежной системы есть название и описание платежной системы, которые также должны храниться в базе данных (например, не жестко закодированы в HTML).

Как бы вы спроектировали базу данных?

Лучшее, о чем я могу думать, - это иметь таблицу для каждой системы + таблицу для описания платежной системы, связывающуюся с именем соответствующей таблицы + 2 дополнительных поля в таблице заказов: идентификатор платежной системы (будет связывать«таблица описания»), идентификатор платежной записи (будет ссылаться на идентификатор в соответствующей таблице платежной системы).Это также позволило бы обеспечить определенную функциональность (обработку уведомлений о заказах и т. Д.) Для разделения между моделями платежных систем вместо использования if s.Это нормально?

Если что, проект основан на PHP 5, Doctrine и MySQL.

Answer 1

Возможно, у вас может быть основная системная таблица, содержащая любую общую информацию (идентификатор, имя и т. Д.), А затем вторая таблица, которая собирает пары имя / значение для атрибутов:

CREATE TABLE system_table
(id int,
name char(50),
...
);

CREATE TABLE system_properties
(system_id int,
name char(50),
value varchar
);

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

Обратите внимание, что SQL создаетВышеуказанные операторы являются псевдокодом.

Answer 2

Одна таблица для каждого типа платежной системы - тип представляет собой уникальный набор атрибутов, общих для одной или нескольких платежных систем. Иметь родительскую таблицу всех этих типов, которая содержит атрибуты, общие для всех (например, имя системы).

Answer 3

Что сказали Дпортас и Джейдель плюс два моих цента.

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

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

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

Короткий ответ: таблица генов имеет классическое поле идентификатора, действующее как PK. Каждая специализированная таблица имеет поле идентификатора, которое является дубликатом поля идентификатора в таблице генов. Это означает, что это и PK в специализированной области, и FK, ссылающийся на таблицу gen.

FK ссылки на платежную систему в другом месте базы данных должны ссылаться на таблицу gen.