Обсуждаем ORM

[Paramedic]

ОРМ позволяет проектировать

Упаси святые угодники, от такого проекта. При проектировании базы данных должны учитываться РЕЛЯЦИИ. На которых и строиться вся реляционная логика. ООП оперирует просто объектами. Реляции попросту выпадают при подобном подходе. Так что проектировать РЕЛЯЦИОННУЮ БД средствами ООП это как-то странно. Ладно, если бы хранилище было заточено строго под ORM. Такие в природе есть, но проблем от их использования не меньше.

[Paramedic]

Лень читать.

Зря. Может быть что-то пересмотрел в своём подходе.

[Кувалдыч ТС]

Класс это проекция таблицы на объект.

Не правда реляционная БД может быть только сопоставлена с аотрибуами обьектов, не никак не с классом. К примеру оан не реализует алгоритмы и интерфейсы класса, и это только один из случаев того что не может реализовать маппинг таблиц.

ORM не может работать без метаданных.

ОРМ и есть металанные. Ессно без самой себя, т.е. кодового описания модели класса она работать не будет.

У разработчика свой логин/пароль

Боле етого, у каждого человека или приложения свой логин пароль и что? Это мешает?

Ты признаёшь, что через ORM база крадётся, а через классический подход -- нет?

Нет конечно. Ты просто не прочитал тот большой текст что я написал про методы краж.
Крадется все. Но БД крадется в разы проще если к ней есть прямой доступ.

[Paramedic]

Так же ОРМ позволяет ввести еще один уровень безопасности над данными (кроме той что возможна на источнике),

Только в случае, если БЛ не прописана на стороне РСУБД. О безопасности данных может позаботиться РСУБД, да ещё таким образом, что ORM и не снилось.

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

Это заблуждение, вызванное тем, что ORM разработчик напрочь забывает о хранилище. Даже если бы данные хранились не в РСУБД, а, скажем, в том же JSON в файловой системе, то изменение алгоритма вызывало бы массу проблем.

[Кувалдыч ТС]

Может быть что-то пересмотрел в своём подходе.

Не думаю что там есть что-то новенькое. Я за свои 20 с лишним лет стажа в программировании разрабатывал множество разных систем. С разными технологиями и требаваниями.

В том числе описанными вами хранилища с доступом через процедуры.

Для меня вообще это обсуждение уже стало свовсем скучным, ибо не знаю как еще объянить заблуждения на счет обсуждаемых вопросов. Ибо смешано все в кучу. И гвозди и технолгии с архитектурой.


Еще раз повтрю - субд это мой еж. ОРМ и т.п. это гараж для ежа. Попробуйте украсть ежа из гаража. С учетом того, что ежа в нем не бывает.

[Paramedic]

Боле етого, у каждого человека или приложения свой логин пароль и что? Это мешает?

Это мешает тем, что у разработчика назначена ИНАЯ РОЛЬ и ИНЫЕ ПРИВИЛЕГИИ, которые не дают возможности работать с данными на прямую, и прячут метаданные.

[OVA]

Это значит что внедрившись во фронтенд, самую незащищенную часть приложения, мы имеем ПОЛНЫЙ доступ к БД. Можем закачать ее хоть всю. При чем вместе с метаданными, так как в любой СУБД можно строить запросы к скрытым служебным таблицам описывающим структуру БД. Т.е. спереть БД целиком тут просто как нефиг делать. Нужно лишь проникнуть во фронтенд.

Нифига. Только обратишься к тому, к чему разрешено обращаться в базе тому пользователю, от имени которого фронтэндом обращается к базе.
Стырить метаданные можно, да и толку-то от них без данных?!

Игорь опередил. Ку, роли в SQL-серверах творят чудеса! И если юзеру назначена роль "мастер по ремонту обуви", то ничего позволенного только "министру обувной промышленности" он ни в жиссь не получит из базы.

[Кувалдыч ТС]

Только в случае

В любом случае. Ибо как иет работа? С какой стороны? Сначала обращение к атрибуам объекта бизнес-логики, а значит и контроль доступа к ним, а уже потом, при наличии доступа извлекаются данные аотрибута из СУБД, и вот тут уже срабатывает ограничение доступа внутри СУБД.

[Paramedic]

Для меня вообще это обсуждение уже стало свовсем скучным, ибо не знаю как еще объянить заблуждения на счет обсуждаемых вопросов. Ибо смешано все в кучу. И гвозди и технолгии с архитектурой.

Так ты открой статьи-то по ссылкам, и методично опровергни тезисы.
Например тезис о том, что ООП использует наследование, которого нет в реляционной модели. И реализация наследования приведёт к жутчайшим тормозам.

Опровергни тезис о том, что ORM тащит всегда все поля, когда их надо всего два. И тем самым создаёт тормоза.

Ну и много чего нужно опровергнуть.

[Кувалдыч ТС]

Это мешает тем, что у

Ою этом я уже писал в "большом посте".

[Paramedic]

Но БД крадется в разы проще если к ней есть прямой доступ.

Безусловно, для этого и создаются шлюзы и демилитаризованные зоны. Только при чём здесь ORM? На шлюзе может совершенно спокойно сидеть классическая реляционная разработка, а наружу будут уходить данные, хоть в твоём любимом JSON, хоть в XML, хоть в криптографическом формате.

[Кувалдыч ТС]

что ООП использует наследование, которого нет в реляционной модели.

В реляционной модели наследование есть. И реализовать их там можно разными способами. И не обязательно тормозными.

ORM тащит всегда все поля

Не всегда и не все. Только те, что прописаны у модели ОРМ. При чем реализация загрузки объекта может быть гибконастроенной. К примеру, сложные объекты могут иметь "ленивое" чтение, т.е. когда некторые поля загружаются из БД не сразу при чтении объекта, а лишь к приобращении к соотвествующим атрибутам объекта.

[Кувалдыч ТС]

для этого и создаются шлюзы и демилитаризованные зоны.

ну оно не для этого... это уровень сетевой безопасности, а не безопасности бизнес-логики или уровня данных.

Только при чём здесь ORM?

Это ты у себя спрашиваешь?

в твоём любимом JSON, хоть в XML

При чем тут ОРМ?

Да и любимых форматов или технологий у мну нет...

Я же не могу любить молоток больше, чем пассатижи или наоборот

[Paramedic]

Ою этом я уже писал в "большом посте".

Так ты не даёшь свой "большой пост" прочитать. Пишешь много букв. Вот этот пример:

Еще раз повтрю - субд это мой еж. ОРМ и т.п. это гараж для ежа. Попробуйте украсть ежа из гаража. С учетом того, что ежа в нем не бывает.

не функционален. СУБД это средство управления БД. Это даже не твой гараж. Твой гараж -- это БД. Это целая инфраструктура. ORM это инструмент, который пытается получить данные реляционным способом, через подачу SQL запросов. Которые пишет криво, тупо и глупо.

[OVA]

БД крадется в разы проще если к ней есть прямой доступ

Ужоснах... Кому в здравом уме в голову придёт юзерам давать прямой доступ к базе данных?!

В том числе описанными вами хранилища с доступом через процедуры.

Это, кстати, нереально дорогой путь и ненужный на практике. Привёл просто как пример.
Удобно таким образом оформлять подсистемы обмена данными, к примеру, стандартизируя обращения к процедурам в разнородных хранилищах.

Можно дальше и не продолжать. Быть может, Ку набрёл на такую специфику, где применение ORM оправдано. Но мне лично в своей области хватает классической трёхзвенки или вообще чистого клиент-сервера.