Технологии СУБД

(материал не встречается в журнале и является эксклюзивным.
Автор - Алексей Лукин, Иркутск)

SQL. С самого начала.

“Мы говорим 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 очень перспективная система, и будущее наверняка преподнесет много приятных сюрпризов сторонникам его использования. Один из самых последних заключается в том, что Sun выкупила права на использование StarOffice (конкурент Microsoft Office), и пообещало не только сделать его бесплатным, но и предоставить в бесплатное пользование его исходные тексты. Большой камень в огород Microsoft, однако (статься писалась в сентябре 1999 – прим.авт.) .

Возвращаясь к теме СУБД, следует сказать, что многие производители СУБД выпустили серверы для 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 поддерживает курсоры с произвольным позиционированием.

 

Способы взаимодействия с сервером

Взаимодействие с сервером СУБД с рабочего места пользователя может строиться различными способами:

Терминал-сервер.

Эти технологии существуют со времен первых вычислительных машин. Вся обработка информации сосредоточена на сервере. Терминал выполняет только функции отображения. К безусловным достоинствам следует отнести низкую суммарную стоимость владения (TCO – Total Cost Of Ownership) рабочих мест. Она обеспечивается собственно невысокой стоимостью терминалов, их высокой надежностью, т.к. там практически нечему ломаться и простотой в обращении. Экономия особенно заметна на больших количествах рабочих мест.

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

Стоимость хорошего алфавитно-цифрового терминала зарубежного производства колеблется в пределах $300-$500. Не забудьте про терминальный сервер ($1500-$3000) или про терминальный контроллер ($300-$1000). Это недорого, но есть еще более дешевые решения.

У многих организаций скопилось большое количество исправной, но морально устаревшей техники на базе 386 и 486 процессоров. Вместе с тем она могла бы еще послужить. Существуют эмуляторы терминалов, которые на базе такой устаревшей PC (даже с 286 процессором) обеспечивают нормальное рабочее место, более чем достаточное для работы с приложением Oracle или Informix. Стоимость такого рабочего места может составлять 150-200 долларов (из которых $10-15 стоит дешевая сетевая карта на 10 Мбит). А теперь сосчитайте экономию на парке, например, в 50 машин с PII.

Для Oracle7.3 больше всего подошел эмулятор ANSI-терминала ANSIW95, а под Informix лучше всего работает TELNEAT (после некоторой подкрутки).

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

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

 

Клиент–сервер.

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

Архитектура “клиент-сервер” при большом объеме манипуляций с данными требует высокоскоростных каналов, и решения на этой основе становятся дорогими при разнесении рабочего места и сервера уже на 1-2 км.

Кроме того, при идентичном количестве рабочих мест архитектура “клиент-сервер”, по сравнению с “терминал-сервер” требует большего штата отделов информационно-технического сопровождения, либо большего времени на решение пользовательских проблем.

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

В случае с клиент-серверной архитектурой все менее очевидно. Пример из жизни - вам звонит пользователь и радует вас тем, что у него драйвер ODBC выдает что-то вроде “System Error 0x8098A999EC”? При этом пользователь клянется и божится, что он ничего не трогал и не менял. Самое интересное в том, что он, скорее всего, говорит правду. А если пользователей в системе несколько десятков человек? А если несколько сотен?

 

Толстый и тонкий.

Один из законов философии гласит: “Все развивается по спирали”. Клиенты СУБД не исключение. С началом развертывания массовой кампании по переходу на “клиент-сервер” несколько лет назад, клиентская часть для сервера стараниями фирм- производителей распухла так, что иногда по размерам была сопоставима с собственно сервером. Сообразно размерам она и работала – медленно и печально.

В чью светлую голову пришла идея использовать Internet-технологии для построения интерфейса к СУБД, уже, наверное, не узнает никто. Хотя все гениальное – просто. Посудите сами: существует язык, который позволяет более или менее однозначно описать, что надо пользователю показать на экране (HTML, если кто еще не догадался J ), есть средства для этого, типа Netscape Communicator, MSIE и проч.,при помощи которых можно отрисовать вожделенные пользователю окна, меню и многое другое используя вышеупомянутый HTML. И что важно – эти средства есть практически на каждом компьютере. Грех не воспользоваться! А уж приделать к Web-серверу транслятор запросов к серверу СУБД, как поступил Informix (Informix Universal WebConnect), или включить http-сервер непосредственно в дистрибутив сервера СУБД, как поступил, например, Oracle - это уже дело техники.

Оказалась востребована и Java. Именно она позволяет разрабатывать переносимые программные продукты, а также обеспечивает полноценную логику работы.

Как-то само собой получилось, что компьютерная пресса обозвала тонким клиента на основе браузера, а тяжеловесного клиента (Microsoft Excel или Oracle SQL*Forms для Windows, например) – толстым. Безусловно, тонкий клиент имеет большие перспективы, особенно в отношении организации удаленного доступа.

Строители “междумордий” пытались уйти от алфавитно-цифрового терминала и пришли к терминалу в новом графическом качестве. Вот такая вот прикладная философия.

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

Правда, иногда производители СУБД поступают не совсем честно. Начиная с версии 8 Oracle перестал поддерживать столь любимые мною алфавитно-цифровые интерфейсы (точнее говоря поддерживает, но только по корпоративному соглашению). Только графика и Java, одним словом, загоняют пинками в рай.

 

Организация SQL-сервера.

Физическая структура сервера. OLTP и DSS.

Любой SQL-сервер имеет физическую и логическую структуру. Физическая структура - это метод, с помощью которого SQL-сервер хранит свои данные в ОС. На настоящий момент известно 2 варианта хранения данных. С буферизацией средствами ОС, т.е. сервер СУБД держит свои данные в файлах и без буферизации , когда сервер СУБД работает со своими данными на отдельном разделе диска (raw access), и доступ к которому полностью управляется сервером СУБД.

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

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

