Опасности гипер-нормализации? - PullRequest
3 голосов
/ 20 января 2009

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

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

Поскольку ранний сравнительный анализ показывает, что это приведет к значительному снижению производительности, они создали слой кэширования в коде приложения, который поддерживает денормализованные версии каждого типа данных. Хотя это ускоряет запросы, я скептически отношусь к сложности, с которой столкнется прикладной уровень, но я надеюсь на обратную связь - я пессимистичен? Успешно ли другие внедрили этот тип решения? Должен ли я придерживаться своего оружия, или это хорошая вещь - перевести сложность с «Инструменты модификации схемы» на «Инструменты зеркалирования схемы»?

Ответы [ 4 ]

11 голосов
/ 20 января 2009

Нормализованные схемы попали узкие места производительности в прошлом, и основной рефакторинг был по расписанию. Одна из групп разработчики хотят хранить каждый свойство типов данных в отдельная таблица, так что изменения в типы данных никогда не потребуют схемы изменяющее. (Одно свойство может быть превратились в отношения 1: n, для Например, просто изменив приложение логика.)

Это звучит как плохая идея для меня.

  1. Это ухудшит производительность вашей базы данных. Если вы храните эти вещи в одном ряду, они будут физически размещаться вместе на диске и рассматриваться как одно целое для целей блокировки и т. Д.
  2. Запросы, которые вы пишете, потребуют массу дополнительных объединений и будут очень болезненными. Вы закончите писать представления, чтобы превратить его в то, что он должен был быть в первую очередь.
  3. Описанный сценарий может никогда не произойти, поэтому вы замедлили и усложнили свое приложение, потенциально не принеся пользы,
  4. Если это произойдет, и вам придётся перекодировать и протестировать кучу кода приложения, что за небольшие дополнительные усилия по внесению изменений в базу данных в это время? Вы можете создать свою дочернюю таблицу, скопировать в нее данные с обновлением и удалить столбец из родительской таблицы
  5. Если вы добились успеха, в будущем к вашей базе данных может присоединиться другое приложение. Они не смогут сказать, что такое настоящая схема, потому что эта информация хранится в вашем приложении. Данные модели в базе данных.
  6. Кэш на сервере приложений может стать сложным, если (а) слишком много места в памяти, (б) вы масштабируете до нескольких серверов приложений, (в) у вас другое приложение, которое подключается к вашей базе данных. Вы работаете над проблемой производительности, которая является вашей собственной работой.
  7. Вы не сможете создать индекс для нескольких столбцов, если каждый из них живет в дочерней таблице.
5 голосов
/ 20 января 2009

То, что вы описываете, не похоже на то, что я называю нормализацией. Это больше похоже на гиперабстракцию - пытаться найти какой-то уровень абстракции, из которого можно извлечь все остальное. Как «Объект» в JavaScript. Если вы доведите это до логического завершения, вы можете обойтись двумя таблицами; одна таблица для каждого объекта, со столбцом для ObjectTypeCode и ObjectId; и еще одна таблица со связями, имеющая два столбца ObjectId, третий для уникальности и четвертый для значения.

Я предлагаю вам пересмотреть модель вашего домена. То, что вы описываете, звучит для меня страшно (но, к сожалению, до боли знакомо). У меня был парень, который работал на меня, который изобрел стол под названием «Объекты». Было две дочерние таблицы, ObjectAttributes и ObjectProperties. Было трудно получить четкое объяснение различий между ними. Стол (и он, к счастью) не продлился долго.

2 голосов
/ 20 января 2009

Строго говоря, не существует такой вещи, как «гипернормализация». Если полностью нормализованная схема преобразуется в другую эквивалентную полностью нормализованную схему, они оба одинаково нормализуются. То, что часто называют «гипернормализацией», на самом деле является декомпозицией таблицы для достижения целей, отличных от нормализации.

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

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

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

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

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

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

0 голосов
/ 20 января 2009

Наша доброжелательная SO-команда взялась за эту тему: Возможно, нормализация не является нормальной .

Вывод -

По мере того как старая поговорка нормализуется, пока не болит, денормализуется, пока не заработает

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