На Django создаю проект, в котором ORM на основании объектов модели создает таблицы в Postgres. Хочется понимать в чем проявляется смысл объектно- реляционной БД, чтобы создавать модели, которые будут эффективно писаться / храниться / читаться. Подобно тому, как в реляционной БД можно создать неэффективные таблицы, которые снизят производительность приложения, так и я опасаюсь выбора неправильной архитектуры объектов моделей.

Может кто- то объяснить (книжки на эту тему дружно молчат) в чем собственно выражается объектность Postgres и как это влияет на проектирование объектов моделей (по которым ORM создаст таблицы)?

King_cat
Postgres - реляционная СУБД, питон - объектно-ориентированный язык, ОРМ - это технология позволяющая сохранять объекты питона в реляционной СУБД. Да просто фреймворк поверх питона, который преобразует объекты в строки таблиц и наоборот, плюс там построитель запросов. Postgres при этом никак не пострадал, он об ОРМ ничего не знает, Джанга ему присылает нормальный SQL, и там в бэкграунде невидимо все общение в терминах табличных баз данных - соединенние, курсор, запрос, коммит, роллбэк. Да просто все как мычание, ты пишешь
а питон это преобразует в
, а ответ назад в объекты
и все, не стал от этого постгресс другим, это классическая табличная СУБД

FishHook
Postgres - реляционная СУБД
…
не стал от этого постгресс другим, это классическая табличная СУБД

Первое предложение на главной странице сайта Postgres гласит:
PostgreSQL is a powerful, open source object-relational database system with over 30 years of active development that has earned it a strong reputation for reliability, feature robustness, and performance.

Поэтому очень интересно в чем эта object-relational выражается.

Это говорит что она работает с обьектами а не документами как например монга

ZerG
Это говорит что она работает с обьектами а не документами как например монга

И в чем эта работа с объектами выражается?

King_cat
И в чем эта работа с объектами выражается?

PostgreSQL - реляционная СУБД, и в этом смысле, если вы изучали ANSI SQL, то PostgreSQL со своими нюансами - как без этого - но работает очень похоже на то, как работают все RDBMS, будь то Оракл или SQLite. С другой стороны - это большой продукт с кучей своих уникальных решений, иначе в нем не было бы смысла, например наследование таблиц (уже запахло ООП), составные типы данных или хранение массивов.
Так вот, Джанга использует только “классические” возможности реляционных баз данных. Если вы хотите использовать всю мощь PostgreSQL, то вам придется отказаться от использования ОРМ и скорее всего Джанги вообще, все запросы вы будете писать вручную, скорее всего в виде обращения к хранимым процедурам, и ваш проект будет непереносимым, то есть другую СУБД вместо той, под которую писали код вы использовать не сможете. Это имеет смысл, если ваш продукт очень интенсивно работает с большим объемом данных, где много сложной бизнес-логики и различных оптимизаций. Для целей Джанги - это все оверхед, все-таки Enterprise решения не делают на Джанге.

коротко отвечая на ваши вопросы в стартовом посте

и как это влияет на проектирование объектов моделей (по которым ORM создаст таблицы)?

никак ровным счетом не влияет, модели в Джанге не зависимы от используемой СУБД

King_cat
в чем собственно выражается объектность Postgres, книжки на эту тему дружно молчат

можно читануть вот это
http://citforum.ru/database/articles/manifests/art_28_3_3.shtml

King_cat
как в реляционной БД можно создать неэффективные таблицы

эффективность вы скорее всего потеряете на неправильно написанных запросах нежели на неэффективной структуре. Любая ОРМ страдает N+1 проблемой и Джанга не исключение, наделать тормозных запросов можно запросто. Вы не о том печалитесь

FishHook
можно читануть вот это
http://citforum.ru/database/articles/manifests/art_28_3_3.shtml

Пардон, но статья написана в 2003 году, и возможно на данный момент все полностью изменилось.

FishHook
Вы не о том печалитесь

Я печалюсь о том, что легко могу изменить. Отказываться от ORM- значительно более сложная процедура, поэтому я хочу попробовать минимальными усилиями добиться пристойного результата.

King_cat
Отказываться от ORM- значительно более сложная процедура

тогда ваш вопрос о чем? Как я уже написал выше, ОРМ не использует 95% возможностей Postgres

King_cat
и возможно на данный момент все полностью изменилось

не изменилось ничего

King_cat
но статья написана в 2003 году

стандарт ANSI SQL возможности которого эксплуатирует Джанга принят в 1986м

Я просто вбил название топика в гугл и вторая ссылка
https://habr.com/ru/post/93356/

ниблогодорити