Anatoly PodgoretskyХрани яйца в одной корзине.
Остальное для лукавого, заранее раскладывание граблей.
Ну почему же. Денормализация для повышения скорости вполне оправданна. Или я не прав?

ЗЫ
Под денормализацией в данном случае я имел ввиду хранение и даты, и других нужных полей (День-Месяц-Год-Часы-минуты-секунды), фигурирующих в запросах как отдельные атомы.

mir sqllexНу почему же. Денормализация для повышения скорости вполне оправданна. Или я не прав?

Под денормализацией в данном случае я имел ввиду хранение и даты, и других нужных полей (День-Месяц-Год-Часы-минуты-секунды), фигурирующих в запросах как отдельные атомы.
Если у вас есть чрезвычайно критичный по времени запрос, часто выполняемый, типа "отобрать записи за всю историю, но такие, у которых час=13", то о такой оптимизации можно подумать. Но не раньше.

Кроме того, и в этом случае есть альтернативы. Например, можно создать вычислимое поле "час" и проиндексировать его.

В большинстве случаев, для эффективного выполнения запросов с условием на элемент даты/времени (типа "час" = 13) достаточно добавить в WHERE эффективно сужающее интервал времени условие типа "MyTime" BETWEEN "left" AND "right", где поле "MyTime" проиндексировано. Обычно в интервал попадает не такое уж большое количество записей, чтобы последующиё перебор по ним с условием "час" = 13 был недостаточно быстрым.
Именно это я имел ввиду. Само собой, обычно решение о денормализации принимают после получения статистики использования БД. Особое спасибо за дополнительные коментарии.
Но кроме использования части даты в предикате where может быть понадобиться получение в запросе отдельно дня/года/часа/минуты...
Поэтому, не будет ли разумным заранее добавить (кстати, вычислимое поле - та же денормализация) нужные поля при интенсивной работе с частью даты-времени?
Может быть кто-то уже сталкивался с подобной задачей и делал тесты на реальной базе. Поделитесь, плз, результатами.

Александр Волок (def1983).
Я тоже обычно придерживаюсь этой точки зрения, но что думаете по вышенаписанному?

Александр Волок (def1983)
Что касается SQL Server, то функция Datepart довольно производительна, и, имхо, издержки на добавление и хранение нового столбца вряд ли будут сильно отличаться от простого использования DatePart + DateTime типа.

(зы. Разговор идет о приземленных олтп системах)

Даже не смотря на то, что результат DatePart не будет проиндексирован (вычисляемые колонки - то же излишество, индексируемые представления в олтп системах скажутся на производительности)?

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