Один частный случай. В comp.databases.informix один из компьютерных экспертов, эксплуатировавших Informix на Sun Solaris утверждал, что несмотря на то что в Sun Solaris возможна реализация работы через raw devices, получаемая выгода невелика (прирост производительности составляет около ~20-30%). Это связано с тем, что по его словам, файловая система спроектирована достаточно эффективно. Также, он предупредил, что потенциальные проблемы могут перекрыть получившуюся выгоду, при этом описывалась ситуация, когда из-за ошибки при инсталляции на “сырой” раздел могла уничтожаться таблица разделов жесткого диска.

Raw access применяется для работы с OLTP. OLTP(Online Transaction Processing) - онлайновая обработка транзакций. Это такой способ организации работы СУБД при котором система работает с транзакциями небольшими по размерам, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа.

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

Другой способ организации работы СУБД - DSS (Decision Support System) - системы поддержки принятия решений. Эти системы характеризуются тем, что в них преобладают массированные выборки по большому объему данных в режиме “только чтение”.

К ним относятся, например, программное обеспечение на основе СУБД для финансового анализа, численных методов оценки деловой активности и прочих характеристик за большие периоды времени и обрабатывающие большие (сотни гигабайт) объемы данных.

Есть еще ряд специфичных приложений в которых работают сервера СУБД.

К ним относятся BPS (Batch processing System) – системы пакетной обработки. Принцип очень похож на работу старых компьютеров: есть некоторая очередь заданий, каждое из заданий выполняется с полным доступом к ресурсам и максимальной эффективностью.

Более интересным и современным является использование серверов СУБД в качестве медиасерверов MMS(Multi Media Servers), т.е. сервер используется для предоставления пользователям доступа к аудио и видео информации. Задача сервера СУБД в данном случае – обеспечение непрерывности мультимедиа потока во избежание рывков видео и прерывания звука вплоть до уровня передачи в канал.

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

 

Логическая структура сервера. Составные компоненты.

Логическая структура СУБД - это те объекты СУБД, которыми сервер СУБД непосредственно манипулирует, но не в контексте операционной системы, а контексте базы данных и которые “видны” пользователю (таблицы, представления, индексы, кластеры, сохраненные процедуры и прочие).

Таблица - это основная единица хранения информации в системе. Таблицы в базе данных хранят все пользовательские данные. Кроме того, в системе есть специальные таблицы, к которым в обычных условиях пользователи доступа не имеют или имеют его только на чтение. Это системные таблицы(data dictionary (словарь данных) в терминологии Oracle и SMI (System Management Interface (интерфейс управления системой)) в терминологии Informix), в которых описана логическая структура всей СУБД, в частности, содержатся параметры пользователей, их права доступа, структуры пользовательских таблиц, тексты сохраненных процедур, триггеров и пр.

Данные в таблице хранятся в строках и столбцах. Каждый столбец имеет свое имя и присвоенный столбцу тип данных. Данные в столбце могут быть только одного типа, т.е. если столбец хранит данные типа DATE, то в него нельзя вставить данные типа FLOAT. Строка в таблице, по своей сути сходна с записью данных в файле DBF.

Как правило, СУБД при операциях вставки/модификации данных обеспечивают там, где это возможно, неявное преобразование типов. Т.е. следующие операторы по сути идентичны, хотя во втором случае в столбец типа INTEGER вставляются текстовые данные:

Insert into my_table (column_int)values (911);

и

Insert into my_table (column_int)values (’911’);

С таблицами связаны правила целостности данных (data integrity rules), которые определяются ограничителями (constraint) и триггерами (trigger). О них речь пойдет дальше.

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

Представления часто используются для того, чтобы:

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

Использование представлений зависит от реализации SQL-сервера. В некоторых системах с представлениями можно работать только на чтение.

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

Синонимы - это алиасы для таблицы, представления или программного модуля. Синоним это ссылка на объект. Он используется для того, чтобы скрыть реальное имя объекта или реального пользователя объекта, обеспечения общего доступа к объекту или прозрачности доступа к объектам удаленной базы данных. Краткий пример - пользовательская программа выполняет запрос из некоторой таблицы XYZ. Если у нас в системе есть синоним XYZ, который указывает на самом деле на таблицу ABC в схеме пользователя JUSTAS на сервере rhka.org , то используется именно таблица JUSTAS.ABC, а не какая-то другая. Предположим, администратор решил вынести таблицу ABC в схему пользователя ALEX на другой сервер по имени center.com. Чтобы не переписывать клиентские программы администратор пересоздает синоним XYZ, который теперь указывает на ALEX.ABC@center.com. Клиентские программы в этом случае работают с данными с другого сервера. Понятно, что для успешной работы клиентской программы структура обоих таблиц должна совпадать.

Индексы создаются для ускоренного поиска по таблице. В целом идеология совпадает с идеями использования индексов в DBF-технологиях, за исключением того, что в случае с SQL, сервер целиком управляет индексом при операциях с таблицей (удаление/вставка/модификация) и нет необходимости специально перестраивать или корректировать индексы. Более того, при обработке запроса SQL-сервер сам может выбирать подходящий индекс из доступных для данной таблицы. Например, таблица XYZ содержит столбцы A,B,C,D,E,F,G и имеет 3 индекса по полям A,B,C затем D,E,F и F,G. При запросе select a,b,c from xyz будет задействован первый индекс. При запросе select f,g from xyz будет задействован третий индекс. При запросе select a,g from xyz индексы не будут задействованы вообще (строго говоря, это зависит от реализации), но запрос отработается, хотя и с меньшей скоростью. Последний случай крайне нежелателен в случае, если таблица содержит несколько сотен тысяч строк, в этом случае замедление будет очень заметно. Но обычно запросы, с которыми клиентские программы работают с сервером, известны заранее, поэтому на сервере должен быть создан соответствующий индекс.

