U-geneserg99пропущено...

Увлекательное чтиво. :-)

Ржу уже изпадстала. Там полтекста между первой и второй страницей не видно, но "увлекательное чтиво". :) Анекдот.

В свете "Я собственно и не сомневаюсь что Вы теоретически подкованы гораздо лучше меня." это выглядит особенно мило.

Вы уж, дружище, определитесь.
Так я смайлик поставил. С ходу почти ничего не понял. :-)

U-geneserg99пропущено...

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

U-geneЛюбая система - это набор правил, которых надо придерживаться, что бы получить какие то возможности. Я ввожу всего одно правило "объект = реляционная БД" и предлагаю реализующие его средства. Если пользователь примет это правило и воспользуется этими средствами (очень КМК несложными) , он получает возможности и реляционных СУБД и OOЯП в одной системе.
У Вас же вычисляемые свойства не могут быть персистентными. Значит Вы сами своё правило и нарушаете. :-) ООЯП и СУБД сейчас и так есть в одной системе. ООЯП на стороне клиента, а СУБД на сервере. Думаю и Ваша надстройка может быть оформлена как клиентская библиотека. При этом если Вы обеспечите совместимость с разными РСУБД (Oracle, MS SQL и т.п), то эта библиотека не будет завязана только на My SQL, что с точки зрения коммерческого успеха правильно. При этом изучать Ваш инструментарий должны будут прикладные программисты, которые и так вполне комфортно себя чувствуют с ООЯП, а не администраторы БД, которые вряд ли захотят изучать что то новое, а тем более брать на себя ответственность за корректную работу неизвестной никому серверной прибамбасины.

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

U-geneserg99У Вас же вычисляемые свойства не могут быть персистентными. Значит Вы сами своё правило и нарушаете Опана. Уровень дилетантизма меня поражает.

Вот весьма формальное определение реляционной базы данных, которое дает Дейт
T h e T h i r d M a n i f e s t o
(version dated October 30th, 2011) http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-2011-10-30.pdf

14. Database relvars shall be either real or virtual.
....
16. A database shall be a named container for relvars; the content of a given database at any given time shall
be a set of database relvars. ...
Оригинал здесь

Как видно, база данных - это набор любых relval. Они могут быть и хранимыми и вычисляемыми. Если по-простому: РБД - это не только таблицы, но и виды. Что в точности соответствует компонентам моих объектов.

Ваши дальнейшие рассуждения про ООЯП я воспринял как отвлеченные философские рассуждения, опять о чем то о Вашем личном.
Почему же Вы решили что вычисляемые релвары не могут быть персистентными?

Тот же Дейт пишет.

"База данных— это некоторый набор перманентных (постоянных) данных, ис-
пользуемых прикладными системами какого-либо предприятия."

Данные которые не переживают порождающую их транзакцию с моей точки зрения нельзя назвать постоянными.

Конечно и у Дейта взгляды могут меняться. А я как дилетант за этим естественно не слежу.

U-geneВы разницу между данными таблиц и видов понимаете? Первые хранятся, вторые вычисляются - на основании хранимых данных . Поэтому БД целиком - это как пишет Дейт "некоторый набор перманентных (постоянных) данных". которые либо представлены точно в том виде в котором они храняться (таблицы), либо иным образом (виды), о чем он пишет в другом месте.
Как правило Вид это всего лишь ссылка на подзапрос и временные таблицы соответствующие Видам существуют не дальше своей транзакции. А могут и совсем не существовать так как запросный оптимизатор может их заоптимизировать совместно с основным запросом. Соответственно постоянными данными эти Виды назвать нельзя. И у Дейта нет знака равенства между виртуальными релварами и Видами.

С другой стороны то что в Оракле называется материализованными Видами в принципе можно назвать постоянными данными, так как они могут жить своей жизнью долго. Но там совсем другие принципы реализации.

Собственно всё это не так уж и важно. Если Ваша система работает и приносит кому то пользу, то и слава богу.

_модserg99 нужно прикручивать объектный подход к модели данных БД.
Суть объектного подхода - обойтись без моделирования данных. Он вообще отрицает наличие какой-либо МД.
Вот есть объекты - с ними и работай напрямую.
Мне представляется что модель данных не связана с моделированием данных. Я вообще не очень понимаю зачем нужно моделировать данные и что это такое.