Все больше и больше бизнес-приложений, какова архитектура как бизнес структур, где модель данных основной системы должны поддерживать пользователям работать с другой базе данных объекты и атрибуты, а также предусматривают обширные настройки. К примеру принять производственная компания, которая разрабатывает приложения для сбора всех данных датчика, поступающих от оборудования. Каждый этаж завод потенциально отличается, с типами различного оборудования, датчиков, чтениях и потребностей. Завод, где производятся автомобили имеет весьма различного оборудования и датчиков чем завод, где производятся шоколад.

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

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

«Универсальные» модель данных

Большинство объектов и операций можно смоделировать с помощью модели «универсальной» данных─модель существительных, прилагательных, глаголов и наречия, если вы будете. Следующая модель может быть создан для хранения как раз около любого типа данных для приложений любого типа. (Этот пример модели крайне упрощенческими и исключительно для целей иллюстрации только).

 

Рисунок1

Эта модель переводится следующим образом:

 

Рисунок2

Если эта модель применяется к онлайн книга - продажи приложения, книги и магазины, существительные (объекты); Книга имена и типы являются прилагательные (атрибутов); Продажа является глагол (отношения); и дата продажи и количества наречия. Это очень простой пример и было бы общими для добавить группирование, контейнеры и типы, но как основы эта модель может поддерживать большинство приложений даже без конкретных имен таблица и столбец , которые могут потребоваться в традиционной реляционной модели данных. Поскольку данные по инициативе во время выполнения, база данных является по существу «выполнения».

Однако это очень трудно писать запросы к этой модели. запрос , который возвращает список книг продано в определенный день на конкретного магазина─очень простой запрос─будет выглядеть как в следующем примере:

 

Выберите

        преобразовать(varchar, SaleDateValue.ObjectAttributeValue, 101) как SaleDate

Магазин.ObjectName как StoreName

Book.ObjectName как BookName

Автор.ObjectName как AuthorName

Заказчик.ObjectName как CustomerName

SaleBookQtyvalue.RelationshipAttributeValue как BooksSold

от объекта, продажа

соединение ObjectAttribute как SaleDateValue

on Sale.ObjectID = SaleDateValue.ObjectID

соединение атрибут как SaleDate

на SaleDateValue.AttributeID =SaleDate.AttributeID

и SaleDate.AttributeName = 'saledate'

соединение связь как SaleStore

on Sale.ObjectID = SaleStore.FromObjectID

и SaleStore.RelationshipType = 'salestore'

соединение Object as Store

на SaleStore.ToObjectID = Store.ObjectID

and Store.ObjectType = 'Магазин'

Присоединяйтесь к связь как SaleBook

on Sale.ObjectID = SaleBook.FromObjectID

и SaleBook.RelationshipType = «salebook»

соединение Object as Book

на SaleBook.ToObjectID = Book.ObjectID

and Book.ObjectType     = 'Книга'

Присоединяйтесь к связь как BookAuthor

on Book.ObjectID = BookAuthor.FromObjectID

и BookAuthor.RelationshipType = 'bookauthor'

соединение Object as Author

на BookAuthor.ToObjectID = автор.ObjectID

     и автор.ObjectType = 'Лицо'

Присоединяйтесь к связь как SaleCustomer

on Sale.ObjectID = SaleCustomer.FromObjectID

и SaleCustomer.RelationshipType = 'salecust'

соединение объекта как клиента

на SaleCustomer.ToObjectID = клиента.ObjectID

и клиента.ObjectType    = 'Лицо'

соединение RelationshipAttribute как SaleBookQtyvalue

на SaleBook.RelationshipID = SaleBookQtyvalue.RelationshipID

соединение атрибут как SaleBookQty

на SaleBookQtyvalue.AttributeID = SaleBookQty.AttributeID

и SaleBookQty.AttributeName = 'saleqty'

где продажа.ObjectType  = 'Продажу'

 

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

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

 

Рисунок3

Тот же запрос против выше модель хотел больше следующим образом:

 

Выберите

преобразовать(varchar,продажа.SaleDate, 101) as SaleDate

