“Мы говорим Clipper – подразумеваем …”

Под термином 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 поддерживает курсоры с произвольным позиционированием.