Как я могу убедительно спорить против дублирования столбцов базы данных?

47

Я начал работать в новой организации, и одним из шаблонов, которые я видел в базе данных, является дублирование полей, чтобы упростить написание запросов для бизнес-аналитиков. Мы используем Django и его ORM.

В одном случае мы сохраняем объект MedicalRecordNumber с уникальной строкой, идентифицирующей пациента в определенном контексте. У нас есть объекты регистрации, которые отслеживают пациентов и имеют связанные с ними номера MedicalRecordNumbers , но вместо того, чтобы использовать отношение внешнего ключа, они дублируют строку, чтобы избежать написания соединения ( не по соображениям производительности). Этот шаблон распространен во всей базе данных.

Для меня важна чистота модели данных, поэтому я могу хорошо об этом думать. Излишняя сложность - пустая трата моего ограниченного времени на когнитивную обработку. Это систематическая проблема. Неудобство написания объединений - это исправимая проблема навыков. Я не обязательно хочу выступать за возвращение и изменение схемы, но я бы хотел, чтобы была возможность убедительно сформулировать проблемы с этим типом дублирования.

canisrufus
источник
2
Что значит «не удобно писать письма»? Как они это объясняют?
скрипт
9
Эти люди работают на вас? Вы их руководитель? Большинство ваших обоснований можно найти здесь: en.wikipedia.org/wiki/Database_normalization . Да, они должны стать лучше при использовании объединений.
Роберт Харви
1
Вы искали литературу о том, почему нормализация желательна?
Натан Тагги
17
Разве добавление представлений, которые делают объединение внутри, не делает написание запросов столь же простым? Вы могли бы предложить их в качестве альтернативы.
CodesInChaos,
1
Вы вежливо сообщали об этом своим сверстникам и пожилым людям? Каковы их оправдания, какие соображения они делают? Есть много возможных причин, почему это может быть хорошей идеей (даже если вы говорите, что «производительность не является причиной», какие доказательства вы должны поддержать?). Прежде чем обвинить их в том, что они слишком ленивы и / или жестки, рассмотрели ли вы (и спросили) причины, по которым у них такой дизайн? Может быть, там гораздо больше операций чтения, чем записи (аналитика тяжелой БД)? Отслеживание изменений? Исторические данные? Спросите всех - кто-то может знать настоящую причину.
Luaan

Ответы:

128

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

Ваша аналитическая база данных (склад) должна быть сильно денормализована, чтобы облегчить анализ.

Если у вас нет отдельной аналитической базы данных, вам следует сделать несколько сильно денормализованных [материализованных] представлений.

Если вы скажете своим старшим бизнес-аналитикам / менеджерам сделать много объединений для простого анализа, вы можете быть уволены.

Agile Data Warehouse Design - хорошая книга

Смотрите мои быстрые и грязные советы хранилища данных здесь

Нил Макгиган
источник
9
Это правильный путь.
Нить
6
+1 Это именно то, для чего предназначены представления: разрешить денормализованное представление в нормализованной базе данных.
Nzall
4
Абсолютно правильно, но я думаю, что «уменьшить аномалии» следует подчеркнуть больше, так как это основной ответ на вопрос. Наиболее распространенная (только?) Аномалия, которую вы увидите при дублировании / денормализации данных, заключается в том, что столбцы будут каким-то образом заполняться противоречивыми данными, в результате чего у вас не будет возможности узнать, какими должны быть реальные данные, и нет способ определить, что пошло не так. Последнее может быть смягчено путем массового отслеживания изменений, но это не будет дешевым или быстрым, чтобы пройти и найти проблему. Более экономически эффективным, чтобы избежать проблемы полностью.
jpmc26
2
Другой аспект, который следует учитывать, заключается в том, что, даже если разработчики способны поддерживать правильность данных (сомнительно), это приводит к огромному расходу их ресурсов, чтобы гарантировать, что каждое дублирующееся поле обновляется, когда это требуется для обеспечения согласованности.
Nate CK
1
@Panzercrisis Единственный способ, которым транзакция является «неявной», - это если у вас есть автоматический коммит, выполняющийся в конце вашего запроса. Обычно это не относится к производственной базе данных. В приложении транзакции должны инициироваться автоматически, а фиксация должна быть выдана отдельно от запроса. Это небольшая первоначальная инвестиция в приложение, но она упрощает изменения кода, которые включают добавление вызовов в базу данных, и уменьшает объем, о котором должен думать разработчик (повышает скорость разработки, уменьшает ошибки разработки). Такой дизайн также хорошо сочетается с такими вещами, как пул соединений.
jpmc26
57

