Поделиться через

Структура базы данных и производительность (SQL Server Compact Edition)

  • Статья

Правильное проектирование структуры публикаций и баз данных SQL Server позволяет значительно повысить производительность приложений SQL Server 2005 Compact Edition (SQL Server Compact Edition). В следующих разделах рассматриваются конкретные методы повышения производительности.

Денормализация базы данных

Нормализованная база данных предотвращает появление функциональных зависимостей в данных, что упрощает обновление базы данных и делает его более эффективным. Однако при выполнении запросов к базе данных для получения результирующих сведений может потребоваться объединение большого количества таблиц. С увеличением числа объединяемых таблиц время выполнения запроса значительно возрастает. Поэтому в некоторых случаях не рекомендуется использовать нормализованные базы данных. Как правило, в качестве компромиссного варианта используется база данных с определенным уровнем денормализации. Это несколько повышает сложность процесса обновления, но позволяет уменьшить число таблиц, которые необходимо объединять.

Примечание.
В общем случае, если в большом количестве запросов требуется объединять более пяти или шести таблиц, следует рассмотреть вариант денормализации базы данных.

Денормализация может потребоваться и в ряде других случаев. Например, предположим, что в базе данных существуют таблицы: 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 2000 используются стандартные статьи. При наложении фильтра для этих статей применяется обычная фильтрация. Однако SQL Server 2005 позволяет при создании публикации указать для статей публикации следующие два параметра, управляющие фильтрацией и передачей данных между издателем и подписчиком.

  • Только для загрузки (только для чтения)
    В некоторых случаях данные, к которым необходимо иметь доступ на смарт-устройстве, хранятся только в справочных таблицах. Например, может потребоваться предоставить пользователям право просмотра каталога компании на смарт-устройстве, но при этом пользователи не должны иметь права изменения этих данных. В подобных ситуациях применяются статьи, предназначенные только для загрузки. Такие статьи занимают меньше места, поскольку на устройствах не хранятся метаданные. Кроме того, при синхронизации таких статей возникает меньше сетевого трафика.
  • Секционированный
    Хотя SQL Server 2000 позволяет создавать группы секций, их использование отрицательно сказывается на производительности во время загрузки данных, поскольку при каждой загрузке необходимо рассчитывать соответствия кодов секций. В SQL Server 2005 при использовании секционированных статей загружаемые изменения сопоставляются только одному коду раздела. Это повышает быстродействие, однако налагает следующие ограничения.
    • Каждая строка статьи должна принадлежать только одному коду секции.
    • Каждая статья может быть опубликована только в одной публикации.
    • Подписчик не может вставлять строки, не принадлежащие его коду секции.
    • Кроме того, при использовании подобных статей налагаются следующие ограничения на фильтрацию.
    • Подписчик не может обновлять столбцы, участвующие в фильтрации.
    • В иерархии фильтров объединений секционированные статьи не могут порождаться от обычных статей.
    • Для фильтра объединения, в котором секционированная статья является дочерней, значение параметра join_unique_key должно быть равно 1.
    • Каждая статья может иметь только один фильтр объединения или подмножества. Статья может иметь фильтр подмножества и являться родительской для фильтра объединения, однако статья не может иметь фильтр подмножества и являться дочерней для фильтра объединения.

См. также

Основные понятия

Методы повышения производительности при обработке запросов (SQL Server Compact Edition)

Другие ресурсы

Методы повышения производительности (SQL Server Compact Edition)

Справка и поддержка

Получение помощи по SQL Server Compact Edition