LINUX.ORG.RU

Как постичь дзен по отношению к ORM?

 , ,


1

3

Думаю, все мы тут умеем писать SQL-запросы голыми руками. И тем не менее многие из нас при разработке используют или пытаются использовать те или иные библиотеки для ORM или Active Record.

Мы сейчас на работе пишем веб-приложуху на Питоне, и для ORM используем SQLAlchemy. SQLAlchemy была выбрана после того, как оказалось, что по паре критериев наша легаси-база совершенно, видите ли, непригодна для имеющихся абстракций в Django ORM. Ну окей, хорошо, что код всё равно только-только начали переписывать, так что смогли себе позволить быстро переделать написанные модели с Django на SQLAlchemy и дальше работать с ней. Ну окей, освоили её не очень привлекательный синтаксис построения запросов. И вот спустя некоторое время обнаруживаем очередную глухую стену. Специально не буду говорить, какую: я пока ещё не выяснил, возможно ли решить мою задачу средствами SQLAlchemy или нет, и не хочу быть дураком, утверждая, что невозможно.

Но факт в том, что я снова убиваю полдня на войну с грёбаным фреймворком – со штукой, которая должна упрощать написание запросов. Причём убиваю явно на пустом месте, потому что нужный мне запрос я бы уже давно написал руками, ну, разве что лень было перечислять нужные поля в селекте. Причём, как я уже сказал, есть ли свет в конце тоннеля, мне неведомо. Может, через ещё половину рабочего дня я решу проблему и успокоюсь, а может, после ещё целого дня пойму, что SQLAlchemy просто неспособна на нужный мне запрос.

Вопрос знатокам: доколе? Сколько настоящий, правильный, постигший дзен веб-разработки лоровец стал бы терпеть прихоти своего ORM-фреймворка? Выкинул бы в тот же миг, как потребовалось залезть глубже пяти страничек туториала и зубрить хитроспелетения методов вместо того, чтобы SQL в зубы и делом заниматься? Или выкинул бы в тот момент, когда провозился больше дня? Или изначально не стал бы брать, если точно знал (мой случай!), что в приложении будет что-то посложнее, чем простой CRUD без джойнов? Или терпел бы до последнего? Но где оно – последнее, после которого нужно признать, что фреймворк всё только портит?

И насколько (в процентах, в количестве запросов, в попугаях) допустимо мешать в одном проекте ORM-модели с простым SQL-кодом?

В общем, ЛОР, научи уму-разуму. Или подсунь что-нибудь почитать на эту тему. Только не про сам SQL – его-то я знаю на адекватном для конкретно моих задач уровне, – а именно про методологию, про умение выбирать или не выбирать инструменты, чтобы проект не превратился в месиво.

Думаю, все мы тут умеем писать SQL-запросы голыми руками

Плохо думаешь! Я не писал, юзал только ORM. Но как запросы примерно выглядят представляю, производительность какая примерно тоже знаю.

FIL ★★★★ ()
Последнее исправление: FIL (всего исправлений: 2)

Думаю, все мы тут умеем писать SQL-запросы голыми руками

Тут 90% комп включать не умеют, куда им запросы.

наша легаси-база совершенно, видите ли, непригодна для имеющихся абстракций в Django ORM

А мигрировать её не вариант?
Но если не вариант, то нет ничего страшного, джанга это не только орм и без орм она хуже не становится.

Но факт в том, что я снова убиваю полдня на войну с грёбаным фреймворком

Ну, видимо, алхимия тоже не годится под эту вашу базу.

Вопрос знатокам: доколе?

До тех пор пока вы не соберётесь мигрировать базу в подходящий для ORM вид или пока не найдёте подходящий способ взаимодействия с ней. Не раньше.

И насколько (в процентах, в количестве запросов, в попугаях) допустимо мешать в одном проекте ORM-модели с простым SQL-кодом?

На сколько хочешь (лицензия таких ограничений не накладывает).
Но лучше 0%.
Либо пили всё под ORM либо пили всё без ORM вообще. Нет ничего плохого в запросах к базе без ORM, если ты хорошо понимаешь что они и зачем и как работают.
Хотя и в случае ORM тоже стоит понимать что и как там работает, так что значительно сложнее стать не должно, просто эрудиции нужно побольше и из другой области.

