Хочу сразу сказать, что в данной статье рассматривается мой личный взгляд на существующее в нынешнее время положение вещей. Возможно, некоторые вещи покажутся вам спорными, а кое-где я могу и ошибаться. Однако, думаю, в целом идеи и принципы, изложенные ниже, достаточно верны. По крайней мере, они находят себе неплохое подтверждение на практике.

Начиная с самой первой версии Delphi эта среда комплектуется, на мой взгляд, одной из самых удобных библиотек для работы с базами данных. Сначала доступ к БД мог осуществляться только через BDE, набор библиотек собственной разработки Borland, если разработчик желал что-то другое, приходилось разрабатывать собственные компоненты или искать их на стороне. Затем, в следующих версиях, были добавлены другие библиотеки, такие как ADO и dbExpress, и теперь BDE считается устаревшей технологией.

Delphi никогда не являлась специализированным средством разработки баз данных, и, в связи с этим, нельзя назвать один формат баз данных, к которому она привязана. Выбор, с какой БД будет работать приложение, остается на совести разработчика.

Речь здесь пойдет именно о таком выборе, причем в самом общем виде. А именно, о выборе не просто формата базы данных и фирмы-производителя, но о выборе идеологии ее построения. Если разрабатывается приложение, которое будут использовать на большом предприятии, в котором будут хранится большие массивы информации, то вопрос здесь не стоит, выбирается подходящий сервер из популярного набора MSSQL, Oracle, Informix и так далее. Однако до сих пор есть, думаю, и останется, потребность в маленьких программах, которыми пользуется один или несколько человек. Речь не идет о программах типа "Дневник Васи Пупкина", но о вполне серьезных приложениях, например, для работы со складом или обеспечения простого документооборота. В общем, о тех случаях, когда хочется автоматизировать работу, а использовать имеющиеся большие системы автоматизации не хочется, причем по самым разным причинам. Впрочем, чаще всего из-за того, что это достаточно дорого. Тогда одним или несколькими программистами пишется маленькая программа с удобным интерфейсом для работы с данными. Вот здесь выбор хранилища данных не так очевиден.
Хорошо, если уже есть сервер баз данных, к которому остается только написать интерфейс. Если же его нет, или планируется устанавливать это приложение в разных местах, то использовать сервер становится неудобно, и громоздко, да и денег платить нужно за лицензии (Случай, когда любой сервер стоит 80 рублей, я не рассматриваю. Не важно, по какой причине).

Между тем, уже очень давно есть файл-серверные базы данных, которые и используются в таких программах. Delphi, разумеется, содержит библиотеки и компоненты для работы с ними, в частности, с dBase и Paradox через BDE, с Access через ADO, и так далее, выбор достаточно широк. В этом случае и не требуется устанавливать сервер, и платить за лицензии не надо. Если еще учесть, что файл-серверные базы гораздо старше чем клиент-серверная технология, для них есть куча наработок и опыт разработки, казалось бы, все хорошо. В итоге получается простое в установке приложение, и при этом достаточно быстро работающее с данными. Вот здесь-то мне и хочется обратить внимание на некоторые недостатки такого решения, каждый из которых значит довольно мало, но совокупность которых может привести к тому, что стоимость программы будет выше, чем при использовании дорогого сервера БД.

Итак, что мы приобретаем и, конечно, что теряем, выбирая файл-серверную или клиент-серверную технологии? В те давние времена, когда всем известная фирма только что представила пользователям нечто, прозывающееся "Чикаго", мне довелось участвовать в развитии одной довольно большой системы, написанной на FoxPro, конечно, под DOS. Как-то я услышал от одного из программистов примерно следующее: "База данных клиент-сервер. О-о-о, это круто!". И тогда между нами состоялся следующий диалог:
- А мы тут с чем работаем?
- А это файл-сервер, сам видишь, таблицы у нас на сервере Novell, мы их оттуда и читаем
- Ну а твой клиент-сервер, в чем разница?
- А это когда рабочее место дает запрос к серверу, он его исполняет, и отправляет ответ обратно.
- Ну... И в чем разница? Я тут говорю открыть таблицу на сервере - оно открывает же!
- Так там не таблица, а даешь запрос, сервер выполняет, и на клиента идет только то, что нужно!
- И что с того? Мне нужно таблицу обработать, например?!
- Там ее сервер обрабатывает, сеть меньше нагружена, и клиент тоже!
- Тоже мне, преимущество! У нас тут пользователи по модему на 2400 работают, и компьютеры на местах самые примитивные, и ничего, все в порядке
- Ну не знаю, клиент-сервер - это круто!

