ERD: как хранить данные для трех разных типов платежей - PullRequest
0 голосов
/ 13 ноября 2018

Допустим, у пользователя есть 3 различных способа оплаты. Наличные, IBAN, и через предоставление определенного_документа. Каждый тип оплаты требует своих различных деталей.

Как я могу сохранить это в моей базе данных?

Допустим, пользователь выбрал оплату, используя свой IBAN, при условии, что эта картинка является текущей базой данных, заполняю ли я поля, связанные с опцией IBAN, и устанавливаю для остальных значение Null? Или есть более профессиональный способ хранения данных без этих нулевых значений?

UPDATE

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

1 Ответ

0 голосов
/ 13 ноября 2018

Как заметил @philipxy, вы спрашиваете о представлении наследования в СУБД. Есть несколько способов сделать это:

  1. Соберите все свои атрибуты в одной таблице (которая, согласно вашему скриншоту, является тем, что у вас есть сейчас). При таком подходе было бы лучше хранить NULL s в неприменимых столбцах - если не указано иное, в настройках по умолчанию для таблиц InnoDB используется компактный формат строк, что означает, что столбцы NULL не занимают дополнительной памяти. Конечно, ваши запросы могут быть сложными, и ведение этих таблиц может стать громоздким.
  2. Имеют дочерние таблицы для хранения ваших данных:

    • Payments (PaymentID, PaymentDate, etc.)
    • CashPaymentDetails(PaymentID, Cash_Detail_1, Cash_Detail_2, etc.)
    • IBANPaymentDetails(PaymentID, IBAN_Detail_1, etc.)
    • Информацию для каждого платежа можно получить, соединив таблицу базовых платежей с одной из «вспомогательных» таблиц:

      SELECT * FROM Payments P INNER JOIN CashPaymentDetails C ON C.PaymentID = P.PaymentID

  3. Третий вариант - использовать модель «сущность-атрибут-значение» (EAV). Как и в варианте 2, у вас есть базовая таблица платежей. Однако вместо одной таблицы для каждого способа оплаты у вас есть одна вспомогательная таблица, содержащая детали платежа. Для получения дополнительной информации - это страница Wiki , а - блог с дополнительной информацией.

...