,Store.StoreName

,Book.BookName

,Author.AuthorName

,Customer.CustomerName

,SaleDetail.Кол-во

от продажа

соединение магазин

on Sale.StoreID = Store.StoreID

соединение SaleDetail

on Sale.SaleID =SaleDetail.SaleID

соединение книга

на SaleDetail.BookID = Book.BookID

соединение клиента

on Sale.«КодКлиента» = клиента.«КодКлиента»

соединение автор

on Book.AuthorID = Author.AuthorID

 

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

Супертипы и подтипы

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

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

В модели на рисунке 1 объект таблица представляет "существительные," таких как авторы, клиентов, магазинов и книг. В этом примере мы предполагаем, что все модели конечного потребителя потребуется настраиваемые приложения, которое обрабатывает людей (авторы и клиентов), компаний (магазинов) и вещи (книги). Подтипизация объектов таблица эти новые таблицы удаляет большой трудности с пониманием этих учреждений, но по-прежнему допускает гибкость и расширяемость, необходимых для продать это приложение к любому типу розничной торговли.

Для разработки подтип таблица, мы необходимо сначала определить, какие субъекты являются в общем. На самом высоком уровень — объект таблица. Супертип таблицы также требуют дискриминатора столбец─для разделения строк таблица Супертип по типу объекта─что обычно соответствует имени таблица подтип. ObjectType столбец является естественной дискриминатора, поэтому мы оставим это супертипа таблица.

 

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

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

 

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

Расширяемый атрибуты

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

Один из вариантов заключается в том, чтобы добавить столбцы в схеме. Это дает многочисленные риски, такие как пользователи могут удалять необходимые столбцы или перезаписать столбцов, в дополнение к потенциальных проблем с обновлением. Добавление большого числа столбцов для каждого из возможных вариантов, которые могут понадобиться заранее также является проблематичным─он занимает места и масштабируемость может быть ограничена, когда есть запросы, которые требуют многие предложения OR. Почти каждый корпоративное приложение нуждается в некотором роде ad hoc запрос построителя экран и программно создание запрос для запуска этого часто пишется как последовательность предложения OR. На основе стоимости оптимизаторы примет решение на некоторое количество или положения вернуться из индекса стремятся просмотр индекса. По достижении этого порога запрос становится продолжительной и может блокировка большое количество ресурсов. Это необходимо избегать позволяет гарантировать, что приложение является масштабируемой предприятием.

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

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

Однако пар имя/значение не имеют достаточно информации, чтобы сделать их действительно полезным. Необходимо принять решение о том, как сохранить значение, когда он может быть любого типа. Один из вариантов заключается в том, чтобы сохранить его как SQLVARIANT, другой — для размещения значений в таблицы тип данных─одно имя/значение пары таблица для строк, один для поплавка и так далее. Кроме того должна быть больше метаданные доступны для использования. Вы можете агрегат значения?  Не было показано SQLVARIANT, производительности или масштабируемости, но это не столь простой и чистой, чтобы использовать как типизированные таблица.

Самая большая проблема на сегодняшний день является, что все эти данные должны шарнирах таким образом, чтобы можно сообщить против. SQL Server Reporting Services (SSRS) является очень популярным продуктом, потому что вы можете использовать разработать приложение J2EE без построения отчетов индивидуально. Конечные пользователи могут указывать SSRS схему базы данных или модель отчета служб SSRS и создавать свои собственные отчеты. Это явно нужной функции. С помощью пар имя/значение требует определенной работы группой разработчиков для сводных строк в столбцы, в витринах данных или программно. SQL Server По-прежнему Analysis Services уметь свести эти строки в меры, но проблема потери типа данных.

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

 

Ограничение числа возможных предложений OR повышает масштабируемость и ограничивая количество пар имя/значение увеличивает удобство использования. Оптимальное сочетание должна определяться для каждого приложения. Единственным способом для этого является для запуска нагрузочных тестов, чтобы определить, где модель будет падать. Затем необходимо настроить смеси и проверить снова.

