Джеффри Мак-Манус - Обработка баз данных на Visual Basic®.NET

Можно сказать, и да и нет. В этой главе рассматриваются только основы использования SQL Server и совсем не охвачены вопросы ежедневного администрирования базы данных, настройки производительности и т.д. Эту главу следует рассматривать как введение в SQL Server, а не подробное руководство по его использованию. В первой части главы приведены необходимые сведения, которые могли бы облегчить работу с SQL Server и развеять опасения, что для этого нужны какие-то сверхусилия. Конечно, работа с SQL Server включает более сложные операции, например миграцию приложений от однопользовательских систем к распределенным, но для этого вовсе не нужно обладать искусством "черной" магии. (А чтобы не потерять рассудок, нужно не перетруждаться и почаще консультироваться с врачами.)

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

Да. По сути, есть два основных преимущества использования хранимых процедур вместо кодирования запросов SQL в коде приложения.

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

2. Управляемость. Реализация запросов в виде хранимых процедур означает, что все запросы приложения хранятся в одном централизованном месте, а не разбросаны среди сотен тысяч строк кода. Более того, такая организация запросов позволяет использовать их повторно и одновременно для одной базы данных во многих проектах и приложениях. Это приводит к меньшему объему работы (кодирование/отладка/тестирование) и меньшей вероятности возникновения ошибок. Это также позволяет использовать систему безопасности SQL Server. Наконец, применение хранимых процедур позволяет использовать стратегию "разделяй и властвуй", т.е. специализацию при создании кода приложения. Разработчики программного обеспечения, которые специализируются на создании бизнес-логики и управлении потоком выполнения приложения, могут сфокусировать внимание на создании кода приложения, а организацией доступа к базе данных и созданием запросов могут заняться разработчики баз данных и серверной части системы.

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

В этой главе преследуется цель изложить основные принципы функционирования технологии ADO.NET. Здесь обсуждаются базовые операции и описываются базовые объекты провайдера данных ADO.NET, в частности Connection, Command, Parameter и DataReader. Далее (в главах 5, "ADO.NET: объект DataSet", 6, "ADO.NET: объект DataAdapter", и 7, "ADO.NET: дополнительные компоненты") рассматриваются более сложные объекты, которые тесно связаны с основным объектом ADO.NET — DataSet.

Разработчики приложений для работы с базами данных на основе Visual Basic уже привыкли к тому, что Microsoft каждые несколько лет предлагает новую усовершенствованную модель доступа к данным. Кроме новой трехбуквенной аббревиатуры, технология ADO.NET также предлагает новую модель API-интерфейсов и объектов. В течение последних нескольких лет разработчики уже успели познакомиться с предшественниками ADO.NET — технологиями ODBC, DAO, RDO и ADO. При знакомстве с каждой новой технологией им требовалось тщательно изучить ее назначение и принципы работы. При этом они часто задавали себе один и тот же вопрос: имеет ли смысл переходить на новую технологию? В большинстве случаев ответ был положительным, если только новшества не оказывали никакого влияния на текущие и будущие требования проекта. Действительно, чаще всего переход на новые технологии был вполне обоснован, за исключением технологии RDO (Remote Data Objects) для проектов с процессором баз данных Jet (потому что технология ОАО по-прежнему является более удачной технологией работы с Jet).