Я был воспитан в старой школе - где мы научились проектировать схему базы данных ДО бизнес-уровня приложения (или использовать OOAD для всего остального). Я был довольно хорош в разработке схем (IMHO :) и нормализовался только для удаления ненужной избыточности, но не там, где это влияло на скорость, т. Е. Если объединения были снижением производительности, избыточность оставалась на месте. Но в основном это было не так.
С появлением некоторых сред ORM, таких как ActiveRecord в Ruby или ActiveJDBC (и некоторых других, которые я не могу вспомнить, но я уверен, что их много), кажется, что они предпочитают иметь суррогатный ключ для каждой таблицы, даже если у некоторых есть первичные ключи, такие как «электронная почта» - сломать 2NF сразу. Хорошо, я понимаю не слишком много, но это действует мне на нервы (почти), когда некоторые из этих ORM (или программистов) не признают 1-1 или 1-0 | 1 (то есть 1 к 0 или 1). Они утверждают, что лучше иметь все как одну большую таблицу, независимо от того, есть ли у нее тонна nulls
«сегодняшние системы могут с ней справиться» - это комментарий, который я слышал чаще.
Я согласен, что ограничения памяти имели прямую связь с нормализацией (есть и другие преимущества :), но в наше время с дешевой памятью и четырехъядерными машинами концепция нормализации БД оставлена только текстам? Как администраторы баз данных вы все еще практикуете нормализацию до 3NF (если не BCNF :)? Это имеет значение? Хороший ли дизайн «грязной схемы» для производственных систем? Только как следует обосновать «нормализацию», если она все еще актуальна.
( Примечание: я не говорю о схемах типа «звезда / снежинка» хранилища данных, которые имеют избыточность как часть / необходимость проектирования, а о коммерческих системах с внутренней базой данных, такой как StackExchange, например)