Нормализация базы данных: использование отдельных таблиц для хранения одного поля

Question

В настоящее время наша база данных настроена таким образом, что платежные транзакции записывают идентификатор типа платежа, и это связано с таблицей типов платежей (наличными, чеками, кредитами), которая содержит эти значения. Пример:

Платежная операция:

• ID
• Сумма
• Дата
• Тип платежа ID

Тип оплаты:

• ID
• Тип оплаты (Наличные, Кредит)

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

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

Насколько я могу сказать, "за" и "против" замены таблицы типов платежей одним полем будет:

Плюсы

• Удаляет практически ненужное объединение всякий раз, когда необходимо найти тип платежа.
• Тип платежа для транзакции всегда будет точно соответствовать тому, что было на момент записи транзакции. Т.е. если я поменяю запись «Денежные средства» в таблице типов платежей на «Кредит» (по какой-либо причине), все платежные транзакции, связанные с «Денежными средствами», теперь будут связаны с «Кредитом».

Минусы

• Сохранение типа платежа в виде текстового поля замедлит сортировку по типу платежа и сделает такой вид более запутанным, чем сейчас.
• Вид платежа для транзакции всегда будет точно отражать то, что было на момент записи транзакции. Т.е., если бы у меня была опечатка, а тип платежа был сохранен как 'Kash', я мог бы легко исправить эту опечатку, и все транзакции, связанные с этим типом платежа, будут автоматически обновлены.

Я склоняюсь к удалению таблицы типов платежей и добавлению единственного поля в таблицу транзакций платежей. Как вы посоветуете наилучший способ действий?

Answer 1

Я не согласен ни с одним из ваших доводов "за".

Удаляет в большинстве случаев ненужное объединение всякий раз, когда необходимо найти тип платежа.

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

Тип платежа для транзакции всегда будет точно отражать тот, который был на момент записи транзакции.То есть, если я изменю запись «Наличные» в таблице типов платежей на «Кредит» (по какой-либо причине), все платежные транзакции, которые ссылаются на «Деньги», теперь будут связаны с «Кредитом».

Вы не должныразрешить кому-либо изменять способ оплаты таким образом.Изменение типа платежа должно быть другой транзакцией с собственной меткой времени.

Любая реляционная база данных может обрабатывать JOIN и нормализованные таблицы.Боюсь, ты виновен в преждевременной оптимизации.

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

Answer 2

Если вы удалите таблицу PaymentType, вы замените проверку внешнего ключа на ограничение таблицы CHECK:

PaymentType   CHAR(6) NOT NULL CHECK(PaymentType IN('Cash', 'Credit', 'Cheque')

ОК & mdash; вы пишете «чек» как «чек»; просто еще одно различие между английским и американским.

Теперь это значительно затрудняет поиск возможных значений; Вы должны проанализировать системный каталог, чтобы узнать. С отдельной таблицей вы можете изучить отдельную таблицу, чтобы узнать, что разрешено. Предположим, вы начали отслеживать «Дебет» отдельно от «Кредит»; Вы добавляете строку в таблицу против изменения схемы таблицы. Предположим, вы решили записать, какие коды разрешены в будущих транзакциях (поэтому «Наличные» перестают быть опцией). Вы можете добавить столбец в таблицу Тип оплаты, чтобы указать, что этот код больше не действителен; гораздо сложнее сделать это с простым ограничением CHECK.

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

Если бы это был мой дизайн, я бы, вероятно, использовал бы код CHAR (1) или CHAR (2) в качестве идентификатора для типа платежа, а не числовой столбец. Конечно, все три типа начинаются с «C», поэтому, возможно, вы бы использовали «A» для cAsh, «H» для cHeck и «R» для cRedit (и, возможно, «D» или «E» для дебета или dEbit) с кодом CHAR (1); с CHAR (2) вы бы использовали «CA», «CH», «CR» (и, возможно, «DE»). Полное имя можно сохранить в таблице типов платежей для использования в отчетах. В этом случае преимущества невелики, но экономят 4 байта на запись на достаточном количестве записей (достаточно большое количество достаточно маленьких записей), и это может стать фактором затрат на хранение. Конечно, индексные накладные расходы также вступают в игру; если столбец в таблице «Платежная операция» должен быть проиндексирован, то поле меньшего размера использует меньше места для индекса.