Опять срачь за ORM

[metaclass]

http://tonsky.livejournal.com/275048.html

Если обработаться на жабе и дотнете, то записи в таблицах БД действительно начинают казаться объектами, только заколдованными злыми DBA по чернокнижию дейта и кодда. И нужно использовать специальные магические зелья в виде ORM чтобы объекты расколдовать.

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

Оно конечно выглядит просто - "взял из ORM объект, показал в форме, по нажатию ОК отдал его ORM на сохранение". Но подобные решения намертво увязывают структуру БД, результаты запросов и типы объектов в программе. И вынуждают использовать в БД только структуры данных, которые хорошо в такое укладываются.

Comments

[ko-bx.livejournal.com]

Просто любители ORM (вроде меня) смотрят на базу данных как на деталь реализации персистентного хранилища для их моделей. Бизнес-логика вообще не должна подвязываться на БД и никак от неё явно не зависеть. Хотите -- выкиньте БД и храните всё в текстовых файликах.

То есть, "в идеале" вы начинаете писать всё на чистых объектах (тупо чистых объектах, в случае питона наследуемых от object), а затем "связываете" их с описанием БД (которое не является ORM, а это просто представляение вашей БД, собственно сама операция связывания и есть этот самый маппинг обджект рилейшнов). Sqlalchemy позволяет сделать именно это.

[serbod.livejournal.com]

У конкретных пацанов бизнес логика в самой БД сидит, и там простые и приятные ОРМы не работают. Только датасеты, только процедуры, только хардкор!

[anonim-legion.livejournal.com]

Да и память нынче дешева...

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

[ko-bx.livejournal.com]

Что ты несёшь?

[anonim-legion.livejournal.com]

То, что в проектах, подразумевающих ответственность, работа идет строго с базой. UPDATE или INSERT прошел, транзакцию закомиттили - все, данные никуда не исчезнут.

Но поскольку в большинстве уеб-проектов данные никому не важны, да и сам проект нужен только для перепродажи следующему инвестору - то там можно наворачивать сто слоев абстракции, держать все в оперативной памяти и радоваться, как быстро персистируются объекты.

[ko-bx.livejournal.com]

Чушь какая-то. Может есть где-то туча подобных проектов, делающих это большинство, но меня как-то угораздило наблюдать большинство как раз тех, где данные важны (да я вообще не помню проекты, где данные не важны).

Чем ORM не подходит под определение "работа идет строго с базой"? Не понимаю, к чему ты.

[anonim-legion.livejournal.com]

>Хотите -- выкиньте БД и храните всё в текстовых файликах.

Кроссплатформенность - миф, бесшовный переход с базы на базу - тоже. Или оно одинаково медленно будет работать везде.

>да я вообще не помню проекты, где данные не важны
Да тот же Гугл. "Мы ни за что не отвечаем, пропадет что-то - сами виноваты".

[ko-bx.livejournal.com]

> Кроссплатформенность - миф, бесшовный переход с базы на базу - тоже. Или оно одинаково медленно будет работать везде.

Успешно переходил с базы на базу при помощи изменения пары строчек + миграции. По поводу "медленно" не понял, почему оно медленно будет работать.

> Да тот же Гугл. "Мы ни за что не отвечаем, пропадет что-то - сами виноваты".

Ну, одно дело "мы ни за что не отвечаем", другое -- "данные не важны".