Какая структура таблицы лучше

Question

Нам нужно создать несколько таблиц с единственной целью составления отчетов в Oracle.

Вариант 1

Таблица дебиторской задолженности

• 1010 * Код ссылки *
• Дата
• TrnType, например: Налог, Плата, Премиум
• Сумма

Вариант 2

Таблица дебиторской задолженности

• 1026 * Код ссылки *
• Дата
• Tax
• Плата
• Premium

Примечание. Для данного RefNo могут существовать все типы налогов, сборов и премий или их подмножество.

Какова будет оптимальная структура (в таблицах будет более 100 тыс. Записей)

Answer 1

Ни один из них на самом деле не лучший (с точки зрения того, как думают администраторы баз данных). Лучшим будет (при условии, что RefNo уникален и, следовательно, является первичным ключом):

Receivables:
    RefNo
    Date
ReceivableDollarVals:
    RefNo
    Type
    Amount

Если RefNo / Date является первичным ключом, добавьте дату и ко второй таблице.

Это позволяет минимизировать пространство хранения для тех строк, которые не имеют всех трех типов (хотя экономия минимальна). Затем вы используете предложения WHERE, объединяющие две таблицы (или JOIN s) для выполнения ваших запросов.

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

Однако вам нужно помнить, что третья нормальная форма - это идеал. Вполне допустимо нарушать правила, чтобы повысить производительность, если вы понимаете последствия.

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

Answer 2

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

Как скидка, возврат денег, что угодно. Эти изменения случаются.

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

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

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

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

Answer 3

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

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

Answer 4

Если в таблице будет более 100 тыс. Записей. Тогда вариант 2 является хорошим выбором. Вариант 1 Bcz замедляет доступ к данным.