Денормализовывание для исправности или производительности?
Мы используем хранимые процедуры с DB Oracle, где я работаю теперь. Мы также используем Подрывную деятельность. Все хранимые процедуры создаются как .pkb & файлы .pks и сохраненный в Подрывной деятельности. Я сделал встроенный SQL прежде, и это - боль! Я очень предпочитаю способ, которым мы делаем это здесь. Создание и тестирование новых хранимых процедур намного легче, чем выполнение его в Вашем коде.
Theresa
7 ответов
Я не знаю, назвал бы я то, что вы хотите сделать денормализацией - это больше похоже на то, что вы просто хотите заменить искусственные внешние ключи (StateId, AgencyId) с естественными внешними ключами (аббревиатура государства, код агентства). Использование полей varchar вместо целочисленных полей замедлит производительность соединения / запроса, но (а) если вам даже не нужно присоединяться к таблице большую часть времени, потому что естественный FK - это то, что вы хотите в любом случае, это не имеет большого значения и ( б) ваша база данных должна быть довольно большой / иметь высокую нагрузку, чтобы она была заметна.
Но djna прав в том, что вам нужно полное понимание текущих и будущих потребностей, прежде чем вносить подобные изменения. Вы УВЕРЕНЫ, что трехбуквенный код агентства никогда не изменится, даже через пять лет? Правда, правда?
Создать представление (или встроенная функция с табличным значением для параметризации). В любом случае, я обычно помещаю весь свой код в SP (некоторый сгенерированный код) независимо от того, используют ли они представления или нет, и все, вы почти всегда пишете соединение только один раз.
Аргумент (для этой «нормализации»), что трехбуквенные коды могут измениться, не очень убедителен без плана того, что вы будете сделайте, если коды действительно изменятся, и то, как ваш сценарий с искусственным ключом решит эту проблему лучше, чем использование кодов в качестве ключей. Если вы не реализовали полностью временную схему (что ужасно сложно сделать и не предлагается в вашем примере), это ' Мне не очевидно, какая польза от нормализации для вас вообще. Теперь, если вы работаете с агентствами из разных источников и стандартов, которые могут иметь конфликтующие кодовые названия, или если «штат» может в конечном итоге означать двухбуквенный код штата, провинции, департамента, кантона или эстадо, это другое дело. Затем вам потребуются собственные ключи или ключ из двух столбцов с дополнительной информацией, чем этот код.
Ну, а как насчет производительности ? Если производительность в порядке, просто сделайте пять таблиц JOIN в представлении и, для разумности, выберите SELECT из представления, когда вам нужны данные.
Сокращения состояний - один из тех случаев, когда я думаю, что значимые ключи в порядке. Для очень простых таблиц поиска с ограниченным числом строк и где я полностью контролирую данные (то есть они не заполняются из какого-либо внешнего источника) я иногда создаю значимые четырех- или пятисимвольные ключи, чтобы значение ключа могло прокси для полностью описательного значения поиска в некоторых запросах.
Some denormalization can be needed for performance (and sanity) reasons at some times. Hard to tell wihout seeing all your tables / needs etc...
But why not just build a few convenience views (to do a few joins) and then use these to be able to write simpler queries?
This previous post dealt with a similar issue to the one you're having. Hopefully it will be helpful to you.
Dealing with "hypernormalized" data
My own personal take on normalization is to normalize as much as possible, but denormalize only for performance. And evn the denormalization for performance is something to avoid. I'd go the route of profiling,setting correct indexes, etc before I'd denormalize.
Sanity... That's overrated. Especially in our profession.
Остерегайтесь желания привести вещи в соответствие с вашими текущими идиомами. Прямо сейчас незнакомый код кажется неприятным и мешающим вашему пониманию. Со временем возможно, что вы акклиматизируетесь.
Если текущие (или известные будущие) требования, такие как производительность, не выполняются, то это совсем другая проблема. Но помните, что все можно настроить на производительность, цель не в том, чтобы сделать что-то как можно быстрее, а в том, чтобы сделать это достаточно быстро.