Способы доступа к базам данных

Disclaimer aka отмазка.

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

Базы всякие нужны, базы всякие важны…

Сразу разделим БД на 2 категории: однопользовательские и многопользовательские. К однопользовательским я без излишнего пацифизма отношу все БД, в которых отсутствует сервер. И сколько бы ни утверждалось в рекламе какого-нибудь движка БД, что он «позволяет многопользовательскую работу», если нет у этого движка сервера, т.е. сервиса/службы/приложения, работающего на одной вполне конкретной машине, к которому нужно обратиться, чтобы работать с данными, я считаю такой движок однопользовательским. Бывают заковыристые случаи. Например Access. Ничего не мешает выложить его mdb-файл на сетевой диск и работать с ним из ADO/DAO и т.п. В этом случае мы имеем однопользовательскую БД. Но если для работы запускается сам Access (MS Jet) на какой-то машине, и уже через него у всех идет работа с данными, т.е к нему идут обращения – это уже вполне многопользовательский вариант. Не шибко много, но много . Юзеров на 5, на 1-10-100 Мб БД. Но вернемся к нашим баранам. К доступу для разных БД.

Вспомним прошлый век…

Разберемся с однопользовательскими базами.

Dbf
Самый распространенный формат – xBase, он же dbf. Достался нам в наследство из ДОСа. Основные разновидности: Clipper и FoxPro, еще есть dBase. Кто из них распространеннее – я не знаю, да и не стремлюсь узнать. Более важно другое: при практически идентичной структуре самой базы (dbf), у них сильный разнобой в индексных файлах. Но по большому счету и это неважно. Важно другое. А именно: какая задача поставлена. Есть всего 2 вида:
1.    Есть локальная БД, но ДОСовый интерфейс уже не устраивает. Т.е. хочется красивых кнопочек, менюшек и т.п.
2.    Есть локальная БД, но нужно обеспечить работу 2-20-200 юзеров с этой БД. Тут уже совсем другая проблема – смена технологии.
В первом случае просто нужно «навести марафет». Т.е. обеспечить работу с dbf-ками через Windows-интерфейс.
Во втором случае все гораздо серьезнее. Тут простого решения быть не может, поскольку нужно менять кардинально технологию доступа на систему «клиент-сервер», а если юзеров действительно немало и/или они обрабатывают большие объемы, то придется городить более серьезную вещь – многозвеннную систему. Но об этом – позже (если получится).
А пока разберемся с первым, относительно простым случаем: есть куча dbf-ок, надо соорудить нечто, с красивыми кнопочками, менюшками, окошками и прочими бантиками. Вопрос интерфейса по большому счету не стоит – главное доступ к данным получить, а там уж нарисовать кнопки и т.п. можно любой формы и любого цвета. Начинаем думать: как до dbf-ок добраться? 

Первый ответ, очевидный (и по-моему неправильный): через BDE. Почему очевидный – потому что BDE есть у всех, кто с Delphi работает. А почему неправильный? Да потому, что BDE исторически была создана, чтобы обеспечить примерно одинаковый (универсальный) доступ к БД двух разных форматов: dBase и Paradox. Потом прилепили еще кучу более других форматов. В результате универсальности имеем кучу излишних настроек и  файлов, которые нужны для одного формата, но совершенно не нужны для другого. И соответственно имеем громоздкую систему работы, весящую 1.2-1.5 Мб минимум (если ручками все что не нужно поубирать и настройку делать тоже «ручками» - из приложения) и падающую напрочь при установке любого другого приложения, на ней основанного. Последнее вообще-то не дефект BDE, а небрежность тех, кто приложения на базе BDE делает, но от этого не легче. И по большому счету это не небрежность, а неумелость. В классическом варианте события развиваются так: вначале делается приложение с BDE, затем в нескольких форумах публикуется истошный вопль: «У меня работает, у юзеров – нет, ПАМАГИТЕ!!!!». Потом делается методами тов. Ляпкина и Тяпкина инсталлятор, затирающий все BDE-шное напрочь, независимо от версии и настроек, записывая свои настройки и файлы просто не обращая внимания на то, что уже есть. В результате, если приложений с BDE больше 1-го, то работает только установленное последним. Если работает .

Второй ответ: ODBC. Неплохое решение, но только на первый взгляд неплохое. Работа через ODBC – работа SQL-запросами. Да к тому же вызовы ODBC API не очень просто пишутся. Параметров много и разных, а когда я по-простецки выдрал документацию по ODBC из MDAC 2.8 SDK, то Вордовый документ потянул на почти 200 страниц. Собственно поэтому и пользуются успехом всяческие врапперы (обертки) для ODBC, получающие гордые имена типа Direct Oracle Access, Direct InterBase Access и т.п. А потому ODBC лучше оставить любителям острых ощущений. Тем более что либо придется делать кучу всего ручками (прямые вызовы ODBC API), либо эта технология будет фундаментом для чего-то более удобного, но в свою очередь съедающего мегабайты памяти и мегагерцы процессора.