Microsoft® SQL Server® 2008 предоставляет еще один вариант─поддержка разреженный столбец столбец задает и отфильтрованных индексов. Разреженные столбцы были разработаны специально для оптимизированного хранения столбцы, часто содержат значения null. Наборы столбцов включить эти столбцы должны быть извлечены как в одном XML-документе. Отфильтрованные индексы обеспечивают возможность создать индекс на подмножестве данных; в этом случае это было бы только данные с фактическими значениями. Отфильтрованные индексы повысить производительность и могут теоретически быть создано каждого клиента или расширить столбец, помогающих облегчить таблица сканирует запрос построителя запросов.

Нормализовать, нормализации, нормализовать

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

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

SQL Server 2008 предоставляет новые функциональные возможности для этого в hierarchyid тип данных, который может использоваться для представления это дерево на основе чрезвычайно компактный и могут быть отсортированы.

Двигатель SQL Server был полностью перестроено в версия 7.0, от первоначального общего кода Microsoft/Sybase. Это означало SQL Server может дизайн вокруг более чисто в реляционной модели, установка основой для приложений, которые можно масштабировать и выполнять из коробки, если модель базы данных также следует реляционной модели. Это огромное преимущество. Все метаданные для модели─первичные ключи, внешние ключи, допустимость значений NULL, ограничения check и т. д.─используются оптимизатором для поиска оптимального выполнения плана.

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

Допустимость значений NULL

Значения NULL столбцы и связи, можно ограничить масштабируемость как есть много вариантов для оптимизатора для рассмотрения. Если отношения внешнего ключ значение NULL, для гарантировать, что все части данных представлены программно построен запросов необходимо использовать внешние соединения. Заставляя все отношения внешнего ключ будет не допускающим и создание ограничение внешнего ключ на них дает оптимизатор информацию, которая позволяет оптимизировать запрос и внешних соединений обычно не требуются. Оптимизатор может даже исключить части запрос.

Например возьмем следующие модели:

 

Рисунок8

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

Этот запрос и его план выполнения будет выглядеть следующим образом:

 

Выберите SalesOrderHeader.OrderDate

от SalesOrderHeader

соединение менеджера

на SalesOrderHeader.SalesPersonID = продавец.SalesPersonID

где SalesOrderHeader.OrderDate между ' 01/01/2004' и ' 01/02/2004'

 

 

Рисунок9

Удаление только ограничение внешнего ключ на таблица SalesOrderHeader и повторным выполнением запрос производит следующий план выполнения запрос :

 

Рисунок10

Четко ограничение внешнего ключ метаданные используется оптимизатором для ликвидации таблица , которая не требуется.

Обратите внимание, что есть еще один важный вопрос нулями, что часто упускается из виду; их правильное использование не всегда понимается разработчиков или клиентов. Разработчики должны по-разному код для значения NULL потому что правильный синтаксис отличается от синтаксиса для непустых значений. Не делаю это приводит к ошибкам во время выполнения. Запросы также могут возвращать различные результаты в зависимости от параметр CONCAT_NULL_YIELDS_NULL. В следующем запрос следует и возвращение «AB»:

 

Объявите nchar @ nvar1(1)

Объявите nchar @ nvar2(1)

набор @nvar1 = 'A'

набор @nvar2 = 'B'

Выберите @ nvar1 + @ nvar2

Если вы набор одной из переменных значение null:

набор @nvar2 = NULL

 

Возвращаемый результат зависит от параметр CONCAT_NULL_YIELDS_NULL.

Трехзначная логика

Не многие из нас полностью знакомы с трехзначная логика. Принять следующий тест для иллюстрации этой точки. Заполните каждую клеточку двух выражений, которые объединяются. (То есть, если exp1 равен TRUE И exp2 равен TRUE, Boolean И обоих имеет значение TRUE)

 

 

Теперь предоставьте следующую информацию для или выражения.

 

 

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

Трехзначная логика ответов

 

 

 

Корректирующие действия для Денормализация

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

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

Родительских/дочерних таблиц и последовательности идентификаторов