Индексирование поддерживается всеми SQL-серверами.

Кластер (cluster). Предположим, что есть группа независимых таблиц, между которыми есть некоторая логическая связь. Например, одна таблица содержит характеристики клиентов, вторая содержит описания заказов этих клиентов , Наличие этой связи приводит к тому, что вероятность одновременного запроса данных из нескольких таблиц этой группы весьма велика. В случае если таблицы большие по размерам, то при отдельном их хранении на диске, суммарное время запроса также будет большим. Чтобы этого избежать применяется связка таблиц в кластеры. В кластере строки из разных таблиц чередуются. Такое хранение приводит к тому, что суммарное время запроса по нескольким таблицам существенно уменьшается. Для дальнейшего увеличения скорости запросов может использоваться индексирование или хеширование кластера. Использование кластеров зависит от реализации SQL-сервера. Они поддерживаются как Oracle7, так и Infromix DS. Практически кластеры используются редко, это связано с рядом ограничений.

Последовательность (sequence). Этот объект СУБД специфичен для Oracle. Последовательности представляют собой специальные объекты базы данных для генерации последовательных значений. Каждое следующее обращение к последовательности увеличивает ее текущее значение на шаг, определяемый при создании последовательности. Использование последовательностей зависит от реализации SQL-сервера. В Infromix DS последовательностей нет. Там используется специальный тип данных SERIAL, который при последовательной вставке в таблицу генерирует только целочисленные значения с шагом 1.

 

Правила целостности данных

Главная особенность SQL-технологий наличие у сервера СУБД специальных средств контроля целостности данных, не зависящих от клиентских программ и привязанных непосредственно к таблицам. Т.е. принципиально не важно, каким образом осуществляется доступ к базе данных: через SQL-консоль, через ODBC-драйвера из приложения Windows, через WWW-connector из Internet-браузера или через DBI-интерфейс Perl. В любом из этих случаев, за контролем целостности данных следит сервер, и при нарушении правил целостности данных сервер известит клиента об ошибке.

К структурам контроля целостности данных относятся ограничители (constraint), которые привязаны к столбцам и триггеры (trigger), которые могут быть привязаны как к столбцам, так и к строкам в таблице.

Ограничители это элементарные проверки или условия, которые выполняются для операций вставки и модификации значения столбца. Если данная проверка не проходит или условие не выполняется, то вставка или модификация отменяется, а в программу клиента передается ошибка.

SQL-серверы, как правило, поддерживают следующие ограничители.

NOT NULL – проверка на непустое значение. NULL – специальное понятие в СУБД, которое означает “пусто”. “Пусто” и “0(ноль)” не равны друг другу!

UNIQUE – проверка на уникальность. Вставляемое значение должно быть уникально для данного столбца по всей таблице. Может содержать пустые значения.

PRIMARY KEY – первичный ключ. Значение в столбце считается первичным ключом, если оно непустое и уникально в пределах столбца данной таблицы. Первичный ключ может быть составным и представлять собой комбинацию столбцов. Тогда чтобы считаться первичным ключом, каждое из группы значений не должно быть пустыми и формируемые строки значений первичного ключа должны быть уникальны в пределах таблицы. Первичный ключ - основа для построения индексов по таблице.

SQL-технология позволяет на уровне столбца задавать домены значений, т.е. строго определенные наборы или диапазоны значений, для помещаемых в столбец данных.

В частности можно реализовывать ограничения ссылочной целостности (referential integrity constraint) и проверки фиксированного условия.

Ограничение ссылочной целостности не позволяет значениям из столбца одной таблицы принимать значения кроме как из присутствующих в столбце другой таблицы. Это делается при помощи ограничителей FOREIGN KEY (внешний ключ) и REFERENCES (указатель ссылки).

Таблица, содержащая FOREIGN KEY, считается родительской таблицей. Таблица, содержащая REFERENCES, считается дочерней таблицей. Внешний ключ и указатель ссылки могут находиться в одной таблице, т.е. родительская таблица одновременно является дочерней.

FOREIGN KEY – внешний ключ. Назначает столбец или комбинацию столбцов в текущей (родительской) таблице в качестве внешнего ключа для ссылки из других таблиц.

REFERENCES - указатель ссылки (или родительский ключ). Указывает на столбец (комбинацию столбцов) в родительской таблице, ограничивающую значения в текущей (дочерней) таблице.

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

Ограничения ссылочной целостности используются при каскадном удалении, т.е. при удалении записи в родительской таблице удаляются все записи с указанным ключом из дочерних таблиц, и наоборот при запрете удаления/модификации, т.е. при наличии зависимых записей в дочерних таблицах, значение ключа записи в родительской таблице нельзя удалить или модифицировать.

CHECK - проверка фиксированного условия. В данном ограничителе явно указывается условие, которое должно выполняться для вставляемого или модифицируемого значения в столбце.

Например: check (user in ‘ALEX’,’JUSTAS’) - в столбце user могут содержаться только значения ‘ALEX’ и ‘JUSTAS’, попытка вставки значения ‘SHTIRLITZ’ будет интерпретирована как ошибочная , check (user_salary between 1000 and 5000) - столбец user_salary может принимать целочисленные значения в диапазоне от 1000 до 5000 и т.д. При формировании условий с некоторыми ограничениями могут использоваться функции, например check (user = upper(user)), в данном случае имя пользователя должно вводиться только в верхнем регистре. Есть и ограничения, например, CHECK не может содержать подзапросы (SELECT).

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

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

Некоторые типовые применения триггеров:

• Прозрачный аудит (не зависящий от клиентских программ и невидимый для них) и регистрация событий, связанных с доступом к определенным таблицам или столбцам в таблицах.
• Генерация значений в столбцах на основе значений в других столбцах при вставке/модификации строки данных.
• Манипуляции над зависимыми таблицами в особенности, если они находятся на других узлах распределенной базы данных, чего нельзя сделать при помощи ограничителей.

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

Понятие триггера как выполнение кода по событию в том же Oracle используется весьма широко. В частности, оно является основным при разработке клиентских программ при помощи SQL*Forms.

Триггеры пишутся на процедурных расширениях SQL.

 

Обработка данных в многопользовательской СУБД.

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

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

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

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

Контроль нужен также в системах резервирования билетов на транспорте, чтобы билет на одно и то же место не был продан разными кассирами разным пассажирам.

Несмотря на различия в реализации, серверы СУБД используют общие способы управления данными и доступом к ним.

 

Атомарность SQL-выражений при работе с данными.

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

Этот набор данных для текущего выполняемого выражения не может быть изменен другим пользователем или даже другой сессией этого же пользователя, которая пытается выполнить операцию модификации этих же данных в этой же таблице.

 

Распараллеливание операций.

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

 

Обеспечение максимальной производительности.

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

Строго говоря, эта информация справедлива лишь в отношении Oracle, но другие СУБД используют подобные принципы.

• Процессы, выполняющие чтение блоков данных, никогда не ожидают процессов, выполняющих запись тех же блоков данных.
• Процессы, выполняющие запись блоков данных, при отсутствии явных блокировок со стороны пользователя, не ожидают процессов, выполняющих чтение тех же блоков данных.
• Процессы, выполняющие запись блоков данных, ожидают другие процессы, выполняющие запись, только в случае если они пытаются выполнить запись данных в одни и те же блоки данных.

Данные приемы позволяют существенно уменьшить время ожидания ответа системы и увеличить ее производительность.

 

Транзакции

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

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

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

Если происходит явное сохранение изменений в системе (по команде COMMIT) или неявное сохранение изменений (по завершению группы SQL-выражений, формирующих транзакцию или по завершению сеанса пользователя), то все изменения произошедшие с момента начала транзакции вносятся в систему, и информация о данной транзакции удаляется из журнала.

Для облегчения управления системой в режиме регистрации транзакций существует возможность задания так называемых промежуточных точек сохранения. Промежуточная точка сохранения по команде SAVEPOINT <имя_точки_останова> явно помечает состояние системы и предоставляет возможность восстановления состояния БД на момент ее сохранения по команде ROLLBACK. В данном случае ROLLBACK <имя_точки_останова> откатывает систему к указанной точке. Обычно промежуточных точек сохранения для одного пользователя может быть несколько.

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

Данная схема справедлива для Oracle, где транзакция начинается с выполнением первого оператора, прочие сервера могут работать по-другому. Например в Informix DS, транзакция начинается явно, при помощи команды BEGIN WORK.

В SQL-бочке меда есть своя ложка дегтя. Для всех SQL-серверов использующих журнальный режим регистрации транзакций существует проблема, так называемых “длинных” транзакций. Это транзакции, которые затрагивают очень большой объем данных (сопоставимый с количеством свободного места на дисках) и в этом случае журналы регистрации транзакций могут переполниться. Если их рост ничем неограничен, то они могут израсходовать у ОС всю доступную дисковую память, что не есть хорошо, т.к. операционная система и сервер СУБД в этом случае остаются в непредсказуемом состоянии. Если их рост ограничен, то при переполнении журналов СУБД выдает соответствующую ошибку и операция откатывается. Чтобы избежать таких ситуаций программист должен разделить длинную транзакцию на короткие транзакции.

 

Блокировки.

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

Блокировки связаны с транзакциями. Если выполняется отмена транзакции, то снимаются все связанные с этой транзакцией блокировки.

Многие блокировки выполняются неявно для пользователя, они выставляются, например, операторами UPDATE, INSERT. Существуют явные операторы задания блокировок, например, LOCK TABLE или операторы, имеющие клаузы блокировки, например SELECT … FOR UPDATE. Соответственно есть операторы и для снятия блокировок.

Многие SQL-серверы имеют специальные способы обнаружения и предотвращения взаимных блокировок (deadlocks), которые могут занимать ресурсы СУБД на неопределенное время.

Способы, которыми обеспечиваются блокировки, зависят от реализации сервера, и описываются в его документации. Виды блокировок также зависят от используемого сервера. В Informix существуют, т.н. promotional locks, это означает, что если клиентский процесс не может блокировать в исключительном режиме ресурс, то такая блокировка ставится в очередь и ей предоставляется ресурс после снятия текущей исключительной блокировки другого процесса. Oracle7 так не делает, если он не может установить исключительную блокировку в течение указанного сервером времени, то клиент извещается об ошибке.

 

Политика безопасности

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

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

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

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

Правда, необходимо иметь в виду такое свойство паролей Oracle, как возможность их задания в командной строке для всех утилит и компонент, которые работают с СУБД. Это иногда применяется для облегчения доступа к системе, например, при работе в пакетном режиме. К сожалению, в этом случае, пароли пользователей, регистрирующихся непосредственно в Oracle видны в столбце командной строки в таблице процессов, выводимой по команде ps L . Это значит, что остальные пользователи не должны иметь доступа к командной строке системы, в противном случае, безопасность системы будет серьезно нарушена. Еще лучше если в данной ситуации машина будет использоваться только как сервер СУБД и не будет заниматься под другие задачи, связанные с пользовательским доступом.

В Informix DS используется аутентификация только средствами ОС