Третий ответ: «что нам стоит дом построить? Нарисуем, будем жить». Структура dbf-файла проста как гвоздь, потратив 1-3 дня,  можно нацарапать нечто, что вполне будет способно читать dbf-ки (и даже писать в них). Я в свое время этим переболел. Нацарапал. И оно даже работало. НО! При малейшей неправильности в dbf-файле (типа в цифровое поле «вышними силами» вбиты буквы и т.п.) мое детище впадало в ступор, а отлавливать такие ошибки далеко не самое интересное занятие. Об индексных файлах я лучше промолчу… Короче, не стоит изобретать очередной велосипед, у которого колеса вряд ли будут круглыми и одинакового размера.

Четвертый ответ: ADO. Хорошо развитая технология, работает чуть ли не со всем подряд, никаких особых настроек вроде бы и не надо делать. Однако и тут есть «маленькие» подвохи, налетев на которые будет не до шуток. 
Подвох первый: более-менее прилично в Delphi можно работать с ADO версии не ниже 2.6, а это – Windows 2000  и позднее. Для остальных нужно устанавливать пакет MDAC, который весит от 5 Мб и выше. Да и для Delphi 5, где впервые появилась эта вкладка, надо апдейты поставить, иначе работать не будет.
Подвох второй: ADO с dbf работает через ODBC, а это технология SQL. Поэтому, если в dbf-таблице отсутствует первичный ключ, уникальный для этой таблицы, то вам гарантирована масса острых ощущений типа «не удается найти строку для обновления», а потому получите большую дулю вместо записи данных и т.п. Выражаясь «по-умному», требуется выполнения правил 1 нормальной формы (1НФ) для любой таблицы, с которой работаем. Но ладно бы только это. 
Еще один подвох в том, что с любой таблицей ADO работает через SQL-запросы. А это означает, что если, допустим, понадобилось в чисто dbf-ном стиле пройтись с начала до конца таблицы размером, например около 200 Кб, около 300 записей, и установить какое-то поле в true (или false), то это займет около 500 mS, а если поиграть с настройками ADO в «нужную» сторону - больше 10 секунд (на Celeron-2000) (чесслово, не поверил бы, если бы не сам мерял)! Поскольку для каждой записи ADO+ODBC состряпают SQL-запрос примерного вида
Update table1
Set MyField = true where id = N000
Где N000 – для каждой записи свой, на формирование, проверку запроса и его выполнение нужно время и т.д. и т.п. Удручающая картина, не правда ли? В то же время, если орудовать в стиле SQL, т.е. потребовать – «чтобы у всех записей в таблице table1 поле MyField было true», т.е.
Update table1
Set MyField = true where true
 то это сработает за сотые доли секунды на той же таблице (30-70 mS). Для сравнения: Halcyon 6.9.6 на той же таблице отрабатывал за примерно 60-80 mS, т.е. фактически то же время (что это за зверь – см. ниже). Вывод: ADO – не для dbf. Это для SQL-серверов. Причем не для всех. 

Hint1: если кто-то не понимает, что означают буквы SQL – топайте на vingrad.ru, например, в раздел «литература» и читайте Грабера (Грубера) «Понимание SQL».

Hint2: можно конечно придраться: «А почему это ADO+ODBC, а не ADO+MS Jet?» Конечно можно и так, только скорость работы от этого изменится ненамного, причем неизвестно в какую сторону . Тормоза будут того же духа, только немного другой конструкции.

Пятый ответ: dbExpress + dbxADO, dbxODBC, dbxMSSQL (дополнения к dbExpress от Timur Islamov для работы с ADO/ODBC/MSSQL – Diamond Access). Для локальной работы интересны только dbxODBC/dbxADO. Недостатки – те же что у ADO/ODBC. dbExpress – дополнительный (и ненужный) слой драйверов.

Шестой ответ: не пожалеть 2-5 Мб Интернет-трафика и сходить на широко известный в узких кругах J сайт www.torry.net (мое любимое место, когда надо соорудить что-нибудь «этакое»; если не готовое решение, то по крайней мере намек, в какую сторону копать, найдется). Тут-то и выяснится, что велосипед оказывается давно изобретен! Не надо морочиться со всякими драйверами, настройками и т.п. Достаточно скачать библиотеку прямого доступа, и все! Причем это касается не только dbf-ок, но и  mdb, xls, db и т.п. - полный список смотрите на сайте. Причем как правило будет еще и выбор: взять нечто маленькое и тупенькое, умеющее только по записям двигаться и их читать/править/добавлять/удалять, или выбрать размером больше, но с поддержкой дополнительных возможностей типа встроенный SQL, импорт/экспорт разных форматов. Кстати, ничего не мешает «скрестить ежа и ужа». Т.е. чем-то простеньким работать с записями, а всяческие SQL-запросы насчет сумм, количества и т.п. делать через ADOQuery. Сработает. Получится полный эквивалент Visual FoxPro(VFP) по функционалу в отдельно взятом приложении. Весящий правда раза в 3-4 меньше его exe-шника с run-time библиотеками. Так что кто любит большие exe-шники – переходите на VFP, а кто крошечные – на С или KOL .