Только не про сам SQL – его-то я знаю

А про что?
Про питона?
Про жаннку?
Напиши свои модели с нужными процедурами на чистом эскьюэле и не парься, делов-то.

Goury ★★★★★ ()

Любой фреймворк неудобен, пока к нему не привыкнешь.
Через ещё день ты найдёшь решение, посмотришь на него и подумаешь: «Хм. Необычно. Но вполне логично». Гарантирую это. На 63%.

Stahl ★★☆ ()
Ответ на: комментарий от Goury

Тут 90% комп включать не умеют, куда им запросы.

Ну я всё-таки в Development написал. Хотя забыл, что есть ещё раздел Web-development. Если модераторам угодно, могут переместить.

А мигрировать её не вариант?

Увы, действительно не вариант, пока не перепишем всё полностью, а пока что две системы сосуществуют на одной базе.

Но лучше 0%.
Либо пили всё под ORM либо пили всё без ORM вообще. Нет ничего плохого в запросах к базе без ORM, если ты хорошо понимаешь что они и зачем и как работают.

Вот-вот, именно об этом и хотел узнать мнение. У нас в проекте точно есть один запрос, прямо-таки основообразующий, я его иногда называю The Запрос, который даже если и возможно реализовать на ORMах, проще от этого точно не станет, слишком много там всяких коалесков. Видимо, это должно значить, что ORM нужно выбросить потихонечку.

greatperson ()
Последнее исправление: greatperson (всего исправлений: 1)
Ответ на: комментарий от Stahl

Да. А через ещё месяц найду и у него отсутствующую, но нужную фичу.

Собственно, топик я создал главным образом для того, чтобы продумать план на случай, если SQLAlchemy всё же действительно не справится с задачей ну никак: то ли надо потратить N времени на уход на голые вопросы вообще (ну или переход на что-то совсем минималистичное, без претензий на большее), то ли потратить точно такой же N времени на переход на другой фреймворк. Второй путь не гарантирует от затрат ещё одного N в следующий раз.

greatperson ()
Последнее исправление: greatperson (всего исправлений: 1)
Ответ на: комментарий от greatperson

А что мешает просто написать неудобный запрос руками? Или этот фреймворк в принципе не поддерживает рукописные запросы?
Ну сам посуди — из-за одного «идеологически невписывающегося» запроса менять 100500 других запросов и мигрировать на другой фреймворк? Где гарантия что фреймворк, способный сформировать ВСЕ ваши запросы, вообще существует?

Stahl ★★☆ ()
Ответ на: комментарий от greatperson

Видимо, это должно значить, что ORM нужно выбросить потихонечку

Это изначально значило что ORM и вбрасывать не стоило.

пока не перепишем всё полностью

Ну так и переписывайте потихоньку в непубличной ветке.
Как допереписываете так и мигрируйте, а пока пусть работает как работало — на чистых SQL запросах. Благо сами запросы уже должны быть готовы.

Goury ★★★★★ ()

Пиши ядро не полагаясь на фреймворки. man Clean Architecture

Oxdeadbeef ★★★ ()
Ответ на: комментарий от Stahl

А что мешает просто написать неудобный запрос руками?

Ну вот Goury, как я понял, говорит, что это bad practice. Я сам тоже склоняюсь к тому, что это так. Запрос, написанный руками — это, по-моему, в чём-то аналог какого-нибудь eval() со строчкой кода внутри. Одна такая штука в проекте — и ты уже не можешь верить выдаче Find Usages в своей IDE или спокойно переименовывать что-нибудь в проекте, приходится всё время держать её в уме. А две такие штуки в проекте — и ты уже не сможешь даже точно сказать, две их или три.

Сейчас у меня запрос, написанный руками, один на весь проект. Теперь замаячила перспектива получить второй, и мне как-то не нравится, куда ведёт эта дорожка.

greatperson ()
Последнее исправление: greatperson (всего исправлений: 1)
Ответ на: комментарий от greatperson

Нет, я говорю что bad practice это мешать ORM с запросами.
Пилить без ORM вообще с голыми запросами — нормально.
ORM нужна не для того чтобы тебе было проще или эффективней.
ORM нужна для того чтобы можно было в любой момент выбросить мускуль и переехать хоть на постгрес хоть на монгу.