Чтобы не назначать каждому пользователю большое количество прав доступа к каждой из групп таблиц в системе, формируется некоторый список, в котором все эти права перечисляются. Дальнейшее назначение прав делается при помощи этого списка. Совокупность таких прав доступа к объектам СУБД называются ролью доступа. В Oracle помимо ролей доступа, есть еще и роли приложений (более подробно про них указано в описании Oracle CDE, раздел про SQL*Menu). Функционально эти роли похожи, но роли приложения являются исключительным свойством SQL*Menu. Они не связаны непосредственно с возможностями Oracle и отвечают лишь за доступ пользователя к приложениям.

Ролей приложений в Informix DS как таковых нет L . Для того чтобы создать нечто подобное, каждый раз приходится изобретать велосипед.

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

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

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

Так что работайте и не забывайте, что “Big Brother watches you”.

 

Лицензирование

Informix защищает свои программные продукты при помощи серийного номера и ключа активации. Количество одновременно активных пользователей СУБД зашито в серийный номер. Правда, под Linux лицензия является безразмерной. Хоть это радует.

Лицензионная политика Oracle более интересна - несмотря на лицензирование собственно количества соединений, сами они могут и не ограничиваться сервером. Насколько помню по памяти то замечательное место из документации “... Возьмите Вашу лицензию и установите данный параметр конфигурационного файла в то число пользователей, на которых рассчитана ваша лицензия, если ваша лицензия рассчитана на произвольное количество пользователей, то закомментируйте данный параметр”.

I love it! :-)

Все триальные версии, которые мне попадались работоспособны и после окончания срока триала, тем более выпускает Oracle триалы в большом количестве. Как мне понравилось в SU.DBMS кто-то сказал: “... считается что после окончания срока триала человека начинает страшно мучить совесть...” J

Скорее всего, что именно за счет этого Oracle получил самое большое распространение на территории бывшего СССР, в особенности с учетом нашего способа распространения программного обеспечения. С другой стороны эта ситуация выгодна (как это странно может показаться) и для Oracle.

Допустим программист работал на “черной” или “серой” копии системы A, допустим, что он где-то украл к ней документацию. Систему А он знает и понимает. Настало время “Ч” и возникла необходимость либо в легализации разработок, либо пришла пора “внедрежа” новых технологий в конторе. Догадайтесь с трех раз, какую систему он будет рекомендовать своему руководству для приобретения из систем, представленных на рассмотрение: A, B и C?

У Oracle есть один существенный минус: если сделанную на Oracle систему надо кому-то продавать, то для Oracle Corporation надо выплачивать royalty с каждой проданной копии за его исполняемые модули, необходимые для запуска системы (runtime). Так по крайней мере было раньше. Если сейчас что-то изменилось - не знаю, из других СУБД этим никто вроде бы не страдает.

 

“А как ви телаете руские пуквы, товарисч?”

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

Дальше все просто, при соединении сервер проверяет кодовые страницы у базы данных и клиента, если они совпадают, то нет проблем. Если они отличаются, то сервер проверяет, может ли он осуществить преобразование из одной таблицы в другую, если может (например, из серверной KOI-8 в клиентскую 866), то нет проблем, если это сделать нельзя (например, из KOI-8 в US7ASCII), то в Oracle мы имеем ересь на экране, а Informix рапортует об ошибке и завершает соединение.

Сервер Oracle поддерживает практически все мыслимые русские страницы, включая русскую страницу для Apple Macintosh и странную 855 страницу, так странно любимую Oracle. Настройка русского языка для Oracle на конкретной платформе может потребовать некоторых усилий. В частности мне пришлось потратить некоторое время, прикручивая русские буквы и псевдографику на SCO OpenServer, причем как на самом сервере, так и в CDE. Сервер понимал все кодовые страницы, но CDE нормально пропускал только 8859-5. Вдобавок сам OpenServer двоил большую русскую “А”, но это удалось побороть при помощи mapchan. Также удалось сделать корректный ввод и вывод псевдографики не только на терминальном эмуляторе, но и на системной консоли, для чего пришлось переправить описания терминалов соответственно для консоли и терминального эмулятора в Oracle, а также перестроить определения клавиатуры в OpenServer. А как кодируется псевдографика в Oracle*Terminal – это просто хит!

Зато с поддержкой русского языка в Informix (как для Linux, так и для Solaris x86) не было никаких проблем в принципе. Все стало и заработало с полоборота. У Informix не такое большое разнообразие русских кодовых страниц, но все основные есть: KOI-8, WIN1251, PC866, ISO8859-5. Лучшая для Linux это KOI-8.

Терминальные эмуляторы, которые мне довелось использовать (ANSIW95 и TELNEAT) поддерживают перекодировку из KOI8 в 866 “на лету”.

 

“Ты скажи, чё те надо….”

Oracle 8i EE для Linux желает ни много ни мало 128 MB RAM минимум, хотя рекомендованное типичное значение составляет 256MB RAM. Informix Dynamic Server 7.30.UC7 в этом плане менее прожорлив. Ему достаточно и 64 MB, но следует помнить что по своим возможностям он примерно соответствует Oracle 7.3, а у того потребности в памяти примерно аналогичные.

 

Среда разработчика. А также четверг и 7 пятниц.

Так уж получилось, что мне довелось заниматься в основном СУБД на Unix, и поэтому буду рассматривать только то, что с этой системой связано.

Рассмотрим две отличающиеся идейно среды разработчика: Oracle CDE1 для Unix и Informix RDS для Unix .

 

Oracle Corporative Development Environment (CDE).

Это одно из самых проверенных интегрированных средств разработки корпорации Oracle. Благодаря своим функциональным возможностям находится в использовании до сих пор, хотя и выпущено впервые в 1992 году, в индустрии ПО это практически вечность.