Примерно такая беседа и произошла, скорее всего, это было в курилке, где обычно и ведутся подобные разговоры. Как видно, тогда ему самому не было понятно, что такое "технология клиент-сервер", и уж конечно, тем более мне. Поэтому сначала я дам определение, что же я подразумеваю под технологией клиент-сервер, и чем она отличается от файл-серверной технологии. Все просто: если файловая СУБД - это просто набор файлов определенной структуры, клиент-сервер предполагает наличие специальной программы, обрабатывающей запросы клиентов на обработку данных. При этом при взаимодействии клиент-сервер клиент не имеет доступа к самим данным и общается только с сервером. Как именно - не столь важно, но обычно с сервером БД общение происходит с использованием SQL, в остальных случаях сервер называют "сервером приложений". Как правило, сервер, помимо собственно хранения данных, обеспечивает дополнительные возможности, а именно механизм транзакций, триггеры и хранимые процедуры. В случае, когда приложение установлено вместе с базой данных и с ним работает один пользователь, может создаться впечатление, что сервер будет только мешать, вполне достаточно приложения, которое будет работать напрямую с файлами базы данных. Однако давайте рассмотрим этот выбор с позиций разработки и эксплуатации всего приложения в целом, и сравним, что получается при использовании файлов БД и сервера БД, установленного локально.

Что же, собственно, требуется от обычного приложения, работающего с данными? Достаточно серьезного, сделанного на заказ или на продажу? Давайте посмотрим, чего хочет пользователь. Конечно, часто пользователь сам этого не знает, но можно догадаться, ведь каждый программист тоже пользуется какими-то программами. На мой взгляд, требований довольно много, даже для простой однопользовательской программы работы с данными:

Скорость работы. Программа должна работать быстро и не мозолить глаза часиками, ну или хотя бы показывать их как можно реже. Здесь первенство, как правило, за файловыми СУБД. Просто потому, что отсутствует сервер, а скорость доступа к файлу определяется операционной системы, тем более, что база находится там же, где и приложение. Однако, немного забегая вперед, могу сказать, что обычно у сервера баз данных есть возможность создавать хранимые процедуры, что позволяет перенести часть обработки на сервер. Впрочем, когда база находится там же, где и приложение, это довольно спорное преимущество, особого выигрыша в скорости может и не быть, но часто получается, что из-за переноса расчетов на сервер все приложение начинает работать быстрее, чем файл-серверное.

Легкость установки. Даже если приложение написано просто "для себя", и его можно ставить вручную, это рано или поздно надоедает и начинаешь задумываться над созданием дистрибутива. В случае файловой БД достаточно просто поставлять готовые файлы или создавать их при установке. Правда, в случае Delphi дело осложняется тем, что доступ к БД часто происходит через Borland Database Engine (BDE), а ее ставить требуется, да и места она прилично занимает. Правда, всегда можно взять компоненты от сторонних разработчиков, а начиная с пятой версии Delphi есть компоненты доступа через ADO. Сервер баз данных чаще всего ставить нужно отдельно, однако почти всегда есть подробное описание, как включить установку в собственный дистрибутив, но все же это сложнее.

Надежность. Чрезвычайно широкое понятие, здесь и устойчивость к глупым действиям пользователя, и случай "электричество кончилось", и много чего другого. Мне, как пользователю, хотельсь бы следующего:

Устойчивость к сбоям. Как в аппаратной части, так и в системе. К сожалению, в Delphi нет стандартных средств восстановления файл-серверных баз данных после сбоя, например, неожиданного отключения питания. Приходится пользоваться тем, что есть, в BDE, например, есть функции проверки таблиц и переиндексации, но почему-то почти всегда бывает так, что какой-то из файлов испорчен так, что восстановить нельзя. В других случаях приходится устанавливать средства работы с БД, как, например, в случае Access, средства проверки и восстановления есть, но приходится устанавливать собственно Access, что неудобно. Подавляющее же большинство серверов БД имеет встроенные средства проверки и восстановления, чаще всего пользователь даже не замечает последствий.
Сохранение целостности данных. Здесь у файл-сервера практически ничего и нет. В некоторых случаях есть внешние и первичные ключи, контроль значений отдельных полей - и все. Все остальное программируется собственно в приложении. О триггерах можно и не мечтать, а ведь их использование может значительно упростить алгоритм работы.
Надежность при эксплуатации. Если пользователю сообщили, что данные записаны - они должны быть записаны. К сожалению, в базах данных на основе файлов это часто отдается на откуп системе, хорошо, если контролируется действительная запись в файл, в идеале приходится еще и проверять целостность файла и индексов после записи. Здесь бы помогли транзакции, но все, что я видел, не идет ни в какое сравнение с механизмом транзакций сервера.