Goury ★★★★★ ()
Ответ на: комментарий от greatperson

это bad practice

Отлично! А переписывать все остальные запросы на другом фреймворке каждый раз при столкновении с хитрой проблемой это, как я понимаю, офигенная практика?
Либо костыль, либо суета и колоссальный объём бестолковой работы либо просто вкорячь в свой фреймворк отсутствующую функциональность. Ты же про веб говоришь? У вас там обычно всё открыто и с компилированием даже возиться не нужно...

Stahl ★★☆ ()
Ответ на: комментарий от Goury

Как допереписываете так и мигрируйте, а пока пусть работает как работало — на чистых SQL запросах. Благо сами запросы уже должны быть готовы.

К сожалению, то, что оно работает, ещё не значит, что оно работает хоть сколько-нибудь логично. Например, там сейчас стрёмный Java-код делает запрос к одной таблице, получает тыщу строк и для каждой из них делает запрос к ещё какой-то другой таблице в зависимости от того, что получил. И всякие константы в коде вместо справочников в базе. И длится весь процесс хорошо если несколько минут. Я когда пришёл, превратил вот это всё безобразие в один SQL-запрос и шокировал начальника увеличившейся скоростью. Правда, всё равно получается пара секунд, но тут я прям действительно упираюсь в нынешнюю архитектуру. Конечно, после переделывания всё должно летать вообще моментально.

Так вот, подобных удивительных вещей там дофига, и мечты о быстром полном переписывании, чтобы потом внедрить все изменения за один раз — увы, лишь мечты. Поэтому старые фичи работают как есть, а новые (и хорошо переделанные старые) потихонечку, по одной запускаются на новой кодовой базе. Вынужденная мера.

greatperson ()
Ответ на: комментарий от Goury

ORM нужна для того чтобы можно было в любой момент выбросить мускуль и переехать хоть на постгрес хоть на монгу.

Кстати, вот да. У нас такое в планах вряд ли появится.

То есть вводные такие:

  • Проект свой, не для распространения. (Ну то есть мы не вордпресс, и нет нужды в совместимости с любой абстрактной базой.)
  • Юзается постгрес.
  • Как минимум один запрос такой, что на него влом натягивать ORM, даже если это возможно.

То бишь диагноз однозначен — уходить от ORM?

greatperson ()
Ответ на: комментарий от greatperson

Я когда пришёл, превратил вот это всё безобразие в один SQL-запрос

Ну дык запрос-то есть.
Вот и используй его.
А будет ли его питон или ява отправлять — на результат влиять не должно.

старые фичи работают как есть, а новые... ...по одной запускаются на новой кодовой базе

Ну вот новые пили под ORM, если хочется, а старые оставь на чём есть.

Goury ★★★★★ ()

на Питоне, и для ORM используем SQLAlchemy

Я новичок в python/ORM, выбрал peewee.
Так как хитрые извращения можно сделать руками, а синтаксис очень ОО - все эти наследования и перегрузки - всегда можно прикрутить своё в стиле синтаксиса данной ORM.
На SQLAlchemy посмотрел и спросил себя - «чем это лучше голого SQL???»

Shadow ★★★★★ ()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от greatperson

Если есть хороший специалист по постгресу — не надо было и приходить к ORM.
Никаких преимуществ кроме экономии времени на написании запросов оно не даёт и это преимущество относится только к разработке новых инструментов.

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

Goury ★★★★★ ()
Последнее исправление: Goury (всего исправлений: 1)

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

CrossFire ★★★★★ ()
Последнее исправление: CrossFire (всего исправлений: 1)

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

SQL это простая технология (сам язык SQL непростой, но если его знать, то биндинги использовать просто). Но в то же время он требует много времени на написание типичных запросов.

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

Я думаю, что вполне допустимо смешивать SQL и ORM, если первого немного. Выпрыгивать из штанов, пытаясь уместить всё в прокрустово ложе ORM-а не стоит. Если же первого становится много — вероятно что-то не так. Или приложение ваше имеет кривые требования, порождающие нетипичные запросы (скорее всего), или просто ORM под ваш проект использовать не стоит.

Думать, что ORM это просто, точно не стоит. Это сложно.

