Добрый день.

Хочу попросить местных завсегдатаев высказать мнение о расширениях 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 допускает дублирование строк в таблицах.

Насчет EAV - хороший вопрос.

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

Когда говорят об объектах, то обычно (точнее все и всегда _{кроме меня, конечно:)} ) подразумевают объекты, являющиеся результатом эволюции систем программирования фон-неймановских машин с адресуемой линейной памятью . Как результат, мы имеем систему, которая заменила адреса на некую семантику. В простейшем случае, пара "OID + имя атрибута (свойства)" (о которой Вы говорите) является точным аналогом пары "адрес + смещение", дающая точный адрес какого-то скалярного значения. При этом сама семантика преобразуется в тоже скалярное значение (значение смещения)

Так вот. EAV пытается в лоб эмулировать линейную память. Этот подход ассоциирует пару "OID + имя атрибута (свойства)" со скалярной (и никакой иной!) величиной свойства. Семантика (имя свойства) используется как скалярное значение , с которым эта хранимая величина ассоциирована. Тем самым реляционное хранилище низводится до линейного хранения множества скаляров. От возможностей реляционной модели при этом ничего по сути не остается.

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

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

Еще одно принципиальное различие.Но я сначала у Вас уточню. Насколько я понимаю, EAV есть попытка отображения объектов в реляционную БД. В какой-то программе есть объект, данные о котором надо сохранить в реляционной БД. Соответственно, некое скалярное значение (свойства) копируется из памяти, занимаемой программой в строку EAV таблицы, а потом, по мере надобности, наоборот, восстанавливается из таблицы в память, занимаемую объектом. Это так?

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

Я можно поподробнее - какие структуры, где они, как вы себе процесс представляете?

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

Еще раз спрошу.

Вы мыслите отображением (переносом, копированием, сохранением) значений объектов, существующих в памяти программ в таблицы реляционной БД?

Я от Вас прямого ответа добиться не могу. Скалярные значения из памяти в рел БД по Вашему переносятся или нет? (будь они оформлены как объекты, копии строк или что то еще) перенос скаляров(копирование) из памяти программы в БД по Вашему обязателен, для того, что бы утверждать, что объекты существуют?

Вот эта мысль
Сложно в реализации: меняется структура класса - надо менять структуру его таблиц и менять программы, заточенные на старую структуру. И все в автомате ! она вообще откуда взялась? Кто вам это сказал? Вы это так утверждаете, как будто я меняю класс и потом для этого изменения должен отдельно согласовывать структуру таблиц (собственно я поэтому с вопросам и присаю). Но это не так.

Программа, заточенная на структуру - это что? RxO система вполне самодостаточна. Никаких внешних специально заточенных программ не нужно. Модель предметной области создается и поддерживается целиком на сервере. Этой моделью можно откуда угодно. А если мы поменяли модель на сервере, то естественно запросы тоже могут требовать изменения... Но это замечание к объектам никак не относится. С таблицами абсолютно такая же ситуация.

Кстати
С EAV все просто - структура БД не меняется никогда, соответсвенно не меняются программы. То есть классы совсем не меняются? А если надо будет вдруг тип свойства поменять. Было INT, вдруг нужно LONG? Как в EAV это решается?

Кстати, вы собственно статью, где система описывается, прочитали?(это простой вопрос, он требует ответа "да" или "нет") А то я заметил, что многие пытаются сделать выводы исключительно на своих представлениях. Хотя, вместо того, что бы догадки строить, можно прочитать. RxO - это вообще о другом, чем EAV.

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

2. Нельзя менять мудель, если эта версия этой мудели законтрактована (или контрагенты должны автоматом настроиться на новую модель интерпретировав семантику изменений - кароче послать мудель нафиг, если невозможно интерпретировать и настроиться). А это проблема клиента. Схема открыта, пусть интерпретирует и настраивается, если надо. Я еще раз повторяю - вопрос изменения схемы не зависит от того, имеем мы дела с таблицами или с классами.

Очень просто. Просто меняется тип свойства и все. Прога при этом не меняется (если, конечно, приличная прога :)) Тоже загадка. Где меняли, зачем меняли?

Ктсати, я правильно понимаю, что вот здесь, с 16-го по 32-й слайд - это и есть EAV?

