#sql #sql-server #sql-server-2005 #database-design
#sql #sql-сервер #sql-server-2005 #database-design
Вопрос:
DataColumn, DataColumn, DateColumn
Время от времени мы помещаем данные в таблицу через date.
Сначала все кажется отличным, но потом я подумал: что произойдет, когда в таблице будет миллион или миллиард строк? Должен ли я разбивать таблицы по дате? Таким образом, производительность запроса никогда не ухудшится? Как люди справляются с такого рода вещами?
Ответ №1:
Вы можете использовать секционированные таблицы, начиная с SQL 2K5: Секционированные таблицы
Таким образом, вы получаете преимущества сохранения логического дизайна в чистоте, имея возможность перемещать старые данные в другую группу файлов.
Комментарии:
1. Я думаю, что журнал SQL Magazine описал вариант использования, в котором они начали с таблицы продаж и разделили ее по дате заказа. «Активный» раздел будет храниться в
FILEGROUPхранилище с очень высокой скоростью. Старые данные можно поместить в более дешевое хранилище в другомFILEGROUP. До этого я бы посоветовал сделать что-то подобное, разместив таблицу Sales и Sales_History в разныхFILEGROUPS, а затем создав представление дляUNIONних.2. Но нужно ли вам что-либо менять в своем приложении, чтобы использовать разделенные таблицы, или SQL Server позаботится об этом за вас «автоматически»?
3. Насколько я знаю, это довольно автоматическая магия. Я когда-либо играл с ним только в тестовой среде, но я не верю, что это приводит к прерыванию кода, если таблица разбита на разделы. Это функция механизма хранения, поэтому запросы не знают об этом. Вы даже можете добавить новые разделы позже. Как и в примере с продажами, вы могли бы каждый год вводить новый раздел для хранения информации о продажах за один год.
4. Это был отличный ответ, за исключением того факта, что мне понадобится sql 2005 enterprise
Ответ №2:
Вы не должны разбивать свои таблицы из-за данных. Вместо этого вам следует беспокоиться о своих индексах, нормализации и так далее.
Обновить
Немного более глубокое объяснение. Предположим, у вас есть таблица с миллионом записей. Если у вас разные даты в [DateColumn], вашим лучшим союзником будут индексы, которые работают с [DateColumn]. Затем вы убедитесь, что ваши запросы всегда фильтруются по крайней мере по [DateColumn].
Таким образом, у вас все будет в порядке.
Комментарии:
1. До скольких строк я был бы в порядке, прежде чем это начнет разрушаться?
2. С хорошей структурой БД, нормализацией и индексами у вас все должно быть в порядке, и это все. Но вы всегда можете взглянуть на предложение @Yuck. Это выглядит многообещающе
Ответ №3:
Это легко квалифицируется как преждевременная оптимизация, чего сложно достичь при проектировании БД, ИМХО, потому что оптимизация находится / должна быть ближе к поверхности при моделировании данных.
Но все, что вам нужно сделать, это создать индекс для DateColumn поля. Индекс на самом деле является гораздо более производительным решением, чем любой вид разделения таблиц, и значительно упрощает ваш дизайн и, следовательно, все ваше программирование. (И вы можете решить использовать разделение без влияния на ваш дизайн в будущем, если это поможет.)
Ответ №4:
Похоже, вы могли бы использовать таблицу истории. Если вы в основном собираетесь запрашивать данные текущей даты, то перенесите старые данные в таблицу истории, и ваша основная таблица не будет так сильно расти.
Ответ №5:
Если я правильно понял ваш вопрос, у вас есть таблица с некоторыми данными и датой. Ваш вопрос — увижу ли я повышение производительности, если буду создавать новую таблицу, скажем, каждый год. Таким образом, запросам никогда не придется просматривать данные более чем за один год.
Это неправильно. Вместо этого вам следует установить поле даты в качестве индекса. Сервер сможет обеспечить вам необходимый прирост производительности, если это индекс.
Если вы этого не сделаете, логика вашей программы сойдет с ума и в конечном итоге замедлит работу вашей системы.
Сохраняйте простоту.
(ПРИМЕЧАНИЕ — Вы можете использовать некоторые расширенные функции разбиения на разделы, но при необходимости их можно добавить позже — маловероятно, что вам понадобятся эти функции, но простой дизайн должен иметь возможность перейти на них при необходимости.)
Ответ №6:
Когда таблицы и индексы становятся очень большими, может помочь разделение данных на более мелкие, более управляемые разделы.
Microsoft SQL Server 2005 позволяет разбивать таблицы на разделы на основе конкретных шаблонов использования данных с использованием определенных диапазонов или списков. SQL Server 2005 также предлагает множество опций для долгосрочного управления разделенными таблицами и индексами путем добавления функций, разработанных на основе новой структуры таблиц и индексов.
Более того, если в системе с несколькими процессорами существует большая таблица, разбиение таблицы на разделы может привести к повышению производительности за счет параллельных операций.
Возможно, вам также потребуется учесть следующее: В SQL Server 2005 говорят, что связанные таблицы (такие как таблицы Order и OrderDetails), которые разделены на один и тот же ключ разделения и одну и ту же функцию разделения, выровнены. Когда оптимизатор обнаруживает, что две разделенные и выровненные таблицы объединены, SQL Server 2005 может сначала объединить данные, которые находятся в одних и тех же разделах, а затем объединить результаты. Это позволяет SQL Server 2005 более эффективно использовать компьютеры с несколькими процессорами.
Прочитайте о секционированных таблицах и индексах в SQL Server 2005