Legioner ★★★★★ ()
Ответ на: комментарий от Goury

Нееет, ты не понял. Старый код — такой шлак, что весь коллективный разум, включая нетехнарей, одобряет наше полное нежелание в нём копаться. И тем более понимает опасность что-то в нём менять. То есть к нему отношение — «работает — не трогай». Ну или «не трогай — не завоняет». К сожалению, этот код завязан на нынешнюю структуру БД, вплоть до захардкоженных паролей. (Да!! Даааа! Мы не можем сменить пароль к базе, потому что он захардкожен в самых неожиданных местах!) Соответственно, никаким ORM там и не пахнет. Крепко пахнет кое-чем другим. И вот в этих условиях мы начали писать новую реализацию той же самой функциональности на той же самой базе. То, что мы ещё не успели переписать — а такого много — пока работает по-старому, его никто не трогает.

Разумеется, как только мы доделываем какой-то кусок проекта — мы позволяем себе конвертировать старые неадекватные таблицы в новые адекватные, и тогда соответствующий кусок старой версии ломается, но это уже никого не волнует, потому что есть новая. Но это происходит не раньше, чем старый кусок действительно больше не нужен. Поэтому хорошо ли, плохо ли, но очень большая часть самых системообразующих таблиц будет неизменна до тех пор, пока мы не обеспечим в новой версии всё, что нужно. После этого будет рефакторинг и избавление от вынужденно оставленных сейчас рудиментов плохой архитектуры, не раньше. :(

greatperson ()
Ответ на: комментарий от greatperson

Ну вот и вынеси всё что связано с плохой старой версией в модели в виде SQL запросов, а когда всё остальное будет готово — замени эти запросы на что-нибудь более подходящее.
Например на другие SQL запросы.

Goury ★★★★★ ()
Ответ на: комментарий от greatperson

И вот в этих условиях мы начали писать новую реализацию той же самой функциональности на той же самой базе.

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

Iron_Bug ★★★★★ ()

Лучше небольшие костыли, но работающие, чем идеальный, но несуществующий в природе, код.

Deleted ()

ORM изначально подразумевает подход «сверху-вниз» от объектной модели к построению базы данных по ней (сверху вниз). Это он умеет делать автоматически. В обратную сторону он работает хреново.

Потому ты либо выкидаешь (мигрируешь) свою легаси базу так, чтобы работал ORM фреймворк, либо пишешь свой велосипед, который бы работал с твоей базой.

invy ★★★★★ ()
Ответ на: комментарий от Legioner

ORM это сложная технология.

Я бы не сказал, что она какая-то сложная. Сериализовать/десериализовать объект из базы - много ума не надо. Простой ORM велосипед можно написать в несколько сотен строк кода.

invy ★★★★★ ()
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от greatperson

Ну вот Goury, как я понял, говорит, что это bad practice.

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

По теме — ORM значительно облегчает persistence в БД. Но да, бывают моменты когда легче написать сырой запрос. Зачем из-за одного запроса совсем отказываться от ORM? Но вообще, по секрету, SQLAlchemy позволяет любой сырой запрос руками смапить на модельки, это если ты недалек и используешь session.query(Model1, Model2). Когда session.query(Model1.field1, Model2.field2) позволяют минимально зависеть от ORM и максимально сосредоточится на бизнес логике и легко менять хранилища когда припрет.

anonymous ()
Ответ на: комментарий от Iron_Bug

то и базу можно пересмотреть

А выполняться в продакшене, в котором база ещё старая, но новые фичи тоже уже нужны, потому что конкуренты не дремлют, /usr/bin/pushkin будет? Я к тому, что переход с одной версии на другую не получается мгновенным мероприятием. Ну, мог бы получиться, если бы всё это, о чём вы говорите, было бы начато год назад с прицелом на запуск сейчас. Или если бы начальство было согласно ждать год начиная от сейчас. Но на такое мы начальство ещё не убедили. :)

greatperson ()
Ответ на: комментарий от greatperson

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

Iron_Bug ★★★★★ ()
Ответ на: комментарий от Legioner

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

