hellslade
ОРМ - прокладка между вашим приложением и РСУБД, позволяющая сохранять объекты.

ОРМ - это Опытный Ракетный Мотор. Его схемы и описания есть здесь: http://www.astronaut.ru/bookcase/books/salah05/text/07.htm

u4upy
Не фиксируйтесь на литере “школьникам”.)
Попробуйте подумать, что именно вы знаете про реляционные БД и про ООП, а затем попробуйте школьникам на схеме обьяснить, пальцем ткнуть в стрелки, блоки, в блоках показать строки.

Схемы нужны тогда, когда необходимо добиться понимания (или эффекта понимания) за один сеанс. У вас какая задача? Самому понять или когото убедить?

Только что просмотрел книгу “Pro JPA 2. Mastering the Java™ Persistence API” издательства Apress.
Есть UML-диаграммы самих классов но не более… Вот ее можете и посмотреть

У вас какая задача? Самому понять или когото убедить?

Скажем так, меня вчера настойчиво убеждали, что ORM это лишнее. На примере адресной книги из статьи про ORM в википедии. И блоки мне рисовали и стрелочки. Даже на ЛОРе откопали мнение товарища baloo, что жить без ORM можно и нужно.

Задача в конторе переписать несколько небольших 1С-приложений. По схемам получается, что SQLAlchemy плюсов не дает. Такие дела.

В общем решил, что пока не озарит, дергаться не нужно. Все со временем поймется. Или не поймется.)

По схемам получается, что SQLAlchemy плюсов не дает.

lol

Ferroman

По схемам получается, что SQLAlchemy плюсов не дает.

lol

Небольшое учетное приложение, реестр документов юрлиц, с историей движения, с todo для исполнителей, 9 табличек. Было на 1С, за сегодня перетащили на питон. QtSQL. Где lol, почему lol?)

u4upy
Задача в конторе переписать несколько небольших 1С-приложений. По схемам получается, что SQLAlchemy плюсов не дает

Задачи разные бывают. Бывает лучше руками написать пару нормальных запросов, посмотреть их план выполнения, оптимизировать, вставить в код.
Бывает лучше использовать ORM. Без ORM жить можно, да, потому что это костыль на самом деле.
Снова же, если у вас приложения, которые активно используют хранимые процедуры, тогда ORM не поможет никак.

u4upy

У вас какая задача? Самому понять или когото убедить?

Скажем так, меня вчера настойчиво убеждали, что ORM это лишнее. На примере адресной книги из статьи про ORM в википедии. И блоки мне рисовали и стрелочки. Даже на ЛОРе откопали мнение товарища baloo, что жить без ORM можно и нужно.

Задача в конторе переписать несколько небольших 1С-приложений. По схемам получается, что SQLAlchemy плюсов не дает. Такие дела.

В общем решил, что пока не озарит, дергаться не нужно. Все со временем поймется. Или не поймется.)

А в таком ключе. Конечно нет, ORM не нужен. Если нет вопросов с человеческими ресурсами, с удешевлением саппорта, с необходимостью дальнейшего расширения - то пишите лучше на штатных средствах СУБД.
ORM, это по большому счету, сборник готовых SQL шаблонов для летняев или одиночек бурущихся за неподьемные, другими средствами, задачи. Он снижает время разработки, расширения и саппорта и не более того. А у вас, я так понимаю, стоит задача сделать идеальное монолитное и не нуждающееся в саппорте приложение ;). Такие задачи однозначно лучше начинать от превоисточников.

Потому что определять “плюсы ORM” по схемам - это таки lol. Как определять плюсы лечения по картинкам.
По каким, к лешему, схемам? Задача ORM - построение абстракции вокруг баз данных. Что:

1. Позволяет переносить приложения с одних движков на другие без переделывания запросов.
2. Работать только с программным кодом.
3. Не писать свои абстракции вокруг SQL
4. Сразу создавать нужную архитектуру приложения ориентируясь на подход использованный в данной реализации ORM.

Одновременно с этим:
1. Накладывает определённые ограничения на оптимизацию
2. Требует понимания как работает конкретная реализация орм
3. Медленнее работает
4. Часто не позволяет использовать некоторые полезные особенности движка базы данных
5. Накладывает определённые ограничения на архитектуру приложения.

<b>denz</b> Вашим ответом, ИМХО, можно закрыть тему. Единственно с чем не согласен так это: “для летняев или одиночек”