Oracle CDE состоит из нескольких автономных частей. Это SQL*Forms 3.0 для генерации экранных форм, SQL*ReportWriter 1.0 для генерации отчетов для печати на принтере или экране. SQL*Menu, для генерации меню, которое в свою очередь связывает в готовое приложение формы и отчеты. Ну и еще есть SQL*Plus – замечательная SQL-консоль, которая может использоваться и для быстрого построения отчетов. Здесь рассматриваются версии Oracle CDE для Sun Solaris (SPARC) и Oracle CDE для SCO OpenServer, которые с точки зрения разработчика идентичны.

SQL*Forms 3.0.

Будет, наверное, правильно (хотя и очень грубо) сказать, что разработка приложения для ввода/вывода пользовательской информации, сводится к рисованию полей таблицы на экране и их правильной компоновке, т.е. по своей сути SQL*Forms является дизайнером.

Но попрограммировать все же придется. Основа основ разработки под SQL*Forms – это триггеры, т.е. срабатывание сохраненной в БД процедуры по некоторому событию. Только здесь события связаны с формой. Т.е. если пользователь заходит в форму, то при этом срабатывает соответствующий триггер, заходит в поле формы, нажимает на соответствующую функциональную клавишу, выходит из формы – также срабатывают соответствующие триггеры.

Триггеров в SQL*Forms много – на все события, которые могут произойти в форме и практически на все случаи жизни. Схемы их срабатывания описаны в достаточно объемной документации (~400 страниц). Для написания триггеров используется PL/SQL, который должен быть установлен на сервере (Procedural Option).

Примерное построение экранного приложения, которое заносит данные в таблицу, сводится к нескольким шагам.

Указываем таблицу для генерации формы. При этом SQL*Forms самостоятельно пытается разместить на экране поля этой формы. Приводим за ним в порядок экран, т.е. осмысленно называем поля, расставляем их в нужном порядке на экране, рисуем рамочки, выставляем требуемую длину полей. Сохраняем, компилируем. Все! На это ушло минут пятнадцать. В данном примере нет проверок, сложных условий, работа ведется только с одной таблицей, нет блоков “мастер-подчиненный”, нет подсказок, многостраничной работы и вызова подчиненных форм. И тем не менее, в данном приложении мы имеем возможность вставлять данные в таблицу и удалять их оттуда. Кроме того, можно выполнять поиск данных из таблицы по условию в любом поле, редактировать отобранные строки и сохранять их назад в таблицу!

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

Столь же простым является программирование списков выбора (LOV). Сначала пишется SQL-выражение в котором указывается куда будут сохраняться возвращенные значения в виде SELECT … INTO :VAR1, ….:VARn WHERE …, затем указываются координаты окна, название окна и наш список практически готов. Кроме того, в нем еще можно осуществлять поиск по критерию.

Откомпилированная форма представляет собой бинарный файл с псевдокодом, который передается для запуска компоненту runform. В принципе форму можно выгрузить в перемещаемый формат (*.inp), там все хорошо и красиво структурировано, но Oracle категорически не рекомендует прямое редактирование этого файла, т.к. в случае если там будут содержаться неверные команды есть риск повреждения таблиц с формами. Тем не менее, описание перемещаемого формата полностью документировано в SQL*Forms Designer’s Reference.

SQL*Forms очень жестко задает стиль программирования, поэтому все экранные интерфейсы похожи друг на друга. Но это не очень большой недостаток, в конце концов “нам надо шашечки или нам надо ехать?”. Приложения создаются быстро, свою самую первую рабочую форму я получил через три дня, после того как начал осваивать SQL*Forms. Аналогичное по сути приложение я разрабатывал в Informix 4GL в течение месяца.

SQL*Forms поддерживает многостраничную работу, т.е. форма может иметь размеры большие чем физический размер экрана, поддерживается вертикальный и горизонтальный скроллинг (scroll-regions), наслаивающиеся окна (pop-up windows), списки значений (LOV), в которых возможен поиск, и многое другое.

Кстати клавиатурный интерфейс также единообразен, т.к. определяется лишь настройками терминала и контекстом используемых клавиш. Т.е. если известно, что для ANSI-терминала значения по умолчанию клавиш “перейти в режим поиска” и “выполнить поиск” равны соответственно <F11> и <Esc>,<F11>, то это справедливо для любой формы разработанной в SQL*Forms и не зависит от того, кто и когда ее разрабатывал.

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

Раскладка клавиатуры в SQL*Forms радикально отличается от всех прочих приложений и стандартов, но проблемы с клавиатурным интерфейсом есть только у профессиональных пользователей или программистов. Неподготовленному пользователю все равно на что нажимать для выполнения поиска - на <Ctrl+F> или на <F11>.

Также в SQL*Forms есть возможность автоматической генерации документации на создаваемое приложение.

SQL*ReportWriter 1.0

Безбумажные технологии, как это ни парадоксально, не способствуют уменьшению количества бумажных отчетов. Помочь в их создании помогает SQL*ReportWriter. Он позволяет выводить отчет на экран, в файл или на принтер, осуществлять его постраничный просмотр. Как и SQL*Forms, средство для генерации отчетов SQL*ReportWriter работает по типу “программирование без программирования”, т.е. чем меньше кода, тем лучше. Его создавала другая команда программистов, поэтому его интерфейс отличается от SQL*Forms даже для одного типа терминала. Несмотря на свою непривычность, это универсальное средство, которое позволяет создавать отчеты любой сложности.

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

Отчет компилируется в файл с расширением .rep. Откомпилированный отчет также является псевдокодом, который запускается специальным интерпретатором runrep. Такие параметры как ширина строки, длина страницы, могут передаваться внутрь отчета из командной строки, но гораздо чаще для передачи собственно параметров для операторов SELECT, при помощи которых делается выборка данных для отчета, используется таблица приложения.

SQL*ReportWriter умеет выгружать файл в формат независящий от платформы (файлы с расширением .rex), но к сожалению этот файл для человеческого восприятия слабо пригоден, хотя и содержит только ASCII символы.

