r.nik.Павел Воронцов,

Всё конечно так, как Вы сказали. Но программа не большая и отчуждаемая и тут появляется несколько моментов:
1. Стурктура данных навязана и будет меняться абсолютно точно.
2. Всё остальное в программе достаточно просто конфигурируется, кроме структуры базы данных. И мне кажется это косяком.
3. Программа сама очень маленькая и хибирнейт займёт больше места на диске, чем сама программа со всеми остальными зависимостями.

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

ИМХО, тут первого пункта достаточно для того, чтобы использовать ORM. На практике, меняется модель, и Вы видите, где-что поехало...

r.nik.... но это не та работа, на которой можно много зароботать.

Чтобы много заработать, нужно вечером после основной работы дома изучать, думать, изобретать, анализировать, планировать, делать, менять, взвешивать, оценивать и писать на SQL.ru))) если, конечно, Вы не "Сын Рокфеллера")))

Petro123r.nik.1. Стурктура данных навязана и будет меняться абсолютно точно.
- ЧАСТО структура данных описывает Модель предметной области. Т.е. это неизменная часть.
Приведи пример обратного в сети.

Petro, это нормально при отсутствии нормального аналитика...

r.nik.Добрый день!
Я хочу странного. Мне нужно что-то типа ORM, но чтоб при изменении структуры не приходилось перекомпилировать приложение (пакет), а достаточно было просто поменять конфиги.

Отвечаю на резонный вопрос, как я это вижу:



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

Требуется поддержка трёх БД: MS Sql, MySql, postgreSQL.
Спасибо тем, кто ответит.

Нате вам лекарство

-=*ShamaN*=-r.nik.Добрый день!
Я хочу странного. Мне нужно что-то типа ORM, но чтоб при изменении структуры не приходилось перекомпилировать приложение (пакет), а достаточно было просто поменять конфиги.

Отвечаю на резонный вопрос, как я это вижу:



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

Требуется поддержка трёх БД: MS Sql, MySql, postgreSQL.
Спасибо тем, кто ответит.

Нате вам лекарство

Хм... я тут призадумался.... а ведь с этой штуковиной можно полностью динамический словарь данных построить, типа как в 1С и ему подобных. Но это должно остаться "под капотом".

Топик-стартеру на заметку: при динамической работе с моделями вы потеряете контроль, который производится компилятором в случае мапинга "Модель=Класс" в JPA.
Я хочу сказать, что конструкции вида
при изменении модели (например, при переименовании колонки в addr) спокойно пройдут компиляцию, в то время как конструкция
просто не скомпилируется, и вы увидите сразу все неликвидные обращения к модели при изменениях последней. Чтобы подобный контроль работал и при построении запросов, в JPA предусмотрены классы статической метамодели - это volatile описатели атрибутов модели, которые можно передавать в качестве аргументов.

Я не навязываю свой мнение, а лишь излагаю 2 подхода. Вам нужно 100500 раз подумать, нужно ли вам приходить к модели неконтролируемого датасета Delphi...

Petro123-=*ShamaN*=-,
конечно. Динамический SQL тоже считается моветоном разработки:
string = SELECT + Field + Name + FROM
ВыполнитьБД(string)
"Всё хорошо.... в меру"

Почти одновременно))))

Petro123-=*ShamaN*=-,
конечно. Динамический SQL тоже считается моветоном разработки:
string = SELECT + Field + Name + FROM
ВыполнитьБД(string)
"Всё хорошо.... в меру"

Petro, я с Вами абсолютно согласен, хреновый моветон...
Особенно, когда требуется наследование запросов - ну типа родительский Query одну таблицу селектит с фильтрами по полям, а наследники должны добавлять разные джойны или агрегаты.