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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уволиться.

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

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

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

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

Удачи.

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