[morebeauty]

Вот это -- да, вот это -- я понимаю! Видимо, каждый дельфист должен заново открыть для себя ООП и попытаться втиснуть его в реляционную модель. Для получения опыта -- почему бы и нет? Опыт -- штука полезная.

Ну а сарказм -- штука смешная. От души!

А вот тут хочу вас разочаровать: все плюсы надуманны от начала и до конца.

Для полноценной гибкости придется проделать огромную работу

Так само собой! Гибкость не для создателя системы, а для ее конечного пользователя! Так всегда, одни годами жопу рвут над написанием чего либо, другие потом покуривая сигару пожинают плоды. Ради этого все и делается.

Поэтому в этом

Хочется сделать самопальный ORM? Делайте. А вот преимущества из пальца высасывать не надо.

вы не правы...

Простота -- штука вообще субъективная, особенно если ее совместно с гибкостью рассматривать. А неумение программиста работать с базами данных -- недостаток, с которым надо бороться, а не потакать ему.

Я во втором своем сообщении привел пример с машинными кодами. Что же вы на них то не програмите?
А С++? Вы знаете, при каких обстоятельствах появилась идея создания этого языка на основе С? Дело в том, что программеры смогли откомпилировать абсолютно нечитабельную строку, после чего схватились за голову...

[Freeman]

Сообщение от morebeauty

Я во втором своем сообщении привел пример с машинными кодами. Что же вы на них то не програмите?

Да, я пишу на высокоуровневом ЯП, чтобы не париться. Тем не менее, SQL я пишу руками, потому как банально нравится.

Сообщение от morebeauty

А С++? Вы знаете, при каких обстоятельствах появилась идея создания этого языка на основе С?

Да, я читал книжку Страуструпа. Он -- человек культурный. Он почти что извиняется за нерадивых Кернигана и Ритчи, выпустивших джинна из бутылки. Правда, глядя на последний стандарт C++, можно констатировать, что мы вернулись в исходную позицию.

[morebeauty]

Да, я пишу на высокоуровневом ЯП, чтобы не париться. Тем не менее, SQL я пишу руками, потому как банально нравится.

Я, знаете ли тоже. Но когда столкнулся с необходимостью создать сложный перекрестный запрос на основе одной таблицы (который было проще некуда наваять в случае с MS Access), а вследствие некоторых особенностей вызов процедуры мне не подходил, пришлось выкручиваться. В итоге нашел два решения:
1. По циклу сформировал сложный запрос, который включал в себя еще 0-999 запросов (по циклу и условию), добившись того, что работать можно было через датасурс с ДБкомпонентами.
2. Написал очень, на мой взгляд, удобную функцию, которая по передаваемым данным возвращала двумерный массив со значениями. Для работы с ДБкомпонентами это, конечно, не подходило, но в некоторых случаях мне так было даже удобнее.

Да, я читал книжку Страуструпа. Он -- человек культурный. Он почти что извиняется за нерадивых Кернигана и Ритчи, выпустивших джинна из бутылки. Правда, глядя на последний стандарт C++, можно констатировать, что мы вернулись в исходную позицию.

Это да!
Но ведь идея была хороша! Жаль за реализацию ее взялись, не продумав все как следует!

[M.A.D.M.A.N.]

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

Объясните кратко и доступно какие преимущества даст ваш подход.