В чем сходства и различия?

Изначально компании сами созда­вали свои форматы файлов баз дан­ных и свои языки программирования для работы с этими БД. Но прогресс необратимо продвигался вперед, и вскоре пользователи и разработчики стали ощущать потребность в стан­дартизации. Производителям приш­лось сделать свои интерфейсы откры­тыми (типа ADO, BDE, ODBC, JDBC и т.д.). Другими словами, ко всем СУБД мож­но получить доступ по одному и тому же интерфейсу.

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

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

Выбираем бд

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

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

РЕАЛЬНЫЕ ПРОЕКТЫ

Наиболее ярким примером являет­ся популярный проект Open Source -форум phpBB (www.phpBB.com). Мно­гие крупные компании (такие как Fujitsu Siemens Computers, Greenball Corporation) используют в своей ра­боте различные СУБД. Да и любой банк не обойдется без базы данных. Конкретно в нашей стране многие предприятия используют старые СУБД, написанные еще под DOS. При­чина этого - высокая стоимость пере­хода на более современные СУБД плюс лень тамошних администрато­ров и программистов.

РАЗВИТИЕ ТЕХНОЛОГИЙ БД

 

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

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

Современные СУБД постоянно со­вершенствуются, появляются новые требования к их работе, и неизвестно, что придумают завтра.