Database Programming & Design

       

Вот несколько "надежных" предсказаний на следующие пять лет:


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

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

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

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

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

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


Содержание раздела