Я понимаю, почему кто-то хочет избежать написания объединения для каждого выбора.

Но вы можете один раз создать представление с помощью объединения и использовать его вместо ненормализованной таблицы.

Таким образом, вы сочетаете преимущество нормализации с удобством простого выбора.

Кнут
источник
12
Взгляды твои друзья. Используйте их свободно. А для производительности вы могли бы даже использовать материализованные представления, если ваша СУБД поддерживает их.
VH-NZZ
13

Ответы, которые уже были одобрены, в значительной степени охватывают «как избежать дублирования» (используя представления), но не объясняют, почему. Они в основном показывают, что дублирование столбцов является неправильным решением проблемы упрощения написания запросов. Но вопрос "почему бы не скопировать какой-либо случайный столбец только ради этого?" все еще стоит.

Ответ: «Из-за закона Мерфи». Закон Мерфи гласит, что:

Если что-то может пойти не так, то так и будет.

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

В качестве примера того, как это может произойти, просто рассмотрите тот факт, что дублированные столбцы не заполняются магией; кто-то должен действительно написать код, который хранит значения в них всякий раз, когда строки создаются в исходной таблице, а кто-то должен писать код, который продолжает обновлять их всякий раз, когда оригиналы модифицируются. Оставляя в стороне тот факт, что это добавляет излишнюю нагрузку к коду, который вводит данные в базу данных (и который по определению гораздо важнее, чем любой код, который просто запрашивает базу данных), кто-то где-то при определенных обстоятельствах может забыть провести это дублирование. Тогда значения будут отличаться. Или они могут не забыть выполнить дублирование, но не в рамках транзакции, так что при определенных условиях сбоя его можно пропустить. Но мне не нужно было тратить свое время на написание этих примеров,если это может пойти не так, как надо.

Майк Накис
источник
12

Думая об этом с точки зрения компромиссов, а не хорошо / плохо будет более продуктивным. Они обменивают преимущества нормализации (особенно согласованности) на преимущества в удобстве использования запросов.

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

Что вы можете сделать, чтобы уменьшить риски и затраты?

  • Создайте инструмент проверки согласованности и регулярно запускайте его.
  • Направьте доступ для записи через программное обеспечение, которое последовательно обновляет реплицированные данные.
  • Добавьте представления или создайте инструменты запросов, которые будут автоматически выполнять объединения, чтобы деловые люди могли думать с точки зрения информации, а не внутренних данных БД.
Jerry101
источник
6

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

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

Oleksi
источник
6
Его люди будут утверждать, что они достаточно хороши, чтобы убедиться, что все данные обновляются должным образом (предпосылка, которую я оспариваю, если им неудобно с объединениями). Возможно, лучшим аргументом является то, что вы теряете большинство преимуществ ACID, которые предоставляют СУБД, если вы отказываетесь от нормализации.
Роберт Харви
4
Возможно, но это все вопрос риска. Готовы ли они принять риск повреждения базы данных, потому что это облегчает запросы?
Олекси
1
Играя адвокат дьявола здесь, очевидным контраргументом будет то, что, если кто-то собирается испортить обновление и все равно испортить данные, это проблема с нормализацией или без нее - и, по крайней мере, наличие некоторой избыточности в базе данных делает ее более вероятной что кто-то заметит коррупцию и, возможно, сможет исправить ее позже. (Конечно, специальная денормализация вряд ли является самой надежной схемой обнаружения ошибок, но принцип проверки ошибок с помощью избыточности обоснован: именно так работает бухгалтерия с двумя записями .)
Ильмари Каронен,
Или, другими словами, целостность данных - это нечто большее, чем просто реляционная целостность. С полностью нормализованной базой данных вы все равно можете поддерживать идеальную целостность отношений, даже если кто-то испортит обновление, но это не сделает некорректно обновленные данные менее мусором.
Илмари Каронен
0

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

Будьте терпеливы и работайте методично. Изменений не произойдет за ночь.

hlosukwakha
источник
0

Уволиться.

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

Или вы можете просто сэкономить время, разочарование и уйти сейчас.

Хорошие программисты очень ленивые люди. Они понимают потребности клиентов и менеджмента. Но самое главное, они понимают, что правильное решение проблем с использованием хорошо спроектированных и хорошо реализованных решений экономит им лично ОГРОМНОЕ количество работы, усилий и, что самое важное, агонию и стресс.

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

Удачи.


Задумка: может быть, им нужны инструменты BI / OLAP ... http://en.wikipedia.org/wiki/Online_analytical_processing

AK_
источник