Интерпретатор отчетов runrep может выполняться непосредственно из формы. Таким образом, из необходимого места приложения, пользователь может сразу запускать отчет.

SQL*Menu 5.0

SQL*Menu является относительно несложным в понимании средством, которое организует первичный пользовательский интерфейс. Оно интегрирует все компоненты системы (отчеты и формы) в единое приложение, которое в конечном итоге выглядит как некоторое главное меню, из которого вызываются элементы приложения – формы, отчеты, скрипты, в случае необходимости – бинарные исполняемые программы. Меню организованы иерархически в виде произвольного дерева и могут быть как вертикальными, так и выпадающими. Каждым элементом меню может быть либо элемент приложения, либо подменю.

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

SQL*Menu компилирует описание меню в файл с расширением .dmm, который запускается специализированным интерпретатором runmenu. Как правило строка, содержащая sqlmenu, является последней командной строкой в профиле Unix для обычного пользователя. Здесь начинается и заканчивается его рабочий день. Обычный пользователь системы, грамотно написанной на Oracle, доступа к командной строке операционной системы не имеет вообще, в связи с чем его не надо обучать системе Unix, и таким образом снимается много проблем, в том числе и безопасности доступа.

SQL*Plus 3.1

Эта замечательная утилита Oracle, которая по своей сути является SQL-консолью, позволяет решать массу задач. Например, управлять данными, структурами данных, создавать простые отчеты (причем с достаточно сложным форматированием), выполнять скрипты (работать в batch-mode), быстро лазить по системе и делать многое другое. Без нее жизнь под Oracle была бы гораздо более скучной и сложной.

Впрочем, это не избавляет от необходимости покупать на SQL*Plus лицензию как на отдельный продукт.

SQL*Plus в повседневных задачах в некоторой степени может заменять часть свойств SQL*DBA (ПО, из которого администратор управляет СУБД) , в частности выполнение операторов манипулирования данными (DML), управления параметрами пользователей и т.д, но, естественно, далеко не все.

Пользовательский интерфейс SQL*Plus – командная строка. И никаких меню!

Oracle*Terminal

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

Достоинства и недостатки Oracle CDE

Отладчик отсутствует как класс. Опция Debug в SQL*Forms позволяет выполнять просмотр порядка срабатывания триггеров. Без отладчика не просто разрабатывать сложные приложения. Все остальное делается при помощи контрольной печати. Это не удобно. На CDE достаточно сложно перейти с процедурных языков, так как его идеи разработки сильно отличаются от традиционных, хотя можно создать работоспособное приложение, не написав ни строки кода.

И тем не менее, Oracle CDE1 – это система с богатыми функциональными возможностями даже для 1999 года, поэтому Oracle 7.3 часто используется для разработки современных проектов, там где требуется высокая надежность, допускается использование терминалов, и на рабочем месте пользователя нет необходимости работать с графикой.

 

Другие средства разработки Oracle

Для Windows 3.1 есть CDE2 (те же Forms, ReportWriter, Menu), для Windows95 есть Developer/2000, кроме того Oracle дает скачивать со своего сервера такое средство разработки как Jdeveloper. Весьма любопытное средство для создания Java-ориентированных проектов. Кроме того, есть предкомпиляторы, которые транслируют SQL-выражения в тексте программы в библиотечные вызовы для различных языков. Существуют Oracle Pro*C, Pro*Pascal, Pro*Ada, Pro*COBOL, Pro*Fortran, Pro*PL/1. Ничем из выше перечисленного мне не приходилось пользоваться, так что не спрашивайте как это работает.

 

Informix SDK

Линия средств разработки Informix не такая четкая, как у Oracle, здесь большое количество продуктов, которые выполняют сходные функции даже для одной платформы. Здесь рассматривается версия 7.20.UD1 для Linux.

Informix RDS.

Informix Rapid Development System (RDS) – это интегрированная среда, которая предназначена для полной разработки программного проекта (программы в терминах Informix). Среда разработчика Informix RDS включает в себя следующие компоненты: Informix 4GL, где пишутся как экранные формы, так и отчеты, отладчик Informix 4GL Interactive Debugger и Informix SQL, который выполняет функции SQL-консоли.

Программа состоит из одного или нескольких программных модулей, написанных на процедурном языке Informix 4GL. Интегрированная система отслеживает зависимости между ними по подобию make и компилирует их в случае обновления.

Informix 4GL

Informix 4GL представляет собой компилятор, который транслирует код. Код транслируется в промежуточный P-код, для версии RDS, который запускается интерпретатором (раннером в терминологии Informix) под названием fglgo. Для версии с компилятором C, исходный код 4GL транслируется в код на ESQL/C, который далее обрабатывается компилятором C и компонуется в монолитный исполняемый бинарный код.

Монолитный код и модульный псевдокод имеют как достоинства, так и недостатки. Модульный код проще сопровождать, особенно если требуется передавать измененные модули на удаленные сайты по медленным каналам связи. Модуль, который в псевдокоде занимает размер в 1,5Кб в исполняемом бинарном коде, при линковке со статическими библиотеками, что дает независимость от установленных системных библиотек, может занимать 1,2Мб. Почувствуйте разницу! Правда, при использовании бинарного кода предпочтительнее использовать компоновку с динамическими исполняемыми библиотеками, что также позволяет экономить место.

Сам 4GL представляет собой процедурный язык, внутри которого допустимо использование SQL-выражений. Создатели языка пошли по пути упрощения компилятора, поэтому Informix 4GL, Informix SQL (транслятор SQL-выражений в сервере СУБД) и SPL – язык сохраненных процедур (Stored Procedures Language) в сервере СУБД имеют отличия в синтаксисе. Мелочь, казалось бы, но иногда раздражает. Существенно отличается набор поддерживаемых функций для 4GL и для Informix SQL, в отличие от Oracle, где набор функций практически идентичен в PL/SQL и Oracle SQL. Для программиста в Informix это представляет определенную проблему.

