Должен ли я денормализовать таблицы «Кредиты», «Покупки» и «Продажи» в одну таблицу?

Question

Основываясь на информации, которую я предоставил ниже, не могли бы вы высказать свое мнение о том, является ли хорошей идеей денормализация отдельных таблиц в одну таблицу, в которой содержатся различные типы контрактов? .. Что такое за / против? .. кто-нибудь пытался сделать это раньше? .. Банковские системы используют CIF (файл информации о клиенте) [master], где клиенты могут иметь разные типы счетов, CD, закладные и т. д. и использовать коды транзакций [типы], но хранят ли они их в одной таблице

У меня есть отдельные таблицы для транзакций по кредитам, покупкам и продажам. Строки из каждой из этих таблиц присоединяются к соответствующему клиенту следующим образом:

customer.pk_id SERIAL = loan.fk_id      INTEGER; 
                      = purchase.fk_id  INTEGER; 
                      = sale.fk_id      INTEGER;  

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

Contracts.Type char(1) {L=Loan, P=Purchase, S=Sale}

Сценарий:

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

Я разработал общую таблицу, где, например:

Contracts.Capital DECIMAL(7,2) 

в кредитном договоре он содержит основную сумму залога, в покупке - цену покупки, в продаже - цену продажи.

Является ли этот дизайн хорошей идеей или я должен держать их отдельно?

Answer 1

Ваш стол второго дизайна лучше, и, "нормализован".

Ваш первый дизайн был денормализован!

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

Существует два способа моделирования этого. Если переменные данные минимальны, вы храните все что угодно в одной таблице со специфическими атрибутами типа транзакции, содержащимися в столбцах типа «NULL». (По сути, это ваш случай, и вы сделали правильную вещь!).

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

Однако, в то время как «КРЕДИТ», «ПОКУПКА» и «ПРОДАЖА» действительны как транзакции. Я думаю, что Inventory - это отдельная сущность, и у нее должна быть отдельная таблица. По сути, «КРЕДИТ» добавит к инвентарной транзакции, «ПОКУПКА» изменит состояние инвентаря на «Продаваемый», а «ПРОДАЖА» удалит элемент из инвентаря (или изменит статус на проданный). После того, как предмет добавлен в инвентарь, должен измениться только его статус (это все еще виджет, скрипка или что-то еще).

Answer 2

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

Здесь есть вопрос? Вы просто ищете подтверждение, что это приемлемо?

Гипотетически, что бы вы сделали, если бы подавляющее согласие состояло в том, что вам следует вернуться к отдельным таблицам для каждого типа? Игнорируете ли вы доказательства из собственного опыта (лучшая производительность, простое программирование) и следовали бы советам Stackoverflow.com?