Я видел, как это сделано в 1С. Не думаю, что инженеры, создавшие 1С, неграмотны. Но мне абсолютно не понравилось. Априори заданные константы для времени протухания данных в кеше. Абстракция дырявая, на мой взгляд. В итоге будут тонкие, плавающие ошибки в бизнес-логике.

Версионная БД (в т.ч. постгрес) хороша тем, что она может за свой счёт имитировать и предоставлять тебе в транзакции самосогласованное состояние БД. А с другой стороны, позволяет заметить изменение сразу же, стоит открыть новую транзакцию. Кеширование легко расправляется с обеими этими возможностями: если кеш переживает транзакцию, то и состояние перестаёт быть самосогласованным, и оперативность данных теряется.

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

Короче, я против ОРМ вообще. Правда, скажу, что я им почти никогда и не пользовался. Почему? Потому что я считаю необходимость перехода на другую БД почти никогда не нужной. Приложения, которые я писал, всегда были построены вокруг БД, и массированно применялись хранимые процедуры. Если не закладываться на все возможности конкретной СУБД, первая версия продукта будет выпущена намного позже и будет значительно медленнее работать. Получается что-то типа строительства коммунизма: потом у нас (может быть) всё будет хорошо, зато сейчас будет конкретно плохо. Этот подход имеет право на жизнь, но нужно чётко понимать, зачем ты идёшь на лишения. Обычно идея «перейти на другую СУБД в будущем» абстрактна и ничем не обоснована. Пока это так, любой слой абстракции над СУБД является лишь помехой в работе и ничем иным.

den73 ★★★★★ ()
Ответ на: комментарий от greatperson

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

У вас есть полное описание старого функционала за подписью директора? Кто понесёт ответственность за неправильность описания, когда вы запустите «ваш новый прекрасный код»? Есть ли поэтапность плана внедрения? Предусмотрен ли откат на прежнюю версию на каждом этапе внедрения? Есть ли ресурсы на тестирование? На переобучение? Какую долю кода вы переписали, сколько человеко-лет потратили? Сколько человеко-лет потрачено на старый код?

Тщательно рассмотрите и ответьте себе на каждый из этих вопросов.

Вы (а точнее, ваше начальство) находитесь в большой опасности. До 100% понимания того, что делает ваш текущий код (на уровне функционала хотя бы, не говорю на уровне кода, хотя это тоже желательно), писать что-то новое является смертельным риском. Для вас это может стать крупной неудачей в карьере, а для начальства это может означать прекращение бизнеса.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 3)

Вопрос знатокам: доколе? Сколько настоящий, правильный, постигший дзен веб-разработки лоровец стал бы терпеть прихоти своего ORM-фреймворка?

Постигиший дзэн лоровец в лице вашего покорного слуги начал писать свой ORM задолго до того, как узнал этот термин и потому никаких прихотей фреймфорка не терпел, а затачивал свой фреймворк под свои запросы :)

И насколько (в процентах, в количестве запросов, в попугаях) допустимо мешать в одном проекте ORM-модели с простым SQL-кодом?

Я лет 10, как считаю, что доля SQL-кода должна быть 0%. Идеал не всегда достижим и иногда приходится писать вместо ORM-условий, SQL-условия. Где-то в 0.5% случаев. А вот чтобы чистые SQL-запросы в прикладном коде... Точно не скажу, но лет 5-7, как не писал :)

а именно про методологию, про умение выбирать или не выбирать инструменты, чтобы проект не превратился в месиво.

Мне просто. «Лучше день потратить, да за час долететь». Когда я вижу, что ORM не хватает и возникает желание добавить SQL-запрос, я просто расширяю функционал ORM.

KRoN73 ★★★★★ ()
Ответ на: комментарий от invy

Потому ты либо выкидаешь (мигрируешь) свою легаси базу так, чтобы работал ORM фреймворк, либо пишешь свой велосипед, который бы работал с твоей базой.

А у себя я тупо изначально делал возможность ORM работать с любым древним legacy. Поэтому сейчас много ORM'а работает с базами из конца 1990-х гг. При этом сами модели объектов к структуре таблиц никак не привязаны.

KRoN73 ★★★★★ ()
Ответ на: комментарий от greatperson

Это хорошо, говорит в пользу как вашего начальства, так и предыдущих разработчиков. И резко увеличивает ваши шансы на успех. Берегите их, дружите с ними. См. также мои остальные вопросы.