Надо сказать, что 4GL не блистает богатством функций, коих программисту предлагается весьма ограниченный набор. Все остальное предлагается либо писать самому, либо, если сведущие люди вовремя надоумят, идти на www.iiug.org, сайт International Informix User’s Group, где можно позаимствовать исходные тексты некоторых общеупотребительных функций на 4GL.

Кроме того, не факт, что те функции, которые вы используете сейчас, будут поддерживаться в будущих версиях. Как это было, например, с функциями NVL(), TO_DATE(), TO_CHAR() в версии 7.3x. В версиях 9.x они отсутствовали, правда, в Informix Foundation 2000 их пообещали поддержать.

К примеру, возможность организации вертикального меню (списка выбора) в Oracle SQL*Forms является встроенным свойством и называется оно LOV (List Of Values). Программирование списка значений в Oracle SQL*Forms занимает максимум пару минут. В Informix 4GL отсутствуют встроенные средства поддержки вертикальных меню (заметим, что на дворе, между прочим, 1999 год), а исходный текст, благополучно реализующий это дело, занимает порядка 40Кб. Причем то, что предлагалось на IIUG, меня не устроило и пришлось изобретать свое колесо.

Из меню Informix 4GL может предложить только горизонтальные кольцевые меню (ring menu). Делать большую иерархию на их основе сложно, и уж если при количестве модулей в две сотни начитаешь плутать по более удобной системе Oracle SQL*Menu, то в приложении на Informix заблудишься и подавно. Основной недостаток меню в Informix – низкая информативность. Если для вертикального меню в Oracle можно написать название элементов как: “Расчет норм отпуска по месяцам отбеливателя для тети Аси”, “Возврат остатков отбеливателя от тети Аси”, “Соотношение между количеством старого отбеливателя и размерами дырок в рубашках”, то в Informix это сделать в принципе тоже можно, только ходить по такому меню будет сложно, т.к. в один момент времени на экране будет отображаться максимум один элемент. А вот “Abort, Retry , Ignore” в горизонтальном меню – это пожалуйста.

Хороший источник информации Internet-конференция comp.databases.informix народ там дружный и вежливый, спросите: чем смогут, тем помогут. Правда, при слове Oracle аборигены начинают слегка подергиваться и вибрировать :-).

Informix 4GL Interactive Debugger

Это полноэкранный отладчик для программ на 4GL. Интерфейс сильнее, чем у gdb, но слабее в сравнении с борландовскими отладчиками. Чтобы его освоить, нужны некоторые усилия. В принципе, он поддерживает основные функции нормальных отладчиков. Хотя лично я чаще пользуюсь контрольной печатью J . В отладчике есть перенаправление вывода приложения на другой терминал.

Настройка терминалов.

Терминалы под Informix работают в двух режимах: через системное terminfo или через собственный termcap Informix. Для успешной настройки вашего терминала или терминального эмулятора необходим опыт программирования termcap и понимание принципов его работы, а это не так просто как хотелось бы. Termcap Informix имеет отличия от стандартного termcap. Они частично описаны в документации Informix 4GL Reference. При работе через системное terminfo отсутствует поддержка цвета в приложениях.

Informix-SQL и DBACCESS

Informix-SQL – это дополнительная опция, после установки которой, из среды разработки можно создавать и выполнять SQL-запросы по образу того, как они делаются в Oracle SQL*Plus, хотя и в гораздо менее удобной форме.

DBACCESS – это специальная утилита, которая в основном выполняет административные функции по аналогии с Oracle SQL*DBA. С ее помощью создаются базы данных, таблицы, выполняется просмотр всей связанной с ними информации и многое другое. Достоинством является то, что работа организована через кольцевые меню и достаточна удобна. DBACCESS понимает скрипты, поступающие со стандартного ввода, но не умеет форматировать вывод, что является существенным недостатком, в отличие от Oracle SQL*Plus.

Другие средства разработки Informix.

Большое количество программных средств разработано на ESQL/C. Это предкомпилятор Informix для языка C, он транслирует SQL-выражения в вызовы библиотечных функций. На выходе получается исполняемый бинарный код. У Informix существуют средства разработки под Windows. Подробнее о них в книгах Мошков. “Учебник по СУБД Informix” (электронная версия на www.cit.ru) и Грачев А.Ю. “Введение в СУБД Informix” (электронная версия на www.informix.ua)

Организация меню

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

Отчеты

Программирование отчетов для последующего вывода их в файл экран или принтер также делается при помощи программирования на 4GL.

 

Итого

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

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

В 90% случаев программисту достаточно представлять себе, что он работает с системой один на один, ничего не зная про остальных пользователей. То же касается и пользователей: хорошо спроектированное приложение работает так, что сервер сделает все сам: заблокирует кого надо и откатит кого нужно. В этом большое достоинство SQL-серверов. Хотя для создания действительно эффективных приложений (оставшиеся 10% случаев) надо очень хорошо представлять, как это все внутри работает, а для этого не лениться читать документацию и печатаемые книжки. “RTFM, RTFM и RTFM” -как говорил Ленин В.И.

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

SQL-сервер имеет более низкие требования к каналам передачи данных чем файловый сервер. Для файлового сервера, чем толще канал, тем лучше, поэтому xBase-система работает хорошо до тех пор, пока не потребуется отнести рабочее место хотя бы километров на десять. Это может потребоваться, например, при организации удаленного офиса или точки обслуживания. А без канала связи будут проблемы с репликацией нормативно-справочной информации.

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

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

 

1999-2000. Лукин А.С.

(с) Алексей Лукин, 1999-2000г.
Перепечатка статьи в любом виде без разрешения автора запрещена.