6.6. Работа с базами данных

Когда KOL задумывался, я и не помышлял о том, что когда-либо маленькая программа, сделанная с помощью этой библиотеки, сможет работать с базами данных. Обычно минимальное приложение Delphi, использовавшее движок BDE для общения с базами данных, начинало отсчитывать свой размер с 600К. Для того, чтобы соединиться с сервером, выполнить несложную работу, требовалось подключить к приложению громадные по своим масштабам модули, внутреннее содержимое которых оставалось Великой и Непостижимой для простых смертных Тайной. Самым главным секретом для меня и сейчас остается: что же там такого еще делается по сравнению с движками, сделанными для KOL, что программы получаются такие разбухшие.

6.6.1. KOLEDB

Первый «настоящий» движок для работы с БД я решил сделать через интерфейс OLE DB. Основным (и практически единственным) источником, повернувшим меня на этот путь, была документация фирмы Microsoft, а именно MSDN. Исходя из прочитанного там, я решил, что это наиболее прогрессивный из всех интерфейсов. Именно он используется современной системой ADO как нижележащий уровень для связи с БД.

Для того, чтобы по возможности сохранить размер приложения достаточно небольшим, я решил кое-чем пожертвовать. А именно: параметрами в SQL-запросах. В действительности, использование параметров не является строго обязательным, то есть без них прекрасно можно обойтись. Боле того, с некоторых пор я ими вообще перестал пользоваться. Главная причина, почему я с ними не подружился, заключается в неудобстве отладки SQL-запросов, содержащих такие параметры. Если запрос не имеет параметров, и все значения вставлены в виде строковых значений, то запрос может быть без изменений скопирован в тот же Query Analyzer, и запущен для тестирования в автономном режиме (в смысле, отдельно от приложения). Для сравнения, попробуйте сделать то же самое с запросом, содержащим более десятка параметров.

Примечание: для того, чтобы скопировать запрос, составленный динамически в коде приложения как результат конкатенации нескольких (или многих) строк, можно использовать несколько методов. Например, непосредственно перед выполнением запроса, когда он уже сформирован, его текст можно сохранить в отладочном текстовом файле.

Пакет KOLEDB содержит достаточный минимум средств, нужных для того, чтобы соединиться с сервером базы данных, и начать с ним работу (объекты TDataSource, TSession). На этом этапе наибольшую сложность представляет формирование строки соединения: для каждого сервера нужна своя строка, со своим собственным набором параметров. И даже синтаксис для различных серверов может существенно отличаться. Но приложение обычно разрабатывается в расчете на какой-то один тип сервера, так что трудность эту приходится преодолевать только один раз.

Объект TSession позволяет организовывать транзакции, и является «родительским» для всех создаваемых объектов SQL-запросов TQuery.

Основной рабочей лошадкой пакета является TQuery. Он позволяет выполнять SQL-запросы, получать результаты, и может работать практически со всеми основными типами данных. Во избежание использования громоздких и медлительных вариантных типов данных, свойства для доступа к полям данным разделены по типам. Например, для обращения к строковым полям следует использовать свойства SField[ idx ] и SFieldByName[ ‘name’ ], для целочисленных – IField и IFieldByName, и так далее. Это не означает, однако, что к значению числового поля можно обратиться только через свойство, имя которого начинается с соответствующей его типу букве. Допускается обращение через свойство SField: поле в этом случае будет автоматически конвертировано в строку, при наличии такой возможности.

Практически, не реализованными для KOLEDB (из действительно полезных возможностей) остались доступ к BLOB-полям. Думаю, что когда этот модуль понадобится кому-нибудь для серьезной работы, то у этого программиста не возникнет слишком больших проблем доработать его до нужной функциональности.

6.6.2. KOLODBC

Другой не менее (или даже более) развитый интерфейс для связи с базой данных был выполнен мною совсем недавно, в конце 2005 года. На этот раз мне понадобилось связываться с базой данных через ODBC-драйвер, минуя ADO – таково было требование заказчика. Проект разрабатывался для VCL, соответственно, первая версия была выполнена именно для VCL. Вот тогда-то, поразившись неожиданной простоте полученного кода, я потратил еще пару дней на то, чтобы сделать этот интерфейс доступным так же и для KOL-программистов. Достаточно определить в опциях проекта символ условной компиляции, и классы становятся простыми объектными типами.

Так же, как и для OLE DB, в данном интерфейсе нет поддержки параметров, и это существенно упростило код. Объект TODBCDatabase служит одновременно и для соединения с базой данных, и для управления транзакциями (нет отдельного объекта для управления сессиями). Объект TODBCQuery является основной рабочей лошадкой, и может работать практически со всеми типами данных при получении полей результата.

Особенностью данного интерфейса является наличие метода More, который позволяет без затруднений получать несколько результатов за один запрос. Иногда эта особенность оказывается очень полезной в плане повышения эффективности запросов. Вообще, соединение напрямую через ODBC-драйвера, минуя прочих посредников, вроде ADO, повышает эффективность работы, и иногда довольно существенно.

6.6.3. KOLIB

Данный интерфейс разработан специально для работы с Interbase. Автор пакета:  Михайличенко Евгений a.k.a. ECM . Собственно, больше мне об этом интерфейсе ничего данный момент неизвестно. (Попробую узнать, тогда допишу).

6.6.4. KOLSQLite

Компонент для работы с БД SQLite, автор Богуслав Брандыс (Польша).