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

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_NULLS ON

GO

/****** Object: Stored Procedure dbo.InsertEmployeeOrg Script Date: 10-Jul-02 12:41:13 PM ******/

CREATE PROCEDURE dbo.InsertEmployeeOrg (

 @FirstName varchar(50),

 @LastName varchar(70),

 @DepartmentID int,

 @Salary money

)

AS

 SET NOCOUNT OFF;

 INSERT INTO tblEmployee(FirstName, LastName, DepartmentID, Salary) VALUES

  (@FirstName, @LastName, @DepartmentID, @Salary)

GO

SET QUOTED_IDENTIFIER OFF

GO

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_NULLS ON

GO

/****** Object: Stored Procedure dbo.LastNameLookup Script Date: 10-Jul-02 12:41:13 PM ******/

create proc LastNameLookup

 @name varchar(40) as

 select * from tblCustomer where soundex(gname) = LastNameSoundex

GO

SET QUOTED_IDENTIFIER OFF

GO

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_NULLS ON

GO

/****** Object: Stored Procedure dbo.SelectEmployees Script Date: 10-Jul-02 12:41:13 PM ******/

create procedure dbo.SelectEmployees

AS

 SET NOCOUNT ON;

 SELECT FirstName, LastName, Department ID, Salary, ID FROM tblEmployee

GO

SET QUOTED_IDENTIFIER OFF

GO

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_NULLS ON

GO

/****** Object: Stored Procedure dbo.UpdateEmployee Script Date: 10-Jul-02 12:41:13 PM ******/

CREATE PROCEDURE dbo.UpdateEmployee (

 @FirstName varchar(50),

 @LastName varchar(70),

 @DepartmentID int,

 @Salary money,

 @Original_ID int)

AS

 SET NOCOUNT OFF;

 UPDATE tblEmployee SET FirstName = @FirstName, LastName = @LastName, DepartmentID = @DepartmentID, Salary = @Salary WHERE (ID = @Original_ID)

GO

SET QUOTED_IDENTIFIER OFF

GO

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER OFF

GO

SET ANSI_NULLS OFF

GO

/****** Object: Stored Procedure dbo.procEmployeesSorted Script Date: 10-Jul-02 12:41:13 PM ******/

CREATE PROCEDURE procEmployeesSorted

AS

 select * from tblEmployee

 order by LastName, FirstName return

GO

SET QUOTED_IDENTIFIER OFF

GO

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_NULLS ON

GO

/****** Object: Trigger dbo.trCustomerT Script Date: 10-Jul-02 12:41:14 PM ******/

create trigger trCustomerT

on dbo.tblCustomer

for insert, update

as

 update tblCustomer

 set tblCustomer.LastNameSoundex = soundex(tblCustomer.LastName)

 from inserted

 where tblCustomer.ID = inserted.ID

GO

SET QUOTED_IDENTIFIER OFF

GO

SET ANSI_NULLS ON

GO

Хотя сценарий, созданный автоматически с помощью программы SQL Server Enterprise Manager, достаточно хорош для запуска его даже в том состоянии, в котором он находится, его можно отредактировать нужным вам образом. Учтите, что при повторной генерации сценария внесенные вручную изменения будут утрачены.

Полезной модификацией сценария может стать включение команды 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 включает более сложные операции, например миграцию приложений от однопользовательских систем к распределенным, но для этого вовсе не нужно обладать искусством "черной" магии. (А чтобы не потерять рассудок, нужно не перетруждаться и почаще консультироваться с врачами.)

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

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

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