Добрый день.

Хочу попросить местных завсегдатаев высказать мнение о расширениях SQL описанных по этой ссылке . Для того, что бы заинтересовать, добавлю, что вариант статьи на английском опубликован на ODBMS.ORG

Единственный вопрос - стали бы Вы пользоваться этими расширениями?

PS Надеюсь, что здесь это к месту.

PPS Так и не понял, где эту статью можно выложить в рунете. Citforum загнулся, аналогов не нашел. Если кому интересно - пользуйтесь, размещайте, только про (с) не забывайте.

PPPS Основная теория (всего то десяток страниц) здесь . английский вариант идет туда же.

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

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

вопросВозьмем к примеру этот пример из описалова:
GOODS.Turnover.Contractor.Bank

Скока записей он вернет? Для каждой GOODS одну запись в результате? Или по числу банков?

это пример пути, а не запроса.
если это заголовок запроса (то есть там дальше есть атрибуты, например Name и BIC), то он вернет данные о банках, на которые есть ссылки, согласно пути указанному в заголовке.

вопросДругой вопрос. А если я хочу задом наперед: имея банки, получить goods:
BANKS <?> GOODS
Че посередке должно стоять? Или так низя делать?

Можно

например конструкция
GOODS [ .Turnover.Contractor.Bank.Name LIKE "Citi" ] .Art
вернет артикулы товаровЮ проданных контракторам у которых банк удовлетворяет условию. В скобках - критерий отбора объектов, где используются абсолютно те же пути. Критерии можно вкладывать как угодно.

Эклектично :) Я когда-то давным-давно использовал plain С и не как не мог понять, что же все носятся с С++. "Не все ли равно?" думал я что класс, что структура - те же яйца, только в профиль". Оказалось - не те. В общем, НВы стали смотреть на языковые конструкции, я предлагаю посмотреть на то. что этими конструкциями реализуется.

0) ничего не исчезает - по-прежнему можно использовать обычные для SQL табличные структутры.

1) Появляются классы. При этом мы исходим из идеи, что объект по своей сложности сравним с реляционной БД. Состояние объекта описывается множеством значений отношений (точнее - не более сложных, чем значения отношений). Если раньше мы хранили данные о , например, накладной в двух таблицах, то теперь можно описать класс "накладная", и вместо того, что бы делать JOIN, использовать точечную нотацию.

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

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

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

4) Собственно запросы к классам. Запросы к классам основаны на О-видах.Я уже сказал, что они - "замаскированные" реляционные операции. Результата - всегда отношений. О-виды могут быть произвольными, самое главное, что бы были употреблены "правильные" последовательности имен, заданные в описании классов. "Правильные" значит - те же имена в той же последовательности. Это единственно требование - система посчитает любой такой вид. В запросам можно комбинировать классы и таблицы, классы можно использовать как домены таблиц.

5) Методы инкапсулированы в классе и полиморфны. Допускается групповой вызов методов.

Вы говорите, что нет модели. Вам шашечки или ехать? Я сознательно не употребляю термин "модель" применительно к объектам. Мне это не нравится. Но смотрите. Структура объекта определяется правилом "множество значений, не более сложных, чем отношения". Я могу описывать сложные объекты, использовать ссылки, у меня реализованы инкапсуляция, тотальный(и компоненты и метода) полиморфизм, даже множественное наследование. Мне не нужны экстенты, мне не нужны итераторы, я обхожусь без обязательного описания обратных ссылок. В общем, модель (не люблю это слово, когда про объекты) есть. Просто она такая простая, что вы несколько раз мимо прошли и не заметили. Конечно, с ODMG3.0 где модель на ...цати листах описывается, она не сравниться. Там, только коллекций 8 штук , если не ошибаюсь. Моя модель маленькая, но достаточая, В ODMG модель сложная, а у меня она очень простая - при большей мощности.

Про OQL. (кстати - он вроде не загнулся ) Но, опять таки, давайте начнем не с конструкций, а с идеи. OQL создавался для программистами для программистов. Я не буду говорить, хорошо это или плохо, но полноценно работать с ODMG объектами можно только из языка програмирования. Кстати, насколько я понимаю, OQL не был ни разу полноценно реализован. Только какие то кусочки. Это был(есть?) такой красивый прожект.

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

А здесь запросы выполняются сервером as is (как любой SQL запрос), возвращают данные о состоянии объектов, существующих на стороне сервера. Результат - всегда отношение(таблица). То есть языковые конструкции местами может и схожи, но концепция и идея в целом вообще другая.

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

NafПерекликается с моей мыслью http://mynaf.narod.ru/OQL.html

Да, внешне местами похоже.

Но я, когда смотрю на такие впредложеня, в первую очередь пытаюсь оценить их с формальной точки зрения. Vadiminfo дал ссылку на "Третий манифест" Дарвена и Дейта. Цитата оттуда
Крис Дейт и Хью Дарвен «Foundation for Object/Relational Databases: The Third Manifesto»Можно предложить два возможных ответа на поставленный вопрос:
домен = объектный класс
отношение = объектный класс.
В главе показывается, что первый ответ - правильный, а второй - нет.

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

Подход, который я реализовал, никто никогда нигде вообще не рассматривал. Несмотря на отмеченное выше явное внешнее сходство моей реализации с существующими языковыми конструкциями, я основываюсь на идее "любой объект = реляционная БД", и далее реализую формальное преобразование, позволяющее представить множество таких объектов относящихся(к разным классам) тоже в виде (одной общей) реляционной БД.

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

2 Дедушка
Почему Дейт критикует SQL - что можно здесь прочитать Но, вообще лучше книгу "Третий манифест найти". Там, в приложении H, на 25 страницах Д&Д сравнивают SQL со своим видением "истинно реляционной системы" сравнивают по пунктам. А начинать надо с того, что SQL допускает дублирование строк в таблицах.