Кроме torry есть еще, например, http://kylecordes.com/bag/ - там можно и прочитать «The BDE Alternatives Guide», и ссылки на кучу компонент доступа найти, разложенные по полочкам и снабженные описаниями.

Db (Paradox)
Пожалуй, единственный случай, когда стоит внимательно посмотреть в сторону BDE. Все-таки «родственный продукт». И даже в этом случае можно легко найти несколько компонент, работающих c его таблицами (и заодно и c кучей других форматов). Например Degisy Data VCL Suite. Т.е шестой ответ не потерял актуальности.

Xls (Excel)
Это то, чем Микро$офт пытается угробить dbf . Способов работать – туча. И через родные Delphi-компоненты (закладка Servers), и просто ручками через OLE, и различной навороченности сторонними компонентами, и через ADO. Среди сторонних есть и такие, которые делают файл Excel без Excel, например. И тут в первую очередь надо задуматься – а что собственно предстоит делать. Лично мне приходилось решать всего 2 варианта задач: 
1.    Экспорт из dbf в xls-таблицу заданного, как говорится, «сверху», образца.
2.    Суммирование данных из нескольких (10-20) xls-файлов с несколькими листами в каждом в один с такими же листами.
Оба варианта я решал по-простому, ручками в OLE. Это не так и трудоемко, особенно если не в лоб идти, а статейки на тему Excel-Delphi почитать. Коротко суть статеек сводится к нескольким рецептам: чтобы все работало быстро, лучше применять раннее связывание, писать лучше не ячейками, а строками, а еще лучше – сразу массивом, книгу Excel лучше держать невидимой. Если непонятно как что-то сделать, то просто записываем макрос, делающий то что надо и его рассматриваем. Крошечное ноу-хау: если есть защищенные от записи ячейки, а отслеживать их не хочется (нудное это дело), то просто оформив запись в виде блока
try 
  {что-то пишем}
except
  {просто пустое место}
end;
от этой нудности с защитой избавляемся. В IDE все ячейки с защитой о себе объявят, а юзер ничего не увидит.

Clarion, VisualBase и прочие национальные меньшинства…
Как правило под практически любой формат находится компонент, который либо с ним работает, либо с ним и еще какими-то. Нужно только внимательно почитать описания или поискать нужное слово на Torry. 

Маленький комментарий из личного опыта: исторически так получилось, что когда Delphi просто не было, а был Паскаль (т.е. в прошлом веке, если примерно), я нашел в swag.ru библиотеку Halcyon. Эта библиотека работала с dbf-ками формата dBase III-IV/FoxPro 2.0-2.6 и поддерживала простые индексы у Лиса и Клиппера. С той поры прошло изрядно времени, но пока (на март 2006 года) меня эта библиотека (версии 6.9.6 на март 2006 года) полностью устраивает. SQL в нем нет, зато весит очень мало. А BDE я вообще не применяю – за ненадобностью. А еще есть Topaz, Apollo, Advantage Database Engine (AdvantageDataset), TDbf… , все не перечислить, список все растет и растет. «Ищите и обрящете» (с) Библия.

Итого:
Для простого случая (локальная/однопользовательская БД) имеет смысл попробовать для требуемого формата БД несколько компонент прямого доступа, которых нет в Delphi, а водятся на Torry и т.п. Что больше понравится – то и применять. И отчетливо осознавать: ни в Borland, ни в Micro$oft ничего более подходящего нет и быть не может, поскольку они предлагают универсальные решения. А это как универсальный (разводной) ключ – если гайки разные, то может быть удобнее иметь его вместо набора просто гаечных ключей, но если известно, что гайки всегда М12, то лучше обзавестись ключом М12, чем регулярно подкручивать съехавший размер у универсального ключа и таскать дополнительную тяжесть его разводного механизма.
Только не забудьте проверить, что ваш инструмент потянет нужный объем данных и не споткнется на чем-либо типа поле Memo/BLOB и т.п., максимальные значение целого, длина строки и т.п.
Дополнительно можно немного подумать о смене формата данных: есть немало разных движков БД, хранящих все данные в одном файле. Иметь резервную копию одного файла проще, чем 50-100, да еще и порой раскиданных по сети. 
Неплохо еще и применить просто здравый смысл: если что-то нужно сделать всего один раз, сопровождения потом не потребуется, то нет смысла тратить время на поиски суперэффективных решений. Проще и быстрее использовать любой уже знакомый инструмент.

Самое главное: любое такое решение – только для локальной и однопользовательской работы. Какую бы шустрость оно ни проявляло, какие бы клятвенные заверения производителя ни были о прекрасной многопользовательской работе, как только дело коснется сетевых приложений (это еще ничего), а тем более многопользовательской работы, надо сразу смотреть по сторонам в поисках альтернативы. Эта альтернатива – сервер. Дойдет очередь и до нее.
 

Хорошая статья! 

SergeBS, Респект! 

Только еще оформить бы красиво, а то все сливается.

iddqd, 
Так оформи. И положи. Я только спасибо скажу. Поскольку в Web-тегах я практически 0.