Под термином xBase-технологии следует понимать те СУБД, которые имели массовое распространение несколько лет назад и являлись преимущественно однопользовательскими, файл-ориентированными системами. Это не только DBF-совместимые системы типа dBase IV, Clipper, FoxPro, но и системы типа Paradox, Clarion и прочие. Последние хотя и отличались технически от первых, но были очень схожи идеологически. Поэтому если где-то в тексте встречается упоминание про xBase, то под ним имеются в виду все вышеупомянутые СУБД.

Принципы работы xBase-систем здесь освещаться не будут, так как они достаточно хорошо известны.

Золотой век xBase-систем.

10 лет назад, когда слово 'хакер' еще не было ругательством, а каждый нормальный программист легко отвечал на вопрос о том, что такое INT21 и для чего надо помещать '20 в двадцатый порт', в среде 'нормальных' программистов считалось что заниматься программированием на Clipper и ему подобных можно только, если сильно нужны деньги или больше нечем заняться.

Что было программирование на xBase-системах? Унылое и скучное 'Учет материальных средств', 'Расчет заработной платы' или еще что-нибудь в этом духе. Это, конечно, приносило деньги, но не приносило морального удовлетворения. 'Настоящий' программист мог восстановить до исходного текста любой бинарный код, будь то библиотека от Си-компилятора или драйверы устройств. Причем бесплатно и ночи напролет. Это приносило большое моральное удовлетворение, но не приносило денег. Может быть, за это и платили деньги, но не в этой стране.

В принципе, xBase-системы справлялись со своими задачами на классической конфигурации тех лет: i286/40 MB HDD /1 MB RAM, но работало это все не торопясь, даже на небольших базах.

С появлением процессоров 386 и 486 xBase-технологии воспряли духом - СУБД зашевелились быстрее. Немного подпортило радостную картину массовое появление локальных сетей, так как заказчики требовали совместной работы АРМов в сети (не всегда давая себе отчет в том, чего же они действительно хотят), а писать сетевые программы толком еще никто не умел. Здесь же появилась первая серьезная проблема совместного использования данных. Недостаток xBase-технологий заключается в том, что все установки и снятие блокировок записей и файлов делаются руками программиста, пишущего программу, и если допущена ошибка, то не избежать больших неприятностей.

Проблемы из-за роста объемов обрабатываемых данных замаячили тоже нескоро. Для этого было необходимо время. А пока все выглядело прекрасно, тем более что большинство проблем вызывалось неисправными индексами, которые благополучно чинились.

Поврежденные файлы с базами данных, т.к. их структура была известна, тоже можно было исправить без особых хлопот.

Одним словом на дворе стоял золотой век xBase.

'А в проклятом буржуинстве:'

Корпоративные СУБД Oracle, IBM DB/2 и прочие существовали уже тогда. Эти системы занимали свой узкий сектор на мэйнфреймах (в крайнем случае минифреймах) и стоили очень дорого. Перенос этих СУБД на PC-платформу, из-за ее слабосильности, не предусматривался.

Кроме того, эти системы не были рассчитаны на программиста-любителя и идеи, заложенные в них, иногда требовали принципиально другого подхода и способа мышления, вдумчивого чтения документации, отказа от некоторых традиционных подходов. Шапкозакидательскими методами, как это предлагают большинство изданий типа 'Изучение ::.. за 21 день' такие системы не берутся.

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

Были трудности и другого плана, например, разработка приложений на Oracle радикально отличалась от Clipper, Fox, Paradox и др. ЭТО именно РАЗРАБОТКА, потому что назвать ЭТО ПРОГРАММИРОВАНИЕМ язык не поворачивается. xBase-системы все-таки более или менее похожи на процедурные языки, в отличие от того же Oracle CDE. Распространенное мнение конца 80-х годов было приведено в PC Magazine, Russian Edition. 'Oracle - это система, в которой чувствуется мощность танка, только не знаешь за какой рычаг надо дернуть'.