Семантические модели, как правило, очень глубоко в родительских/дочерних отношениях; Это просто общая черта, которая не часто встречается в модели данных OLTP и OLAP. Проблемы с неправильно моделирования родитель/потомок обычно не влияют на масштабируемость для родителя и ребенка, но для всех внуков. Каждое поколение осложняет проблему, потому что каждое поколение обеспечивает естественной сужению данных и родительских/дочерних таблиц не очень разные для оптимизатора, чем таблица с домен таблица. ( домен таблица обычно тип таблица, с отношением внешнего ключ с обычной таблица. Эта таблица обеспечивает домен допустимых значений для столбец в обычной таблица.)

В следующих таблицах представляют общие сущности на завод по производству этаж (упрощенный для этого примера). Есть sequenceID для каждой таблица и в настоящее время есть не связей, определенных, поэтому оптимизатор не имеют никакой информации о отношения (эти отношения являются понятием и не определен в системе). Сайт это здание завода, площадью внутри здания завода, линия является производственной линии внутри области, узел представляет собой часть оборудования на этой линии, и датчики на узлах.

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

Проблема с этой модели является, что оптимизатор (а также разработчик) увидит их в качестве домен таблиц, которые ограничивают значение NodeID датчик таблица. Но это не на самом деле правильно. Датчик не может существовать сам по себе─это подраздел узел─так это дочерней таблица. Это касается всей группы из таблицы─каждый является потомком предыдущего. дети в реляционной модели идентифицируются составной ключ (родитель ID и экземпляр или LineID).

Это хорошая практика, чтобы сохранить родительский ключи в таком же порядке в каждой дочерней таблица для удобства чтения. Это очень четко в этой диаграмме, что каждый является родитель следующего. Другое правило реляционных баз данных является, что вы должны соединение на весь ключ; Эта модель делает, что ясно как хорошо. Объединения датчик таблица с узлов таблица требует соединение на код узла и AreaID и LineID и NodeID на обеих сторонах соединение. Обратите внимание, что неверно моделирования, такие, как модель на рисунке 12 может привести к выходу на рынок неправильных данных.

Эта задача выглядит весьма обременительные─есть так много ключей и так много кода. Однако это нормальная форма и делает огромная разница в масштабируемость в семантической модели. Оптимизатор можно выбрать абсолютно правильным соединение планов выполнения, и вы можете перейти в иерархии в любой точке. Для экземпляр, найти все датчики в одной области может быть достигнуто только датчик таблица. В предыдущей модели на рисунке 12 «родительские» ключи не перевозятся вниз, и вы должны соединение каждый отдельной таблица для получения этой информации. Часы для запросов, возвращающих повторяющиеся данные и что использовать предложение DISTINCT исправить это. Повторяющихся данных является четким признаком модельной задаче и это проблема обычно только этот─отношенийдомен вместо того, чтобы родитель/потомок. предложение DISTINCT не должно быть необходимо сделать правильный запрос .

Чтобы проверить модели физических данных, реконструировать базы данных в Microsoft Visio® и посмотреть, если все отношения неизменны. Если Visio можно вытащить всей модели и отношения, поэтому можете оптимизатор.

Суррогатные ключей

Ясно то, что количество ключей, содержащихся в первичный ключ получает больше, как вам двигаться вниз иерархии является проблематичным. Многие бы соблазн использовать суррогатный ключ вместо составного ключ. Суррогатные ключи первоначально использовались для экономии места, и это важно как ключи были проведены все остальные индексы; поскольку это беспокоит несколько лет назад. Суррогатные ключи не имеют бизнес смысла─они призваны стоять в что-то другое. CompanyID в компании таблица является суррогатный ключ , поскольку он занимает место CompanyName, который долго, трудно использовать и могут меняться. (Первичный ключ должен не изменяется.) В модель завода SiteID является суррогатный ключ для SiteName. Однако SiteName столбец является до сих пор в таблица. Обычно когда суррогатный ключ используется, вы должны по-прежнему хранить бизнес-данных в таблица─в противном случае эти данные будут утеряны. Суррогатные ключи экономии места, только если первичные ключи перевозятся в другие индексы или таблицы.

