Производительность БД и типы данных

Question

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

Соответствующая информация: Приложение интенсивно использует поле «Бизнес-дата» в одной из наших таблиц. Тип данных для этой бизнес-даты - nvarchar (10), а не тип данных datetime. Формат дат - «ММ / ДД / ГГГГ», поэтому Рождество 2007 года сохраняется как «25.12.2007».

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

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

Answer 1

Вы сэкономите место на диске и увеличите производительность, если будете использовать datetime вместо nvarchar (10).

Если вы используете поля даты для вычисления даты ( DATEADD и т. Д.), Вы увидите значительное увеличение скорости выполнения запроса, потому что поля не нужно преобразовывать в datetime в во время выполнения.

Answer 2

Операции в течение DATETIME с выполняются быстрее, чем в течение VARCHAR с, преобразуются в DATETIME с.

Если ваши даты появляются где-либо, но в предложении SELECT (например, вы добавляете их, DATEDIFF их, ищите их в предложении WHERE и т. Д.), То вы должны сохранять их во внутреннем формате.

Answer 3

Еще одна проблема с использованием varchar (или любого другого типа данных строки) состоит в том, что данные, вероятно, содержат недопустимые даты, поскольку они не проверяются автоматически при вводе. Если вы попытаетесь изменить поле в поле даты и времени, у вас могут возникнуть проблемы с конвертацией, когда люди добавят даты, такие как ASAP, Неизвестно, 1/32/2009 и т. Д. Вам нужно будет проверить даты, которые не будут конвертированы, используя удобная функция isdate и исправьте или обнулите их, прежде чем пытаться изменить тип данных.

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

Answer 4

Фильтрация даты в поле nvarchar не возможна, поскольку данные в индексе отсортированы лексикографически, что не соответствует сортировке, которую вы ожидаете получить для даты. Это проблема с форматом даты "мм / дд / гггг". Это означает, что «25.12.2007» будет после «12/12/2008» в индексе nvarchar, но это не то, что вы хотите. "гггг / мм / дд" было бы хорошо.

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

Answer 5

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

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

Answer 6

Я считаю, что с архитектурной точки зрения Datetime будет более эффективным типом данных, поскольку он будет храниться как два 4-байтовых целых числа, тогда как ваш nvarchar (10) будет храниться как до 22 байтов (в два раза больше числа). введенных символов + 2 байта.). Поэтому потенциально требуется более чем вдвое больше места для хранения по сравнению с использованием Datetime.

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

Таким образом, Datetime - это путь.

Answer 7

Да. datetime будет гораздо более эффективным для вычислений даты, чем varchar или nvarchar (почему nvarchar - у вас нет способа получить настоящий юникод, верно?). Плюс строки могут быть неверными и неверно истолкованы.

Если вы используете только часть даты, ваша система может иметь уменьшенную версию datetime только для даты.

Кроме того, если вы просто выполняете объединения и определенные типы операций (>/</= сравнения, но не датированные), столбец «id» даты, который на самом деле представляет собой int формы yyyymmdd, обычно используется в хранилищах данных. К сожалению, это допускает «недопустимые» даты, но также допускает более очевидные зарезервированные, «специальные» даты, тогда как в datetime вы можете использовать NULL от 01.01.1900 или что-то еще. Целостность, как правило, обеспечивается с помощью ограничения ключевого ключа для «измерения» даты.

Видя, что вы пометили вопрос как "sql server", я предполагаю, что вы используете какую-то версию SQL Server, поэтому я рекомендую вам использовать либо datetime, либо smalldatetime. Кроме того, в SQL Server 2008 у вас есть тип date, а также datetime2 с гораздо большим диапазоном. Проверьте эту ссылку , которая дает некоторые детали

Answer 8

Я не могу подтвердить это числами, но тип datetime должен быть намного быстрее, так как его можно легко сравнить, в отличие от varchar. На мой взгляд, стоит взглянуть на метки времени UNIX как на тип данных.

Answer 9

Существует множество причин, по которым вы должны использовать DateTime, а не varchar для хранения даты. Производительность одна ... но я бы заинтересовался такими запросами:

SELECT *
FROM Table
WHERE DateField > '12/25/2007'

дает вам неправильные результаты.