Проектирование и производительность баз данных (SQL Server Compact)
Производительность приложений SQL Server Compact 4.0 можно значительно повысить с помощью правильного проектирования структуры публикаций и баз данных SQL Server. В следующих разделах рассматриваются конкретные методы повышения производительности.
Денормализация базы данных
Нормализованная база данных предотвращает появление функциональных зависимостей в данных, что упрощает обновление базы данных и делает его более эффективным. Однако при выполнении запросов к базе данных для получения результирующих сведений может потребоваться объединение большого количества таблиц. С увеличением числа объединяемых таблиц время выполнения запроса значительно возрастает. Поэтому в некоторых случаях не рекомендуется использовать нормализованные базы данных. Как правило, в качестве компромиссного варианта используется база данных с определенным уровнем денормализации. Это несколько повышает сложность процесса обновления, но позволяет уменьшить число таблиц, которые необходимо объединять.
Примечание
В общем случае, если в большом количестве запросов требуется объединять более пяти или шести таблиц, следует рассмотреть вариант денормализации базы данных.
Денормализация может потребоваться и в ряде других случаев. Предположим, что в базе данных имеются две таблицы: Orders и Order Details. Таблица Orders содержит сведения о заказах пользователей. Список продуктов, входящих в тот или иной заказ, содержится в таблице Order Details. Предположим, что необходимо определить общую стоимость каждого заказа. Для этого сначала следует определить стоимость каждого продукта (по формуле «количество единиц продукта» * «цена единицы продукта» — скидка). После этого необходимо сгруппировать стоимости по заказам. Требуемый запрос может выглядеть следующим образом.
SELECT "Order ID", SUM("Unit Price" * Quantity * (1.0 - Discount))
AS Total FROM "Order Details"
GROUP BY "Order ID"
Order ID Total
----------------------------------------
10000 108
10001 1363.15000915527
10002 731.800003051758
10003 498.180023193359
10004 3194.19999694824
10005 173.400009155273
10006 87.2000007629395
10007 1405
10008 1171
10009 1530
10010 470
... ...
(1078 rows affected)
Выполнение этого запроса является достаточно сложным и, если в базе данных хранятся сведения о большом количестве заказов, может занять много времени. Вместо выполнения приведенного выше запроса можно на этапе размещения заказа определить его стоимость и сохранить ее в отдельном столбце таблицы Orders. В этом случае для получения требуемого результата достаточно извлечь из данного столбца предварительно рассчитанные значения, как показано ниже.
SELECT "Order ID", "Order Total" AS Total FROM Orders
Создание столбца, содержащего предварительно рассчитываемые значения, позволяет значительно сэкономить время при выполнении запроса, однако требует своевременного изменения данных в этом столбце.
Использование столбцов постоянной и переменной длины
При проектировании таблиц необходимо знать достоинства и недостатки применения столбцов постоянной и переменной длины. Использование столбцов переменной длины уменьшает размер базы данных, поскольку они занимают столько места, сколько необходимо для размещения хранящихся в них данных. Столбцы постоянной длины всегда занимают максимально возможный объем места, указанный в схеме (даже если данные в соответствующем столбце отсутствуют). Недостатком столбцов переменной длины является то, что некоторые операции выполняются для них менее эффективно, чем для столбцов постоянной длины. Например, если столбец переменной длины изначально имел небольшой размер, а после выполнения операции UPDATE его размер значительно вырос, может потребоваться перемещение соответствующей записи. Кроме того, частые обновления постепенно приводят к повышению фрагментации страниц данных. Поэтому в тех случаях, когда размер содержащихся в столбце данных будет изменяться незначительно и когда часто выполняются обновления данных, рекомендуется использовать столбцы постоянной длины.
Уменьшение длины строк
Число строк, которое может поместиться на странице, зависит от размера каждой строки. Чем меньше размер строки в таблице, тем больше строк может содержаться на странице и тем больше строк сможет вернуть одна дисковая операция, выполняемая над таблицей, что повышает эффективность операций. Уменьшение размера строк также увеличивает число строк, которое может поместиться в кэш хранилища данных, что повышает вероятность попадания в кэш. Кроме того, применение строк малого размера уменьшает размер нерационально используемого пространства на отдельных страницах данных, что характерно в случае применения строк большого размера.
Рассмотрим крайний случай. Если размер записи несколько больше половины страницы данных, то почти половина каждой страницы данных останется пустой. Некоторые разработчики баз данных предпочитают иметь дело с широкими таблицами, перенося схемы, разработанные для больших ЭВМ, на мобильные устройства. Подобный подход может снизить эффективность разработанной базы данных. Одним из способов повышения эффективности является разбиение наиболее важных таблиц. Предположим, в базе данных существует таблица, в которой значения одних столбцов изменяются очень редко, а других — часто. Имеет смысл разбить одну таблицу на две: первая будет содержать часто используемые столбцы, а вторая — редко используемые. Создание этих двух таблиц позволит уменьшить длину строк и воспользоваться возникающими преимуществами. Недостатком подобного подхода является необходимость использования объединений для получения нужной информации.
Уменьшение длины ключей
Индекс — это упорядоченное подмножество элементов таблицы, для которой создан индекс. Применение индексов позволяет ускорить поиск и сортировку. Чем меньше размер ключа индекса, тем меньше места занимает ключ и тем выше его эффективность. Поскольку первичные ключи таблиц часто используются в других таблицах в качестве внешних ключей, рекомендуется минимизировать длину первичных ключей. Если в таблице отсутствуют столбцы небольшой длины, которые могут использоваться как первичный ключ, в качестве первичного ключа можно использовать столбец удостоверения, реализованный в виде целочисленного значения.
Индекс, включающий небольшое число ключевых столбцов (или только один ключевой столбец) называют узким индексом. Индекс с большим количеством ключевых столбцов называют широким индексом. Как правило, широкий индекс имеет большую длину ключа. Предельным случаем является создание индекса, включающего все столбцы таблицы. При этом, фактически, создается копия исходной таблицы, что является неэффективным с точки зрения размера базы данных, а также производительности при обработке запросов.
См. также
Основные понятия
Оптимизация производительности выполнения запросов (SQL Server Compact)