Как видно, при использовании файл-серверной технологии приходится писать либо средства проверки и восстановления базы данных, либо дополнительно устанавливать приложения для работы с этой базой данных. Отслеживать, целы ли данные тоже трудно, например, при изменении одновременно двух связанных таблиц как правило приходится молится, чтобы не произошел сбой питания (о наличии UPS, понятно, разговора не идет), и предусматривать полную проверку базы данных при запуске после сбоя. Яркий пример - 1С, которая работает именно так.

Возможность создания страховочных копий. Тоже немаловажный вопрос, какой бы надежной ни была база данных, от краха жесткого диска не спасет ничего, а причин этого много - заводской дефект, прострелили из автомата, наводнение. Или пользователь скачал очень полезную программу из интернета и запустил... Причем полная потеря данных случается гораздо чаще, чем хотелось бы. Поэтому всегда рекомендуется предусмотреть возможность создания архивов данных. С сервером, как правило, поставляются средства для создания backup, причем, как правило, в процессе работы с базой. В файл-сервере забота об этом полностью ложится на плечи программиста.

Легкость в сопровождении. Вполне естественно, программа должна просто работать, и все проблемы должны решаться простой ее переустановкой. Если в приложении с файловой базой данных предусмотрено восстановление данных, как правило, от пользователя больше ничего и не требуется. Другой случай, когда совместно с приложение установлен еще и сервер, до которого пользователю часто вообще дела нет и объяснить ему, зачем нужна эта лишняя вещь очень трудно. Еще недавно я сказал бы, что здесь преимущество очевидно. Но в последнее время производители серверов обратили внимание на эту проблему, и сейчас есть несколько однопользовательских версий серверов баз данных, не требующих отдельной установки и запуска. Правда, как правило, эти редакции обладают меньшей функциональностью, но их возможности в любом случае выше простых файлов с данными. С другой стороны, как только где-то появляются хотя бы два пользователя, да еще и, представьте себе, подключенные к интернету, то скорее всего, последствия будут. И пренеприятные. Поэтому, как правило, всегда имеется личность, присматривающая за всем этим. Сейчас серверы БД практически требуют присмотра и сопровождения не более, чем, скажем, каталог с документами офиса, или та же файл-серверная база данных. Эти обязанности вполне можно возложить на эту самую личность, ничего, его все равно обычно эникейщиком называют.

Удобный для пользователя интерфейс. С точки зрения программиста, удобный интерфейс - это тот, который проще программировать, что почти всегда не соответствует пожеланиям пользователя. Как правило, малые приложения имеют простой интерфейс для доступа к нескольким таблицам, и с этой точки зрения файл-серверная технология является более удобной, как правило, с сервером приходится работать через запросы, и часто это приводит к тому, что табличное представление редактировать нельзя, приходится искать компромисс. Впрочем, в значительной мере удобство интерфейса значительно больше зависит от искусства самого программиста, чем от используемой базы данных.

Возможность масштабируемости. Если вы совершенно уверены, что с базой данных будет работать только один пользователь, то скорее всего через некоторое время вас попросят сделать так, чтобы одновременно в ней могли работать два человека. Практически наверняка. В случае наличия сервера вопрос о том, один человек работает с ним или несколько вообще не стоит, как правило, достаточно просто указать только его местонахождение. С файл-сервером ситуация на порядок сложнее. Как правило, если при написании программы предполагался только один пользователь, для двух ее приходится исправлять, причем иногда довольно значительно.

Низкая стоимость. Стоимость программы складывается из затрат на ее разработку и написание, стоимости лицензий и стоимости сопровождения и других параметров, их довольно много. Причем сопровождение в некоторых случаях обходится дороже всего. Файл-серверные базы данных чаще всего не требуют платы производителю. Например, при использовании BDE с базой в формате dbf вы можете ставить свое приложение заказчикам, без всяких отчислений денег на сторону. Сервер баз данных стоит денег. Такое мнение еще лет пять назад было вполне справедливым, но сейчас есть и просто бесплатные серверы БД, да и персональные версии как правило бесплатны или довольно дешевы. Сейчас, например, я не вижу препятствий к тому, чтобы использовать, например, Firebird или Firebird Personal, или Yaffil personal. Недавно и настольная версия MS SQL (MSDE) также стала бесплатной.