SQL-технологии еще 'были страшно далеки от народа'. Но будить этих 'спящих декабристов' пока было некому. Потому что слишком дорого :-(.

'Народное техно - грохот серверов:'

Общая ситуация начала меняться когда все более быстрыми темпами начала уменьшаться стоимость мегабайта на жестких дисках и лентах, подешевела память, а Intel выбросил на рынок Pentium. Построение системы управления крупным предприятием на отдельно взятом сервере стоимостью менее $4000 (только железо) при помощи более эффективных технологий стало, наконец, по карману для более широкого круга заказчиков.

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

Вряд ли стоило ожидать в таких условиях массового исхода из-под xBase-совместимых СУБД.

'Моя твоя не понимай ' или 'оПХБЕР-гДПЮБЯРБСИ'

Есть, по крайней мере, одна проблема, которой нет у американского программиста: он не знает, что такое двуязычная раскладка клавиатуры и почему getty должен непременно пропускать 8 бит.

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

Русские кодовые страницы - это отдельная история. По части кодировок России 'повезло'.

Немногочисленный русскоязычный мир Unix стойко держался за KOИ8, имевшую несколько вариаций, так как это была единственная кодировка, которая сохраняла у писем читабельность при прохождении через корявые американские почтовые гейты, которые полагали, что почта может быть только 7-битной.

PC-платформа во всю использовала кодировку 866, кроме того, коммерческий гений БГ изобрел Windows, вместе с которой появилась кодировка 1251.

Фирма IBM также посчитала необходимым выказать добрый жест и разработала для славян в лице России кодировку 855, которая, кстати, называлась не Russian, а Cyrillic. Честно говоря, кроме Oracle, она нигде и не попадалась. Чем руководствовалась корпорация Oracle при выборе этой кодировки в качестве базовой для русского языка- не известно, скорее всего тем, что русские пишут кириллицей J . Хотя на экране скорее мефодьица какая-то.

Альтернативные платформы типа Apple использовали свой вариант русской кодировки. Местами еще поскрипывало жесткими дисками наследство от братьев по СЭВ в виде 'Правцов' и 'Роботронов', которые также использовали свое видение русского языка, но к счастью их парк был относительно невелик.

Международная организация по стандартизации ISO, естественно, остаться в стороне тоже не могла. С ее помощью на свет появилась ISO 8859-5, которая была предназначена в качестве окончательного решения проблемы русского языка на компьютерной платформе. В отношении последней стоит сказать, что она наиболее хорошо приспособлена для сортировок, буквы русского языка в ней идут подряд и без разрывов, но так как стандарту де-юре сложно изжить стандарты де-факто, то она была встречена компьютерным сообществом достаточно прохладно. Хотя теперь она встречается достаточно часто на Unix-платформах, иногда ее обозначают как Russian Unix.

Справедливости ради стоит упомянуть еще и Unicode - универсальную систему кодирования символов.

Обычный пользователь от этой проблемы далек и натыкается на нее, если в теле приходящего к нему по Интернет письма содержится абракадабра (см. заголовок). А вот для программистов СУБД - это проблема, особенно если в сети используются клиенты на разных платформах.

'Даешь внедреж!'.

Но настоящий прорыв в СУБД уровня предприятия произошел все-таки после того, как на сцену вышла Windows NT. Эта ОС замышлялась как вытесняющая Unix платформа, ориентированная на рынок корпоративных приложений. И хотя NT не сумела серьезно пододвинуть Unix ( удар скорее пришелся по Novell) и лишь оттенила его достоинства, тем не менее, своим появлением она вызвала определенное брожение в среде производителей Unix-систем.

Когда на горизонте замаячила алчущая денег тень БГ, изготовители Unix наконец-то начали задумываться о том, что годами складывавшийся стереотип 'Unix - система для избранных' себя изжил и его дальнейшее существование угрожает обернуться существенным снижением прибыли. Из этого следовало, что системы должны делаться не только для высококвалифицированных программистов, но и в том числе для обычных пользователей. К Unix-системам начали приделываться интерфейсы администраторов, управляемые при помощи меню. В некоторых системах появилась эмуляция DOS и поддержка Win32, а в последствии и Windows95-98. Unix стал ближе и понятнее народу. В конечном счете, это все шло на благо конечному пользователю, которому надо было решать повседневные задачи, а не вникать в очередные стратегические направления развития информационных технологий.

Опуская достоинства и недостатки Windows NT, следует заметить, что пара Windows NT + MS SQL Server имела внешний вид 'настоящего SQL-сервера', интеграцию через ODBC с другими средствами Microsoft, и что важно - низкую цену.

Microsoft, исповедуя политику 'что не съем - так покусаю', так торопился забить место в секторе корпоративных СУБД, что не стал разрабатывать сервер самостоятельно, а купил у Sybase уже готовый и адаптировал его к NT. Волей-неволей, но остальным производителям SQL-серверов, для сохранения стоимостной привлекательности также приходилось снижать цену на свои системы. И это было хорошо!

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

Не так давно Microsoft проводил сравнительное тестирование NT и Linux. Windows NT, конечно же, победила. Но, как кто-то пошутил в RU.LINUX: 'Если тараканы забегали, то это значит, что дихлофос подействовал'.

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

Возвращаясь к теме СУБД, следует сказать, что многие производители СУБД выпустили серверы для Linux, и хотя они несколько ограничены в функциональности, как платформа для оценки возможностей SQL-серверов или разработки компактных систем они весьма пригодны. Ограничение в функциональности иногда связано с возможностями Linux, например, Linux не поддерживает raw devices , соответственно СУБД не могут работать самостоятельно с 'сырыми' разделами. Или такое ограничение является волей фирмы-производителя СУБД - зачем в условно-бесплатный релиз закладывать то же самое, что и в коммерческий релиз, в особенности если последний стоит большие $$$?

Из SQL СУБД на Linux существуют версии Oracle, Informix (как SE так и DS), IBM DB/2, InterBase, Sybase. Эти системы распространяются на разных условиях, но как правило они бесплатны либо для разработки, либо для некоммерческого использования. Informix Dynamic Server, например, продается по чисто символической цене $99. IBM DB2 Developer Edition является бесплатной для разработчиков. Oracle, традиционно распространяющий свои версии в виде триальных систем, выпустил под Linux свой Oracle8 Enterprise Edition.

Есть еще некоммерческие системы типа Postgres SQL (поставляется вместе с Linux) и mySQL. С Postgres мне не доводилось работать, поэтому мне сложно о ней что-либо сказать.

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

Под Linux есть даже Clipper! Только называется он теперь Flagship, и разрабатывался он не CA, а немецкой фирмой Multisoft Datentechnik Gmbh. Как и на любую Unix-систему на него можно ходить терминалами. Лицензия для оценки возможностей на две сессии - бесплатна. Переделки кода с Clipper для DOS - минимальны, немцы утверждают, что он полностью совместим по коду с версией 5.0. Есть даже DBU, с идентичным интерфейсом, рапортующая 'Exit to Unix?' при выходе, вместо привычного 'Exit to DOS?' J . Кстати немцы утверждают, что он существует под 50(sic!) различных платформ. Но если рассматривать Flagship в качестве корпоративной СУБД, то это все-таки полумера: и отнюдь не бесплатная для использования в организации. Хотя, если есть желающие, то Flagship им в руки. 'А мы пойдем другим путем'.

SQL-технологии. Что они могут и как они это делают.

Взаимодействие клиента с сервером.

Язык

Общение с сервером СУБД происходит на языке структурированных запросов SQL (Structured Query Language). Базовый набор языка стандартизован ANSI. Действующая редакция ANSI SQL92. Это непроцедурный язык. Он предназначен именно для построения запросов и манипуляции данными и структурами данных. У него нет ни переменных, ни меток, ни циклов, ни всего прочего, с чем привык работать нормальный программист. Надо четко представлять себе, что SQL оговаривает способ передачи данных в клиентскую программу, но никак не оговаривает то, как эти данные должны в клиентской программе обрабатываться и представляться пользователю.

Естественно, что базовый стандарт не может предусмотреть все потребности пользователей, поэтому многие фирмы производители СУБД предлагают свои собственные и часто непереносимые расширения SQL. Например, Oracle и IBM имеют собственные расширения оператора SELECT, которое позволяет эффективно разворачивать в горизонтальное дерево иерархически упорядоченные данные (В Oracle это START WITH / CONNECT BY). В SQL-диалекте Informix такого оператора нет, поэтому для этих целей приходиться писать сохраненные процедуры. Количество расширений может исчисляться десятками для сервера СУБД от одной фирмы. Впрочем, никто и не говорил, что это будет просто:

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