den73 ★★★★★ ()

Я для себя сформулировал, что для быстрого старта и не таких серьезных проектов ORM удобнее. Автомиграции, события и привязка кода к prePersist, preLoad, композиция (т.е. встраивание одних моделей в другие), генерация типового кода. Тут ORM просто облегчает тебе жизнь.

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

Мешать SQL и ORM не антипаттерн. Ну пусть будет у тебя CRUD на ORM, а запросы/отчеты на SQL, это идеальный вариант. Всё равно у белых людей обычно объекты - это просто DTO, ничего не знающие про базу данных, вся логика запросов в репозиториях. Приложение по сути использует хранилище как черный ящик, а будет там SQL или ORM - кого это волнует?

nguseff ()
Ответ на: комментарий от KRoN73

Сейчас может и умеют, в 2010м я намучался с Hibernate, когда он не хотел работать при явно указанных primary key и foreign key. Я помню тогда нашел проблему - это был баг в нём (нашел в багтреккере описание и воркэраунд).

invy ★★★★★ ()
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от den73

Я видел, как это сделано в 1С. Не думаю, что инженеры, создавшие 1С, неграмотны. Но мне абсолютно не понравилось. Априори заданные константы для времени протухания данных в кеше. Абстракция дырявая, на мой взгляд. В итоге будут тонкие, плавающие ошибки в бизнес-логике.

В нормальном кешировании нет никакого протухания и оно полностью прозрачно для приложения, т.е. невозможно получить устаревшие данные. Если в 1С это не так, значит инженеры таки неграмотны (или руководствовались какими-то своими соображениями). Единственное, где можно заметить кеширование — если менять что-то ручками в БД, тут да, надо сбрасывать все кеши.

Обычно идея «перейти на другую СУБД в будущем» абстрактна и ничем не обоснована.

Согласен. Я скажу больше — если специально не стараться, приложение с ORM точно так же будет прибито к определённой базе. Хотя в случае с ORM перейти таки будет проще, если сильно понадобится.

Пока это так, любой слой абстракции над СУБД является лишь помехой в работе и ничем иным.

Фраза уровня «любой слой абстракции над машинным кодом является лишь помехой в работе и ничем иным». Любой слой абстракции нужен, чтобы что-то упрощать (параллельно усложняя что-то другое).

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

Единственное, где можно заметить кеширование — если менять что-то
ручками в БД

Не понял. Предлагается работать с БД всегда через один коннект к ней? Ведь транзакции не располагают информацией о действиях друг друга. Т.е. без построения специальной системы оповещений (нарушающих логику транзакций) не удастся узнать, какой кеш уже протух, а какой ещё нет.

den73 ★★★★★ ()
Ответ на: комментарий от den73

Не понял. Предлагается работать с БД всегда через один коннект к ней?

Предполагается работать с БД через интерфейс ORM. А коннектов обычно по числу ядер + 2, больше не имеет смысла в нормальной ситуации.

Ведь транзакции не располагают информацией о действиях друг друга. Т.е. без построения специальной системы оповещений (нарушающих логику транзакций) не удастся узнать, какой кеш уже протух, а какой ещё нет.

Не очень понял. В кеше первого уровня хранятся данные (таблица, id) -> (столбцы). Если мы делаем любые изменения, то из кеша удаляются все затронутые id. В рамках текущей транзакции используется кеш второго уровня, т.е. если мы что-то меняем в транзакции, то до коммита оно на кеш первого уровня не влияет.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

Предполагается работать с БД через интерфейс ORM. А коннектов обычно по числу ядер + 2, больше не имеет смысла в нормальной ситуации.

Ну это какое-то... ну нет слов у меня. Т.е., по сути, всё, над чем бились творцы баз данных SQL, и что, собственно и представляет из себя их основную ценность, выбрасывается на помойку. А именно, понятие изолированных параллельных транзакций. Нет, ORM - это не моё. Впрочем, я это уже и раньше знал, а сейчас просто ещё раз проверил.

В кеше первого уровня хранятся данные (таблица, id) -> (столбцы). Если мы делаем любые изменения, то из кеша удаляются все затронутые id.

