ViPRosU-geneпропущено...
Так напялено уже давным-давно. Принцип напяливания давным-давно используется в куче систем (в том же 1С). Почему бы его не формализовать и не запихнуть в СУБД?
потому что сразу потеряется основной козырь - "n транзакций в секунду" не понял

эттаа. никому не надо, кроме фриков с "ООП головного мозга"
б. не ясно, как сделать, чтобы хоть кому--то понадобилось для дела


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

Помимо выразительности, другое важнейшее свойство - гибкость модели. Применительно к объектам это означает возможность on-fly менять объекты не только "количественно" (т.е. их состояние), но и "качественно", говоря по-простому, менять интерфейсы, реализаций,создавать новые классы и т.п. и т.п. в существующей, работающей модели . Кстати, одной из причин неудач ООСУБД было то, что схема классов, создаваемая с использованием современных ООЯП, фиксирована, любое ее изменение означает тотальные перестроения, перезапуски и сопутствующие танцы с бубном. И оказывается, вопрос изменчивости сложной схемы и данных в рамках этой схемы, требуют решений, которые не то что не реализованы, но почти не рассматриваются в контексте существующих ООЯП.

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

MasterЗИВ,

Давно уже. Просто в пласт лежит, но, пока, концептуально.

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

этта,

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

так же и у меня - для доказательств голой теории подходит любая реляционная СУБД. А эффективная реализация требует влезть в физику ядра, на уровень, где существуют страницы, локи, пины, структуры, указатели на структуры, кое-что добавить, немного расширить каталог и т.д. Для этого, для начала, надо иметь доступ к коду СУБД. У Вас есть доступ к коду MSSQL? Я б может даже рад был бы, ибо бизнесу решения от MS до сих пор ближе. А у PG код открыт, архитектурно то, что я успел о нем узнать, мне нравится, по сравнению с другим опенсорсом. Но принципиальной разницы, MS или PG для меня нет.

Кстати, я не понял, что, у PG DDL более "транзакционен" чем у MS? Как "транзакционность" меряется? Хотя это к делу не особо относится.