AlexTheRavenДумаю, правда, что полученная вещь будет слишком сложна для реального использования, но докторскую по ней защитить всё равно будет можно :) .

Объектное расширение SQL уже существует и, например, довольно удачно реализовано в СУБД Оракл. ИМХО, оное, предназначено для работы с объектными БД в традиционном (реляционном) стиле, что полезно, например, для генерации отчётов, для систем разработки, которые не дружат с объектными БД.

Стыковкой объектноориентированных языков программирования с БД занимается Object Management Group (OMG). Эта инициатива направлена на то, чтобы не использовать SQL вообще, хотя бы для того, чтобы прикладная программа разрабатывалась на одном языке программирования.

Дмитрий16 NafВыложил свои мысли по этому вопросу
http://mynaf.narod.ru/OQL.html
Прошу обсуждения


Мне не понравился (очень) один момент.
Зачем объеты таскаются целиком? Этоведь эквивалентно "SELECT *"

Я сейчас работаю над наложением объектной структуры на классическом MS SQL и пришел к нескольким выводам:
1. Объекты (ID) отдельно, атрибуты отдельно!
2. Чтение из базы объекта НЕ есть чтение ВСЕХ атрибутов.
3. Множество мелких скалярных запросов противопоставить одному большом селекту.

Обсудим?

1. Это поддерживается, например в Оракле. Например запрос:


вернёт ссылку на объект o и его значение v.
Если прямо сейчас зачение объекта не требуется, то можно получить только ссылку, а позже разименовать эту ссылку в объект операцией deref.

2. Как вариант - ленивая инициализация. ИМХО, имеет смысл только для очень медленных каналов связи при том что каждый отдельный атрибут объекта занимает очень много места и долго передаётся по сети. Например, в оракле для LOB полей можно сначала загрузить из БД только локатор, а затем по мере надобности подгрузить сам LOB или вырезки из него.

3. Накладные расходы на выполнение SQL запроса как правило довольно велики, кроме того запросы

и

занимают на сервере БД практически вдвое больше места чем один запрос


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

Анатолий Иванов модТаблица - это просто массив в терминах ЯП, т.е одна переменная.
В СУБД есть понятия схем, подсхем, права доступа, view. Суррогат, но все же.

Хм. А разве не таблица - класс, а поля таблицы - переменные/свойства/поля класса? Единственно, что методов у таблицы нет своих собственных для работы со своими данными.

Есть понятия класс, объект и компонент.

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

Если взглянуть на инкапсуляцию шире, то фактичеки структура данных инкапсулирована, поскольку данные доступны только через API СУБД и SQL запросы. Изменить атрибут объекта мы можем только с помощью команды update и т.д. Триггеры - суть специализированные методы объектов, правда триггеры вызываются на выполнение рекурсивно, в процессе выполнения SQL запроса, а не явно, как обычные методы.

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

По большому счёту, БД это средство асинхронных коммуникаций процессов, реализованное в виде файлов на диске. СУБД позволяет работать с этими файлами на следующем уровне абстракции, рассматривая их как набор таблиц, следующий уровень абстракции определяется Middleware, в частности объектным кэшем, который позволяет абстрагироваться от табличной организации данных и перейти к сетевой структуре, отказаться от SQL запросов в пользу навигации по объектным ссылкам. Следующий уровень - прикладной. Он позволяет наделить объекты некоторым дополнительным поведением, которое невозможно определить на предыдущих уровнях абстракции и скрыть структуру объекта от других объектов системы.
ИМХО, как со временем СУБД научились запускать триггеры, так же со времем СУБД или Middleware научатся реализовавывать процедурные интерфейсы объектов, Оракл сделал небольшой наг в эту сторону, к сожалению ограничившись PL/SQL, а пока пишите методы объектов в клиентских приложениях, WEB сервисах и хранимых процедурах.