Обработка баз данных на Visual Basic®.NET
Шрифт:
Хотя
Полезной модификацией сценария может стать включение команды PRINT в стратегически важных местах сценария, например для отображения некоторых фрагментов текста в диалоговом окне Messages программы SQL Query Analyzer. Это позволит отслеживать прогресс выполнения сценария, а также использовать выводимые сообщения для отладки сценария: поиска и устранения замеченных ошибок. Использование команды PRINT совсем не обязательно и не имеет прямой связи с процессом создания базы данных.
Помните, что при использовании подобных пакетов команд SQL их можно запускать повторно нужное количество раз. Дело в том, что он создан так, чтобы полностью удалить и воссоздать повторно базу данных. При загрузке тестовых данных для проверки работоспособности базы данных не следует беспокоиться о повреждении или утрате данных при выполнении такого сценария. Кроме того, создавая базу данных с помощью пакета команд SQL, можно легко переносить структуру базы данных на другие cерверы. Это позволяет создавать две совершенно разные физические базы данных: одну для создания приложения, а другую для работы.
Резюме
В этой главе представлены основные сведения об использовании СУБД SQL Server компании Microsoft для создания распределенных вычислительных систем. И хотя здесь рассматривается SQL Server 2000 компании Microsoft, все описанные основные действия по управлению базами данных, но уже с особенностями реализации, применимы и к СУБД других компаний – Oracle, Sybase, Informix и пр. Не забывайте, что при наличии драйвера ODBC или провайдера OLE DB, которые позволяют при разработке приложений абстрагироваться от конкретной реализации СУБД, с этими базами данных можно работать с помощью Visual Basic .NET.
Вопросы и ответы
Меня всегда пугала сложность работы с SQL Server, потому что эта СУБД казалась мне "черным ящиком". Мне знакомы случаи, когда люди чуть ли не сходили с ума от работы по созданию серверной части приложения. Неужели материала этой главы будет достаточно?
Можно сказать, и да и нет. В этой главе рассматриваются только основы использования SQL Server и совсем не охвачены вопросы ежедневного администрирования базы данных, настройки производительности и т.д. Эту главу следует рассматривать как введение в SQL Server, а не подробное руководство по его использованию. В первой части главы приведены необходимые сведения, которые могли бы облегчить работу с SQL Server и развеять опасения, что для этого нужны какие-то сверхусилия. Конечно, работа с SQL Server включает более сложные операции, например миграцию приложений от однопользовательских систем к распределенным, но для этого вовсе не нужно обладать искусством "черной" магии. (А чтобы не потерять рассудок, нужно не перетруждаться и почаще консультироваться с врачами.)
Если большинство моих запросов очень просты и не содержат сложных логических выражений, нужно ли мне использовать хранимые процедуры?
Да. По сути, есть два основных преимущества
1. Производительность. Для многих программистов производительность является единственной причиной, по которой они стремятся использовать хранимые процедуры. Более высокая производительность хранимой процедуры по сравнению с кодом приложения связана с тем, что хранимая процедура откомпилирована и спланирована в SQL Server еще до вызова на выполнение. При передаче серверу на выполнение обычной команды SQL от клиентского приложения она должна быть обработана синтаксическим анализатором, откомпилирована, а также должен быть создан план ее выполнения. Поэтому выполнение всех этих действий непосредственно во время работы системы связано с большими накладными расходами и снижением производительности.
2. Управляемость. Реализация запросов в виде хранимых процедур означает, что все запросы приложения хранятся в одном централизованном месте, а не разбросаны среди сотен тысяч строк кода. Более того, такая организация запросов позволяет использовать их повторно и одновременно для одной базы данных во многих проектах и приложениях. Это приводит к меньшему объему работы (кодирование/отладка/тестирование) и меньшей вероятности возникновения ошибок. Это также позволяет использовать систему безопасности SQL Server. Наконец, применение хранимых процедур позволяет использовать стратегию "разделяй и властвуй", т.е. специализацию при создании кода приложения. Разработчики программного обеспечения, которые специализируются на создании бизнес-логики и управлении потоком выполнения приложения, могут сфокусировать внимание на создании кода приложения, а организацией доступа к базе данных и созданием запросов могут заняться разработчики баз данных и серверной части системы.
ГЛАВА 4
Модель ADO.NET: провайдеры данных
Порой кажется, что не успели еще разработчики приложений баз данных привыкнуть к новой технологии, как компания 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.
Обзор технологии ADO.NET
Разработчики приложений для работы с базами данных на основе Visual Basic уже привыкли к тому, что Microsoft каждые несколько лет предлагает новую усовершенствованную модель доступа к данным. Кроме новой трехбуквенной аббревиатуры, технология ADO.NET также предлагает новую модель API-интерфейсов и объектов. В течение последних нескольких лет разработчики уже успели познакомиться с предшественниками ADO.NET — технологиями ODBC, DAO, RDO и ADO. При знакомстве с каждой новой технологией им требовалось тщательно изучить ее назначение и принципы работы. При этом они часто задавали себе один и тот же вопрос: имеет ли смысл переходить на новую технологию? В большинстве случаев ответ был положительным, если только новшества не оказывали никакого влияния на текущие и будущие требования проекта. Действительно, чаще всего переход на новые технологии был вполне обоснован, за исключением технологии RDO (Remote Data Objects) для проектов с процессором баз данных Jet (потому что технология ОАО по-прежнему является более удачной технологией работы с Jet).