Денормализация для простоты: плохая идея?

Прочитав этот вопрос, я узнал, что денормализация не является решением проблемы простоты. А что насчет этого дела?

У меня есть новостные статьи со списком сайтов, на которых будут опубликованы статьи. Последнее может быть выражено нормализованным образом либо таблицей, либо отношением «многие ко многим» (я думаю, через кросс-таблицу). Но простое решение - просто добавить кучу логических значений для сайтов-статей-будут-опубликованы-на (publish_to_site_1, publish_to_site_2 и т. Д.). Предполагая, что это сайты:

  1. небольшое количество
  2. не изменится со временем
  3. не имеют самих полей, кроме имени

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

Примечание. Я делаю это в Rails, где это не так уж больно. С другой стороны, метапрограммирование делает такие вещи тривиальными.

(1..5).each { |site| do_something(article["publish_to_site_#{site}".to_symbol]) }

database-design denormalization
person Dan Rosenstark    schedule 20.05.2010    source источник
comment
+1 за использование нехорошего в заголовке.   -  person ponzao    schedule 20.05.2010
comment
@ponzao, да, мне показалось правильным задать вопрос о целой кучке логических значений.   -  person Dan Rosenstark    schedule 20.05.2010

Ответы (4)


arrow_upward
3
arrow_downward

Если эти условия действительно выполняются, тогда нет, это неплохая идея.

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

Итак, это нормально (нормализовано):

article                        show_on_stackoverflow    show_on_my_blog
-----------------------------------------------------------------------
Denormalize for Simplicity             YES                     NO
More simplicity                        YES                     YES
...

Но это не нормально (избыточность):

article                        show_on_stackoverflow    stackoverflow_mainpage_url   show_on_my_blog    my_blog_mainpage_url
------------------------------------------------------------------------------------------------------------------------------
Denormalize for Simplicity             YES              http://stackoverflow.com            NO          http://my.blog.url       
More simplicity                        YES              http://stackoverflow.com            YES         http://my.blog.url
...
person Heinzi    schedule 20.05.2010
comment
Это правда, но заставляет меня думать, что почти без всякой выгоды я запираю себя в болезненное будущее, если что-то изменится. Плохо. - person Dan Rosenstark; 20.05.2010
comment
Точно. Если есть вероятность, что вам понадобятся дополнительные поля в будущем, лучше вложить еще несколько объединений сейчас, чем потом все перепроектировать. - person Heinzi; 20.05.2010
comment
Мне нравится, что вы приняли вопрос за чистую монету и не читали мне лекции об очевидном: что вы, вероятно, никогда не соблюдаете эти условия на самом деле. Данные имеют тенденцию привлекать данные или что-то в этом роде, поэтому show_on_so неизбежно получает другое поле ... так что вы получаете избыточность (как во втором примере), а затем это денормализовано для простоты, что плохо. - person Dan Rosenstark; 21.05.2010
comment
Вы можете реализовать новые поля как новые таблицы и просто присоединиться к ним. - person Seun Osewa; 25.05.2010

arrow_upward
2
arrow_downward

Предположение два нереально.

Поэтому в полном соответствии с «Если эти условия действительно выполняются, то нет, это не страшная идея». : да, это ужасная идея.

person Erwin Smout    schedule 21.05.2010
comment
Я проголосую за это, потому что я пришел к такому же выводу в моем случае (на самом деле я думаю, что №3 также большую часть времени нереалистично), но я все же думаю, что мы должны быть осторожны: это не нереально, если это реально : Это очень маловероятно, но у вас может быть дело (возможно, на основании некоторых юридических критериев), в котором оно будет удовлетворено. - person Dan Rosenstark; 22.05.2010

arrow_upward
0
arrow_downward

Если вы думаете о логических значениях «sites-article-will-be-published-to» просто как об атрибутах первичных данных, таких как «isGreen», «hasHair», «isBipedal», то одна таблица нормализуется в том смысле, что было бы неправильно иметь внешний ключ к таблице Green{<true>, <false>}.

Очевидно, что если ваши 3 условия не будут по-прежнему выполняться, следующему парню придется выполнить нетривиальную работу, но «как можно проще, но не проще» имеет свою полезность.

person msw    schedule 20.05.2010
comment
Извините, я не понял. Другая таблица будет «Характеристики» (в вашем примере) и будет содержать такие символы, как зеленый и двуногий. - person Dan Rosenstark; 20.05.2010

arrow_upward
0
arrow_downward

Лично я бы не стал денормализовать. На мой взгляд, одно отношение n: n не так уж и громоздко, если вы знакомы с SQL. Что может быть обременительным, так это использование денормализованной структуры для разных запросов. Например, вы уверены, что вам никогда не понадобится список всех сайтов, на которых публикуется статья ...?

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

Ура Матиас

person Matthias Meid    schedule 20.05.2010