В нашем примере мы могли бы использовать суррогат для датчика или узел таблиц, но SiteID, AreaID и LineID должны быть в таблица , так как они являются частью определения таблица.

Идентификаторы последовательности

Последовательность идентификаторов, как правило, найти в базы данных миграции от Oracle. Как обычно для оптимизации запросов Oracle DBA, проблемы, с которыми они вызывают для реляционных запрос двигателей скрыта в стоимости их услуг. Одной из целей основной архитектуры для SQL Server было свести к минимуму необходимость оптимизации экспертов. Для достижения этого низкая совокупная стоимость владения (TCO), потратьте время для моделирования приложения правильно и удалите все идентификаторы последовательности. Пусть оптимизатор делать свою работу за вас.

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

Образцы модели данных являются первой и наиболее важной частью любого приложения базы данных. Первая логическая модель идет о бизнес-требования. После того, как логическая модель является полной и утвержденных, физическая модель материализуется в базу данных с ограничения и индексы, допустимость значений NULL, типы данных и так далее. Это позволяет оптимизатору работать как реляционные оптимизатора. Модель данных также показывает, как правильно писать запросы. Соединения следует использовать только вдоль линии связи, показанная на диаграмме. Потому что там, как правило, отсутствие моделирования дисциплины в некоторых базы данных групп, соединение разработчиков по столбцам, представляется, имеют то же имя, или что критерии, они могут прийти с. В модель завода хотя есть AreaID в датчик таблица, существует не линию связи, поэтому не должно быть соединение между этими двумя таблицами. В самом деле если запрос написан таким образом, повторяющиеся строки будут возвращены, и потребовалось бы предложение DISTINCT. Объединение всех таблиц приводит к хорошей производительности─объединение многочисленных таблиц не является проблемой;  проблема заключается в неправильно соединении многочисленных таблиц.

Индексирование

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

Рекомендуется иметь первичный ключ быть кластеризованный ключ в семантической модели, если есть веские причины не до (например, эксплуатационные испытания, которые выявляют проблемы с этим). Потому что мы должны оставаться очень реляционном правильным и жесткой для масштабируемости результаты, ключи в конечном итоге переносятся во всяком случае, так что кластеризованного первичного ключ экономит пространство и дает оптимизатору лучших вариантов

Это должно заботиться о около 80% ваших потребностей оптимизации запрос . Остальные 20% вы найдете во время тестирования производительности и масштабируемости. Важно подчеркнуть, что существует оптимальный баланс между объектное представление и реляционное представление данных, и вы можете найти это приложение только проверяя.

Построители запросов

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

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

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

Подкачка

Клиенты могут отправлять запросов, возвращающих большое количество результатов, в то время, как часто клиенту не нужно на самом деле все возвращенные данные. Чтобы сохранить систему масштабируемой, следует разрабатывать в приложение способ ограничения такого воздействия. Включая TOP предложение не гарантирует, что вся таблица не проверяется перед возвращением ограниченное количество строк. Основные работы по-прежнему должна быть выполнена, после чего конечные результаты носят ограниченный характер. Большое количество ресурсов по-прежнему подвергаются потребляется и потенциально заблокирован.

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

Отложенной загрузки

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

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

Семантическая/метаданных/выполнения данных модели контрольный список

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

• Построить логическую модель и убедитесь что он утвержден бизнес
• Подтипа с универсальной модели
• Нормализовать
• Если вы денормализовать, добавьте компенсирующего действие
• Удалите все SequenceIDs
• Модель родитель/потомок правильно
• Создать физическую модель и осуществить его в базе данных
• Избегайте nullable отношения как можно больше
• Реконструирования базы данных в Visio для проверки корректности
• Дизайн пользовательского интерфейс для поддержки разбиения по страницам
• Ленивый нагрузки деревья как можно больше
• Оценить все запросы, которые требуют ОТДЕЛЬНОЙ предложение
• Нагрузочный тест для масштабируемости

Сводка

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

 

 

Для получения дополнительной информации:

SQL Server веб-сайт

Технический центр SQL Server

SQL Server DevCenter