В любом случае, я EAV рассматриваю как очень частное решение применимое в очень конкретном ряде случаев. При этом, что самое главное, я вообще не рассматриваю EAV как альтернативу RxO-системе. EAV - это отображение объектов из программы в РБД. RxO-система - это существование объектов на стороне сервера (программы вообще не требуются) который сохраняет все возможности РСУБД ( кстати, если угодно - EAV можно реализовать на сервере, реализующем RxO.... не знаю зачем, но можно). Это идейно разные вещи. поэтому давайте про EAV закроем тему. Если хочется поточить когти на эту тему, можно возобновить это обсуждение. Я там кстати, уже задал вопросик.


PS. Я, кстати, не в коем случае не утверждаю что RxO-система есть общее решение для всего.

2 SERG 1257

Я вот на эту фразу наткнулся
То есть появляется только дополнительный интерфейс к базе, милый сердцу объектникам
а дальше вопросы читал невнимательно.

Какой дополнительный интерфейс, извините?

SERG1257 ПЛЮС вы добавляете еще одну возможность работы с базой - через классы
Да. Но где Вы при этом нашли какой-то дополнительный интерфейс, мне не понятно.

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

Это не так.

Уважаемый SERG1257 ,

Если прочитали бы статью (хотя бы пару станиц), вопрос "поддерживает ли ваша база обычный SQL?" вообще бы не встал. То есть Вы ввязались в спор даже не удосужившись ознакомится с предметом обсуждения. Ну это же не серьезно.

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

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

Если я отвечу
"приблизительно тем же, чем С++ лучше С."
не уверен, что вас этот ответ устроит.

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

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

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

Вы совсем до конца дочитайте :) может у Вас и другие вопросы снимутся?

2 _мод
Вы добавили новое св-во в класс, надо добавить столбец в таблицу.
Я не хочу вдаваться в реализацию, но добавление свойства (это не мой термин) выражается в добавлении столбцов и в др. манипуляций с реляционной памятью (а не отображается, как вы считаете). Вас это не должно волновать. Одна команда ALTER CLASS... и все добавлено.

Так есть только два способа отобразить объекты на таблицы: традиционный и EAV (или еще как в Каше - все в одну строку) Это кто сказал? Какой такой традиционный способ? А в Каше - это уже третий? Так два или три? А вдруг четыре?

2 Дедушка
ваш пример с С и С++ не корректен тут Поченму не еорректен? Мне лучше видно. Интересно, а что SQL прям весь такой из себя ОО? Ммммм....

зАчем описывать предметную область в ОО-терминах в контексте SQL Фиг ее знает. Рубились когда то по этому поводу. Дураки наверное. Но даже не в этом дело.

Я предлагаю инструмент, кусок языка. Это не модель, не парадигма, не концепция описания предметной области (я не хочу вдаваться в это). Для того, что бы понять что этот инструмент позволяет, можно статью прочитать до конца. Там есть сквозной пример с запросом и с множественным наследование - он показывает возможности инструмента. Второй раз пересказывать то же самое я не буду. Я просто предлагаю возможность. Я говорю - "теперь можно так сделать", и не в коем случае не говорю что "это нужно". Вопрос "Зачем это делать" я оставляю на Ваше усмотрение. Если Вам это не надо - я не буду настаиваю.

Я наблюдаю здесь, что большинство отвечающих твердо убеждены в том, что именно их видение архитектур, интерфейсов, технологий является единственно правильным. Точно так же народ когда то спрашивал зачем С, если есть ассемблер, или зачем С++, если есть С (последнее - в т.ч. и про меня). У меня книжка есть 70-го года "предложения CODASIL" где автор очень скептически относится к реляционной модели. Ваш вопрос - из той же области. Ответ простой - раньше было нельзя, теперь можно. И всё.

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

_модU-geneКстати, вы собственно статью, где система описывается, прочитали?
Прочитал. Мое имхо: овчинка выделки не стоит. Поскольку рез-т запроса всегда таблица, то иметь в БД две разные сущности (виртуальные объекты и реальные таблицы) - это перебор.

По Вашему - перебор, а по моему - новая возможность.

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

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

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

_мод Пример: как создать мн-во объектов из запроса - сущности то разные.

Не понял.Зачем создавать множество объектов из запроса? Мне не нужно создавать объекты. Они существуют на стороне сервера. Я там описываю данные через классы, я изменяю данные об объектах этих классов, я получаю получить данные об этих объектах (в виде отношений). А получать объекты мне не надо. Я про это и говорю на первой странице "запросы возвращают данные об объектах (а не сами объекты)" Видимо, Вы невнимательно читали. Мне получать объекты с сервера не надо. Они там существуют, они снаружи управляются.

А объекты мне не нужны Их нет. Только таблицы (хотя их тоже нет, но это уровнем ниже).