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

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