Если этот кеш хранится на сервере, то для обычной СУБД это особо не нужно. При правильно построенных индексах часто используемые данные находятся в дисковом кеше, и время доступа к ним очень мало. Если же кеш хранится на клиенте, сервер должен собирать от коннектов и рассылать клиентам информацию об устаревании данных в кеше. Как минимум, при этом возникает ещё один показатель производительности, за которым надо следить, а предсказуемость производительности приложения на клиентской стороне сильно снижается. Хотя эта проблема менее значима, чем потеря понятия изолированных транзакций.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Т.е., по сути, всё, над чем бились творцы баз данных SQL, и что, собственно и представляет из себя их основную ценность, выбрасывается на помойку. А именно, понятие изолированных параллельных транзакций.

Это из чего такой вывод следует?

Если этот кеш хранится на сервере, то для обычной СУБД это особо не нужно. При правильно построенных индексах часто используемые данные находятся в дисковом кеше, и время доступа к ним очень мало. Если же кеш хранится на клиенте, сервер должен собирать от коннектов и рассылать клиентам информацию об устаревании данных в кеше. Как минимум, при этом возникает ещё один показатель производительности, за которым надо следить, а предсказуемость производительности приложения на клиентской стороне сильно снижается. Хотя эта проблема менее значима, чем потеря понятия изолированных транзакций.

Один сервер БД, один клиент БД (серверное приложение). Один клиент в смысле один процесс клиентский. Соединений в потоках может быть хоть 10, это ничему не мешает, т.к. кеш первого уровня общий между всеми потоками. Речь идёт о классической трёхзвенной архитектуре: БД-Сервер-Клиент. Если серверов несколько, это уже кластер и тут свои проблемы могут вылазить, но ORM вполне подходит.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)

Как постичь дзен по отношению к ORM?

  • Автоматизация в обмен на простоту реализации, но не автоматизация ради самой автоматизации.
  • Умение извлечь реальную пользу от абстракции, но не абстракция ради next-level абстракции.

Unit of Work (и еще куча паттернов)/Сode Reuse (и еще куча методологий)/etc, вот это всё как-бэ намекает нам...

допустимо мешать в одном проекте ORM-модели с простым SQL-кодом?

Допустимо то, что по вашему мнению на данный момент (с проекцией на обозримое будущее) упростит и сделает вашу разработку эффективнее. Вы можете создать 15 тем на гик-форумах, потом прочитать 15 книг по проектированию, и написать в итоге свою «принципиально новую ORM», а можете сесть и решить вашу задачу «здесь и сейчас». Умение эффективно использовать время и проектировать с учетом экономии его в будущем - и есть дзен.

znenyegvkby ()
Ответ на: комментарий от greatperson

То бишь диагноз однозначен — уходить от ORM?

Диагноз однозначен - лечить юношеский максимализм.

anonymous ()
Ответ на: комментарий от Legioner

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

Т.е. кеш должен быть xa transactional, в остальных случаях - как повезет (что не упадет).

anonymous ()
Ответ на: комментарий от Legioner

Один сервер БД, один клиент БД (серверное приложение). Один клиент в смысле один процесс клиентский.

У вас джавабодишоп головного мозга.

anonymous ()
Ответ на: комментарий от greatperson

Если уходить от ORM это максимализм и так не надо, то как надо?

Для запросов которые легко ложатся на ОРМ - использовать ОРМ. Для запросов которые натягтваются сл скрипом - не натягивать.

anonymous ()

«Вьетнам компьютерной науки»

http://citforum.ck.ua/database/articles/vietnam/

со штукой, которая должна упрощать написание запросов

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

outtaspace ★★★ ()
Ответ на: комментарий от greatperson

Запрос, написанный руками — это, по-моему, в чём-то аналог какого-нибудь eval() со строчкой кода внутри. Одна такая штука в проекте — и ты уже не можешь верить выдаче Find Usages в своей IDE или спокойно переименовывать что-нибудь в проекте, приходится всё время держать её в уме. А две такие штуки в проекте — и ты уже не сможешь даже точно сказать, две их или три.

Заводишь отдельный файл в проекте, в который складируешь и именуешь все raw-запросы. В результате ничего никуда не теряется. Так иногда делают те, кто живёт без ORM.

x3al ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.