Мда... Неожиданно получилось довольно много пожеланий. И все кажутся важными, на мой взгляд, перечисленными выше свойствами должно обладать даже самое простое приложение. Что же получается в итоге? Помимо перечисленного, для разработчика весьма желательно выбрать технологию так, чтобы приложение можно было написать максимально быстро и сделать его простым. Вот здесь использование файл-серверной БД способно значительно осложнить разработку. Давайте посмотрим. Раньше в приложениях для работы с файлами было очень много участков, которые делали примерно следующее: открыть таблицу - пройти по записям и что-то сосчитать - выдать результат. Помню, меня очень восхитили в свое время только появившиеся в FoxPro команды для работы с SQL, особенно select. Никакого цикла, просто нужно написать одну строчку - и все, есть та выборка, что нужно.

Сейчас все СУБД в той или иной мере обладают встроенным языком SQL, но в файловых базах данных он все-таки не обладает той мощью, которую обеспечивает сервер. Нет транзакций, а если и есть, то достаточно примитивно устроенные. К сожалению, мне пришлось столкнуться со странным ограничением BDE, когда в транзакции Paradox можно изменять не более 256 записей. Обнаружилось это увы, уже при внедрении. Нет триггеров. Казалось бы, в данном случае это и не нужно, но наличие таких "вкусностей" на практике позволяет значительно уменьшить размер кода приложения, и попутно повысить согласованность данных. Простой пример: нужно ввести в базу данных документ, например, расходную накладную. Причем требуется, чтобы нельзя было списать больше товара, чем есть сейчас на складе. Если у нас сервер БД, это действие тривиально, просто открываем транзакцию и начинаем вносить строчки в базу. Триггер при этом сверяется с имеющимся количеством, и если в какой-то строке количество больше - просто выдается ошибка. На клиенте остается просто откатить транзакцию и сообщить пользователю о причине. В файл-серверной технологии приходится делать предварительную проверку, что затем может аукнуться при переходе на многопользовательский режим, никто ведь не гарантирует, что второй пользователь не изменил уже проверенную информацию!

Если учесть все сказанное выше, я не могу рекомендовать использование файл-серверной технологии ни в каком случае. Единственное преимущество ее на данный момент - скорость работы, но и оно под сомнением, если грамотно спланировать базу данных для сервера и максимально использовать его особенности, приложение в целом может заработать быстрее. Стоимость сопровождения также можно уменьшить и практически приблизить к затратам на остальные программы, когда либо пользователь сам следит за их работоспособностью, либо это поручается службе поддержки фирмы. Главные причины, заставляющие ранее отказываться от сервера, его стоимость, неудобство инсталляции, большой размер поставки и сложность сопровождения, в настоящее время практически исчезли. Преимущества же клиент-серверной технологии, в частности, высокая защищенность данных и скорость разработки программы, являются очень весомыми.

Правда, переход от файл-серверной технологии к серверным СУБД не является простым, фактически, полностью меняется как идеология доступа к данным и их обработки, так и способы построения их структуры. Если пытаться просто переносить наработки с одной технологии на другую, в результате можно получить просто неработоспособное приложение, или приложение, производительность которого упала настолько, что работать просто невозможно.

В связи со сказанным выше, могу еще заметить, что начинать учиться разработке баз данных на файл-серверной технологии, на мой взгляд, просто вредно. Тем более на Delphi, в поставку которого обычно входит сервер Interbase. Только воспользоваться. Часто говорят: "Начну с файловой базы, а потом, когда научусь, перейду". Не научитесь. Хотя бы потому, что полностью SQL на файл-серверной базе данных выучить нельзя, да и принципы общения с базой данных весьма различаются. Потом придется перестраиваться, а это иногда гораздо труднее.

Мне пришлось совершить такое перестроение еще в прошлом веке, и теперь я уже просто не могу писать приложения для файл-серверной технологии. Последнее такое приложение пришлось несколько лет назад просто переписать заново, уже с использованием сервера. Помимо того, что надежность его работы возросла очень значительно, могу сказать, что времени на написание его заново ушло в несколько раз меньше, чем для прежнего, даже с учетом того, что мне пришлось переносить данные на новое место жительства. При этом немаловажным фактором стало то, что структура базы данных была полностью пересмотрена, и большая часть расчетов была перенесена в саму базу. С тех пор все подобные приложения я пишу только по клиент-серверной технологии, чего и вам желаю.

Дизайн и поддержка: Silicon Taiga

Обратиться по техническим вопросам