Нам нужно создать несколько таблиц с единственной целью отчетности в Oracle.Какая структура таблицы лучше
Вариант 1
дебиторов Таблица
Вариант 2
дебиторов Таблица
Примечание: Для данной Код ссылки для всех типов налога, сбора и премии или подмножество из них ca n существует.
Что бы оптимальную структуру (таблицы будут иметь более 100к записей)
Ни один из них на самом деле не лучший (с точки зрения DBA). Лучше всего было бы (при условии Код ссылки является уникальным и, следовательно, первичный ключ):
Receivables:
RefNo
Date
ReceivableDollarVals:
RefNo
Type
Amount
Если Код ссылки/Дата является первичным ключом, добавить дату второй таблицы, а также.
Это позволяет свести к минимуму пространство для хранения для тех строк, которые не имеют всех трех типов (хотя сбережения минимальны). Затем вы используете предложения WHERE, объединяющие две таблицы (или JOIN s) для выполнения ваших запросов.
Он также позволяет вам добавлять другие типы по желанию без реструктуризации базы данных.
Однако вам нужно иметь в виду, что третья нормальная форма является идеалом. Довольно приемлемо нарушать правила, чтобы повысить производительность, если вы понимаете последствия.
100 000 записей на самом деле довольно мало, поэтому, если вы не думаете, что собираетесь собирать больше типов в ближайшем будущем, я бы выбрал вариант 2 и использовал нули для тех значений, которые не существуют. NULL, скорее всего, сделают ваши запросы немного более сложными.
+1. Он также не может дать разные даты для того же RefNo. – mghie
Сохранение данных в скрытых полях, а не в отдельных строках, не обязательно является нарушением 3NF. Нарушение 3NF будет означать, что значения напрямую не связаны с первичным ключом (refno). Я был бы очень удивлен, если бы это было так. –
Хорошая точка, @Adam, поскольку 3NF - это всего лишь столбец, зависит от ключа, всего ключа и ничего, кроме ключа. Мы по-прежнему разрабатываем наши таблицы, чтобы избежать способов, заданных в вопросе, но это потому, что мы склонны иметь множество столбцов, которые могут быть NULL. Может быть, мне следует назвать мой подход 3.5NF :-) – paxdiablo
Если типы транзакций явно определены и вряд ли будет малонаселенных (то есть, большинство записей будет иметь значения для всех 3), то последний скорее всего, станет вашим лучшим вариантом. Он также представляет данные в формате, который ближе к тому, как вы думаете об этом на самом деле.
Даже если значения могут быть разреженными, «инстинкт кишки» заставляет меня по-прежнему опираться на подход, основанный на столбцах, а не на основе строк.
Реальное преимущество полностью нормализованной версии в первом ответе возникает, когда требования меняются - когда кто-то меняет спецификации, поэтому вам нужно добавлять типы за пределы 3, которые вы идентифицировали.
Как скидка, возврат денег, что угодно. Эти изменения происходят.
Нормализованная структура должна позволить вам сделать это более легко, без необходимости изменять структуру таблицы или большую часть программ, которые используют данные.
Но нормализованная структура требует больше инвестиций в начале - каждая новая транзакция включает вставки в 2-х таблиц, вам необходимо иметь проверочное ограничение для контроля типов и т.д.
Как правило, вы будете делать лучше в долгосрочной перспективе с нормализованной структурой. Однако, с простым случаем, вы можете иногда уйти без нормализации и не платить за последствия (по крайней мере, никто не должен платить, пока вы давно не ушли, и это чужая проблема).
Профессионально, разумные уровни нормализации должны быть вашей стандартной стратегией, и вы должны требовать, чтобы у вас были очень веские причины для денормализации.
Если таблица будет иметь более 100 тыс. Записей. Тогда вариант 2 - хороший выбор. Вариант Bcz 1 замедляет доступ к данным.
Вы сказали «С единственной целью сообщить». Означает ли это, что данные выводятся в Oracle из какой-либо другой системы. Если это так, это означало бы, что дизайн не должен беспокоиться о нормализации для целей обновления/целостности. –