(Возврат на основную страницу)
Умри Access, умри!
Мне довелось достаточно тесно познакомиться с Office 2007 и новой версией Access, и каждый раз, когда я вижу Access, меня посещает одна и та же мысль — когда же Microsoft, наконец, избавится от этого продукта? Зачем он вообще нужен? Мелким организациям все равно приходится платить за него, тогда как Microsoft предлагает и другие, при этом бесплатные, решения.
Вы можете получить бесплатную версию SQL Server Express или Visual Studio Express. Нужно учесть, что Visual Studio 2005 поставляется с большим числом шаблонов, так что создание необходимого кода оказывается достаточно простым делом. Мне кажется, что продолжение поддержки Access — бессмысленное дело и настало время ему умереть.
И дело не только в том, что Access отслужил свое. Использование SQL2K5 Express/VS05 — более разумное решение. Они не только бесплатны, но их применение обеспечивает гораздо более плавный путь миграции. Я сомневаюсь, что мелкий бизнес сознательно предполагает оставаться мелким до конца своих дней. Как владелец предприятия, вы должны смотреть в будущее и анализировать возможности, которые позволят вашей компании занять более удачную позицию на рынке. Так вот, отказ от использования Access — это правильное бизнесрешение. Вы не только экономите деньги, но и получаете безболезненный путь развития по мере роста вашего бизнеса. При переходе от SQL2K5 Express к Workgroup или Standard редакции все, что нужно сделать, — подключить файлы данных к новой системе, и все заработает, как и раньше. При использовании Access у вас просто нет нормального пути перехода. Когда вы вырастаете за рамки, вам приходится конвертировать БД в формат соответствующей СУБД, а потом приводить в соответствие пользовательский интерфейс. Это весьма нетривиальная задача, и часто на этом пути вам приходится корректировать дизайн системы. Мир ИТиндустрии полон рассказов о переходе с Access на SQL Server.
Стоит упомянуть, что файлы БД SQL Server не такто просто испортить, тогда как файлы БД Access ломаются очень легко. Помещаете файл БД на сервер и очень скоро начинаете его ремонтировать. Давайте посмотрим правде в глаза, Access — устаревшее решение, ограничивающее возможности вашего роста. Что было бы, если бы мы все строили свой бизнес на решениях, основанных на Access? Ступить было бы негде от бесчисленных серверов, обслуживающих эти базы данных.
Столь же выигрышным выглядит SQL Server с точки зрения сопровождения. При использовании Access ваши файлы могут быть где угодно: от рабочей станции до сервера. Если не знать точного нахождения, найти их будет весьма непросто, особенно если вы не пользовались этой БД некоторое время. Файл БД можно удалить прямо у вас изпод ног, и вы теряете все свои данные. Или ктото просто переносит файл и не сообщает вам об этом. И это далеко не все, что может случиться с вашей БД на Access. SQL Server свободен от этих проблем. База данных подключена в среду SQL Server и остается там. Пока сервис работает, никто не сможет удалить БД. Если же это случится, у вас, скорее всего, есть резервная копия. Управление БД в среде Access выглядит просто смешно по сравнению с аналогичными возможностями SQL Server.
У Access нет сходных средств управления безопасностью, диспетчеризации заданий, подготовки отчетов и т. д. Вы сможете сделать средствами SQL Server такие вещи, о которых в среде Access невозможно даже и мечтать. Да, я говорил, что Access стоит денег, а SQL Server нет?
Как бы то ни было, давайте вместе прибьем Access.
Как создать поврежденную базу данных при помощи BULK INSERT/UPDATE и BCP — SQL Server в качестве HEX редактора
В этой статье я покажу, как использовать сочетание BULK INSERT, UPDATE и параметра BCP queryout для создания повреждений базы данных, которые вы затем используете для процесса проверки непротиворечивости базы в своей среде.
Как узнать, что процесс проверки и извещения о непротиворечивости базы данных работает? Вам придется в действительности испортить базу, чтобы полноценно протестировать свои процедуры (именно так я обнаружил, что задание проверки непротиворечивости базы данных в служебном пакете 2005 SP2 не работает).
Я не был уверен насчет того, что следовало написать в блоге первым: запись о том, как используется BULK INSERT для загрузки сырых данных, или эту, так что раз тема по checkdb сейчас находится в печати, то я остановлюсь на этой записи.
Эта статья, на самом деле, относится в основном к SQL Server 2005, но, приложив небольшие усилия, я смог заставить это заработать и в SQL Server 2000; к сожалению, мое желание сделать это не настолько сильно, как в случае 2005, где можно поговорить о многих интересных подробностях.
Выборка на основе списка произвольных значений — динамический SQL или анализ списка значений с помощью пользовательской функции?
Основанный на множествах метод обработки данных, применяемый в SQL Server, не слишком подходит для работы с критериями на основе списков произвольных значений. Есть, конечно, оператор IN, но как передать такой список в хранимую процедуру и как получить эффективный план исполнения без перекомпиляции при каждом запуске запроса?
В дискуссионных группах по Microsoft SQL Server часто обсуждают два вопроса:
1. Как передать массив в хранимую процедуру?
2. Как сделать выборку на основе списка значений?
Примеры:
1. Пользователь ищет работу, указывая список подходящих регионов или населенных пунктов.
2. Пользователь помечает сообщения в почтовом ящике, чтобы потом их удалить.
Постановка задачи
Давайте рассмотрим конкретный сценарий, чтобы иметь возможность тестировать и сравнивать разные решения. Определим структуру таблиц и хранимую процедуру для обработки заказов. Статус заказа при переходе от одной стадии его жизненного цикла к другой меняется, например заказ может быть отправлен, просмотрен, подтвержден или ждать подтверждения, отклонен, выполнен и т. д.
Сначала определим таблицу orderStatuses:
create table dbo.OrderStatuses(
orderStatusID tinyInt primary key,
orderStatusName varchar(30),
orderStatusDescription varchar(255)
)
Для тестирования мы будем пользоваться упрощенной версией таблицы orders, содержащей ссылки на таблицу пользователей и таблицу orderStatuses, а также дополнительную информацию в столбце типа varchar(200):
create table orders(
orderID int identity(1,1) primary key clustered,
userID int not null,
orderStatusID tinyInt not null,
orderInfo varchar(200)
)
В этой статье мы рассмотрим несколько реализаций хранимой процедуры, возвращающей число заказов для данного пользователя и список соответствующих им статусов. Заготовка процедуры приведена ниже:
create procedure
orders_sel_by_userID_orderStatusList
@userId int,
@orderStatusList varchar(100)
as begin
set noCount on
<здесь
будет
код
реализации>
end
Для заполнения таблицы воспользуемся следующим сценарием:
set noCount on
declare @StatusCount int set @StatusCount = 7
declare @UserCount int set @UserCount = 50
declare @Count int set @count = @StatusCount *
@UserCount * 10000
declare @i int set @i = 1
while @i <= @count begin
insert into orders(userID, orderStatusId,
orderInfo) values(@i % @UserCount + 1, @i %
@StatusCount + 1, 'IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII')
set @i = @i + 1
if @i % 10000 = 0 print @i
end
set noCount off
Наконец, нам потребуется индекс на столбцах userID и orderStatusID:
create index orders_UserID_orderStatusID
on orders(userID, orderStatusID)
Для тестирования производительности каждой реализации я пользовался сценарием, который можно загрузить по ссылке http://www.sqlserverperformance.com/mm_list_random_values.zip (ZIP — 3,12 Кб).
Я исследовал производительность при передаче одного значения statusID, потом двух и трех значений, а также когда при последовательных запусках процедуры передаются разные наборы параметров.
Хостинг. Часть 1
Трижды я собирался опубликовать в своем блоге статью о хостинге, и трижды уходил от темы, сначала написав об исключениях, потом о совместимости приложений и, наконец, о финализации. На этот раз я твердо намерен довести дело до конца.
Пожалуй, мне нужно объяснить, почему написание этой публикации заняло так много времени. Частично в этом виноват отпуск. День благодарения я провел, катаясь на лыжах в Уистлере. Затем я ненадолго отправился в Скоттсдейл, поздравить с днем рождения друга и навестить своих родителей, а после — больше трех недель отдыхал от сиэтлской зимы на Мауи.
Другой причиной стал творческий кризис. Хостинг — необыкновенно обширная тема: внутренняя спецификация Whidbey Hosting Interfaces занимает более 100 страниц, и эта спецификация покрывает лишь сами интерфейсы хостинга. Но у хостинга есть масса других аспектов, таких как конфигурирование политик безопасности для различных доменов приложений и применение COM или управляемого C++ для того, чтобы заставить управляемое приложение работать на неуправляемом хосте. Охватить их все нет никакой возможности.
Тем не менее приступим.
На PDC (Professional Developers Conference) я был вроде туриста, однако я все же постарался оправдать свое присутствие на конференции, приняв участие в групповом обсуждении темы хостинга. Помимо меня, в дискуссии участвовали двое руководителей проектов в области CLR, архитектор CLR, представители Avalon/Internet Explorer, SQL Server, Visual Studio/Office и — к моему огромному удовольствию — представитель IBM в сфере DB2.
Всем участникам дискуссии было совершенно ясно, что команда CLR не справилась с задачей определения понятия «хостинг». Хостингом можно считать:
• Сочетание неуправляемого и управляемого кода в рамках одного и того же процесса.
• Работу нескольких приложений, каждое из которых выполняется в собственном особым образом сконфигурированном домене приложения — AppDomain.
• Использование неуправляемых интерфейсов хостинга, описанных в mscoree.idl.
• Конфигурирование способа функционирования CLR в процессе, например отключение параллельного сбора мусора через конфигурационный файл приложения.
Хотя интерфейсы хостинга, описанные в mscoree.idl, — всего лишь малая часть того, чем мог бы быть хостинг, я сосредоточусь именно на них.
В версиях CLR V1 и V1.1 мы предоставили несколько APIфункций, дававших неуправляемому процессухосту ограниченный контроль над CLR. Этот ограниченный контроль включал в себя возможность выбирать версию CLR для загрузки, создавать и конфигурировать объекты AppDomain из неуправляемого кода, обращаться к ThreadPool и выполнять еще некоторые фундаментальные операции.
Кроме того, мы знали, что рано или поздно потребуется поддержка хостов, которые управляют всей памятью процесса и используют диспетчеризацию заданий без вытеснения (nonpreemptive scheduling), а может даже «легкие» волокна (fibers) вместо потоков ОС. Так что мы добавили коекакие зачаточные (и, увы, несостоятельные) API для управления волокнами и памятью. Это неизбежно происходит при добавлении функций, которые, на твой взгляд, рано или поздно тебе понадобятся, вместо функций, которыми ктото реально пользуется и дает по ним свои отзывы.
При близком рассмотрении API для хостинга в версиях V1 и V1.1 можно понять, что нам нужно для поддержки ASP.NET и некоторых других сценариев вроде тех, что включают в себя EnterpriseServices, Internet Explorer или VSA. Кроме того, появляются догадки о том, что необходимо для нормального сосуществования в рамках SQL Server.
Разумеется, в Whidbey мы преобразовали эти догадки по поводу SQL Server в жесткие требования. А также постарались обобщить каждое расширение для SQL Server, чтобы оно подходило и для других сценариев хостинга. На самом деле, удивительно, что команда SQL Server до сих пор с нами разговаривает — каждый раз, когда они нас о чемто просят, мы говорим «нет» и даем им нечто, что не слишком здорово работает с SQL Server, зато замечательно подходит для других хостов.
В нашем следующем продукте (Whidbey) мы сделали попытку доработать существующую поддержку хостинга и существенно расширить ее для большого числа новых сценариев. Так что я не буду больше тратить время на обсуждение оригинальных API для хостинга из версий V1 и V1.1, за исключением случаев, когда это будет укладываться в рамки дискуссии о Whidbey.
Кроме того, я собираюсь пропустить все вступительные вопросы вроде «когда нужно использовать хостинг», поскольку именно они послужили причиной моего творческого кризиса. Вместо этого я намерен осветить более интересные с технической точки зрения темы. Возможно, после знакомства с деталями мы сможем сделать шаг назад и увидеть общие закономерности.
(Возврат на основную страницу)