Это все конечно здорово но вы таки не ответили на мой самый первый вопрос: задлянафига это все нужно.
Зачем я буду напрягать свой моск, зачем новички будут учить старый добрый SQL, и новый злой SQL++
Без ответа на этот вопрос, понятного даже такому ретрограду как я, в терминах которые можно измерить без определений типа модно, круто, современно, можно до хрипоты спорить об реализациях, но оно все равно не взлетит.
U-gene0) ничего не исчезает - по-прежнему можно использовать обычные для SQL табличные структутры. То есть появляется только дополнительный интерфейс к базе, милый сердцу объектникам. То есть об экономии речи не ведется, разработчики СУБД должны тратить ресурсы, плодить баги и т.п. реализуя эту фичу и что же получая взамен.
U-gene1) Появляются классы.Афигеть какое преимущество.
U-geneвместо того, что бы делать JOIN, использовать точечную нотацию. Типа набирать меньше
То есть вы привели два слабых пустых аргумента, которые меня ни в чем не убеждают. Да хрен бы со мной, но оно не убедит и других
U-gene2) Появляется возможность использования ссылок между классами.Если под ссылкой вы имеете ввиду, дополнительное неявное ограничение налагаемое на параметр в процедуре, то я согласен, смысл имеет
U-geneПо сути речь идет о динамическом UNION, который автоматом может подтягивать данные из разных источников. В обычном SQL такого не достичь... точнее, каждый раз, когда появляется новая разновидность данных, которая должна попасть в какой-то результирующий отчет, мы этот отчет должны обязательно править руками, явно добавляя туда источник новой разновидности.А чем вам вьюха не угодила
U-gene4) Собственно запросы к классам. Запросы к классам основаны на О-видахЧем ваши О-виды лучше старого доброго, отлаженного SQL, известного многим. Я сомневаюсь, что вы хотите стать новым гуру и стричь купоны на лекциях, семинарах и книжках.
U-gene5) Методы инкапсулированы в классе и полиморфны. Допускается групповой вызов методов.Пример задачи, решение которой старыми методами громоздко, некрасиво, подверженно ошибкам.

Еще раз U-gene это вы попросили нас оценить вашу концепцию. Это вы должны доказывать что ваши расширения имеют право на жизнь. Я мыслю, что объекты в программировании были внедрены чтобы упростить жизнь разработчикам заменив линейный список процедур иерархическим списком объектов.
Еще раз повторю - приведите пример success story - база: тысячи таблиц и вьюх, десятки тысяч процедур, длительный срок разработки разными разработчиками, отвратительная документация, не следование соглашениям о наименованиях, короче ад для поддержки, а вот если бы использовать вашу придумку то .....

U-gene Какой дополнительный интерфейс, извините?Я так понимаю что база остается базой, таблицы таблицами, а также вьюхи и процедуры. То есть с базой можно будет работать по старинке, обеспечивая обратную совместимость.
ПЛЮС вы добавляете еще одну возможность работы с базой - через классы.

Хорошо поставим вопрос иначе - поддерживает ли ваша база обычный SQL. Есть ли у вас обратная совместимость?
Если совместимости нет, то вам будет легче показать достоинства вашего подхода, но придется реализовывать туеву хучу всякой обвязки - драйверов, компонент, утилит и т.п.

Неменее уважаемый U-gene
Статью я дочитал, предыдущий запрос снимается.
Но я таки не нашел чем (при каких обстоятельствах) ваша RxO система лучше уже имеющихся.