Дата и время SQL Server по сравнению с Международной ключевой производительностью
Я обычно проявляю этот подход:
Имеют глобальную переменную настроек для Вашего приложения, которое указывает на папку, где Вы храните загруженные файлы. В Вашем хранилище базы данных относительные пути в файлы (относительно того, на что переменная настроек указывает на).
Поэтому, если файл расположен в /www/uploads/image.jpg, Ваши настройки varible указывают на/www/uploads, Ваша строка базы данных имеет image.jpg. Это - гибкий путь, который разъединяет Вашу системную структуру каталогов из Вашего приложения.
Далее можно фрагментировать хранилище файлов в каталогах на основе того, каких таблиц базы данных они касаются. Скажите, что у Вас есть таблица user_reports и таблица user_photos. Вы храните файлы, которые касаются user_reports в/www/uploads/user_reports. Если у Вас есть большое количество пользовательских загрузок, можно реализовать fragmentaion еще больше. Скажите, что пользователь загружает файл 20.03.2009, файл называют report.pdf, таким образом, Вы храните его в /www/uploads/user_reports/2009/03/20/report.pdf.
4 ответа
Я ежедневно имею дело со складами в миллионах строк, и мы считаем, что умные ключи даты - это то, что нужно. Это в формате ГГГГММДД. Чтобы найти весь 2008 год, вам нужно сделать следующее:
select
*
from
gl
where
postdate between 20080101 and 20081231
С индексированным столбцом это феноменально быстро, даже для одного миллиарда строк. Это также указывает на таблицу дат, поэтому мы можем добавить день недели, названия месяцев или любую другую информацию о датах, которая у нас есть с этим объединением.
Конечно, эти хранилища обычно создаются для поддержки кубов SSAS (OLAP базы данных), и поэтому эта таблица дат становится нашим измерением даты. Присоединиться к int гораздо быстрее, чем к datetime.
Также рассмотрите, что в действительности является частью даты в поле Actual datetime или smalldatetime ... 4-байтовое целое число, представляющее количество дней с 1 января 1900 года.
Это может быть приведение к фактическому datetime неявно, очень быстро (поскольку это то же самое значение, что и первые четыре байта 8-байтового значения DateTime)
, вы также можете использовать его в предложениях Where для фактических значений datetime, поскольку SQL Серверный механизм неявно преобразует одно в другое и обратно.
Кроме того, каждое возможное значение 32-битного (4-байтового) целого числа является допустимым значением datetime (Midnight) для внутреннего типа данных Datetime SQL Server
То, что вы в конечном итоге делаете со значительно большими наборами финансовых данных, - это «кубы данных».
Это в основном относится к процессу создания отчетов, которые вам нужны за каждый период, исторически, поэтому вам не нужно делать эти где предложения, вы просто просматриваете данные за этот период.
Так что это не имеет значения. Однако сохраните ее и внедрите историческую базу данных, которая будет более эффективной для долгосрочных отчетов.
Я бы предпочел сохранить дату непосредственно напротив записи.
Если вы можете использовать smalldatetime, оно того же размера, что и целое число - оба 4 байта. А под капотом типы данных datetime - целые числа.
Первые 2 байта smalldatetime - это что-то вроде количества дней, прошедших с 01.01.1900, а вторые 2 байта - это что-то вроде количества секунд, прошедших с полуночи. (Это может быть неточно, но вы поняли.) Так что эти типы данных очень эффективны.
Я думаю, что предложение where, выполняемое для поля smalldatetime, будет нормальным.