Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Вебмастеру -> Сеппа Д. -> "Microsoft ADO.NET" -> 130

Microsoft ADO.NET - Сеппа Д.

Сеппа Д. Microsoft ADO.NET — М.: Русская Редакция, 2003. — 640 c.
ISBN 5-7502-0223-2
Скачать (прямая ссылка): mcrsftado2003.pdf
Предыдущая << 1 .. 124 125 126 127 128 129 < 130 > 131 132 133 134 135 136 .. 260 >> Следующая

Свойство PatentCotumns
Свойство ParentColumns возвращает массив, содержащий объекты DataCotumn из участвующего в отношении родительского объекта И-гйаУФЛч. Данное свойство доступно только для чтения,
Свойство ParentKeyConstraint
Свойство ParentKeyConstraint возвращает ограничение lUtiqtteConstrwm на которое ссылается объект DataRelation. Если ваш объект DataRelation не использует ограничения, свойство ParentKeyConstraint возвращает Nothing или null - в зависимости от языка программирования. Данное свойство доступно только для чтения,
Свойство Parent Table
Свойство ParentTable возвращает участвующий в отношении родительский объект DataTable. Данное свойство доступно только для чтения.
Свойство RelationName
Свойство RelationName доступно как для чтения, так и для записи и позволяет
получать и задавать имя объекта DataRelation.
Вопросы, которые стоит задавать почаще
Вопрос. Когда нужно создавать объекты DataRelation без ограничений?
Ответ. Предположим, ваше приложение получает из БД данные о клиентах и заказах и выводит их в простой Web-форме. Приложение позволяет только просматривать, но не редактировать информацию.
В таком приложении полезен объект DataRelation, с помощью которого легко вывести список заказов конкретного клиента. Однако ограничения в объекте
DataSet скорее всего не понадобятся. Почему? Ограничения применяются для
проверки данных, требующей времени. Если данные в приложении доступы только
для чтения и БД уже проверила их средствами собственного набора ограничений,
ADO N FT нет смысла повторно проверять эти данные.
Вопрос. Я собираюсь работать с данными нескольких тмблпн, но не буду выбирать все записи родительской таблицы. Приведенные в главе запросы, которые
выбирают только связанные дочерние записи, кажутся мне сложными и неэффек-
ГЛАВА 7 Работа с реляционными данными
285
iii!HiN\in. Разве отдельный основанный на соединении запрос не будет в этой ситуации быстрее?
Ответ. В период тестирования бета-версии Microsoft ,NET Framework в одной из групп новостей развернулось широкое обсуждение.дашелг» вопроса. Двое разработчиков пришли к выводу, что выборка данных от отдельных запросов неэффективна. Их предпосылки были логичными и разожгли мое ikkVui ьггегю. и я решил проверить, как применение отдельных запросов влияет на производительность. Я создал приложение на Visual Basic .Ni- Г. использующее ADO.NET, и приложение на Visual Basic, работающее с ADO 2.6. Оба приложения выбирали из таблиц Customers, Orders и Order Details БД Norrhwind информацию о клиентах, находящихся в США. Для каждого приложения я написал различные процедуры, получавшие данную информацию с использованием запросов разного типа.
Процедура, тестировавшая соединяющий запрос, просто выбирала данные в отдельный объект i'kHnTable, для которого не былил.вдиыы ограничения. Я использовал следующие запросы:
Запрос, основанный на соединении
SELECT C.CustomerlD. CCoepariyName. C.ContactName, С. Phone, O.OrderlD, 0.EmployeelD, O.OrderDate, D.PicductIO, D Quantity. D.UnitPrlce FROM [Order Details] D, Orders 0, Customers С WHERE D.OrderlD = O.OrderlD AND O.CustomerlD = C.CustomerlD AND C.Country = N'USA'
Отдельныезапросы
SELECT Customer-ID, CompanyName, ContactName, Phone FROM Customers WHERE C.Country = N'USA'
SELECT
FROM Orders 0, Customers С
WHERE O.CustomerlD = C.CustomerlD AND C,Country = N'USA'
SELECT O.OrderlD, D.ProductID, D. Quantity, !).Un1t?rice
FROM [Order Details] D, Orders 0, Customers С WHERE D.OrderlD = O.OrderlD AND O.CustomerlD = C.CustomerlD AND C, Country = N'USA'
Параметризованные запросы
SELECT CustomerlD, CompanyName, ContactName, Phone
FROM Customers WHERE C.Country = N'USA'
SELECT EmployeelD, OrderDate
FROM Orders WHERE CustomerlD = ?
SELECT OrderlD,
FROM [Order Details] WHERE OrderlD = ?
286
Часть III Автономная работа с данными: обьен- DataSet модели ADO.NET
Как и многие другие участники группы новостей, я что производитель-
ность соединяющего и пщхтецшзщнчг.итых запросов окажется выше производительности отдельных запросов. К счастью, прежде чем поделиться своим мнением с другими, я провел ряд тестов. Оказалось, что отдельные запросы работали быстрее всех. В среднем, их производительность были на 20% выше производительности соединяющего запроса и в 6-8 раз выше производительности параметризованных запросов.
Почему? siv. оптимизация запросов — не самая сильная моя сторона, ns:. полагаю, я все же смогу объяснить данный факт. Отдельные запросы вернули данные
быстрее, чем один соединяющий запрос, поскольку последний возвращал больше данных. Соединяющий запрос возвращает избыточные данные, В таблице Order Details может оказаться 100 записей, соответствующих одной записи таблицы Customers, и каждая из них содержит одинаковую информацию.
Я воспользовался методом v объекта (подробнее о нем — в гла-
ве 12) и записал содержимое объекта DataSet в XML-файл. Размер XML-файла, соответствовавшего объекту DataSet с результатами соединяющего запроса, почти в три раза превышал размер XML-файла, соответствовавшего и;'л..ектDataSet с результатами отдельных запросов. Соединяющий запрос может показаться более эффективным, потому что с ним проще работать, однако в действительности это не так, поскольку он возвращает больше данных.
Предыдущая << 1 .. 124 125 126 127 128 129 < 130 > 131 132 133 134 135 136 .. 260 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100