LINUX.ORG.RU
ФорумTalks

Поделитесь мнением про оптимизации и подходы, которые вам никогда не пригодились или оказались ложными/вредными

 ,


0

4

Допустим, для примера: есть адепты использования ORM, которые топят за ORM потому что он умеет поддерживать множество диалектов баз данных. Но в 95% случаев это не нужно.

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

Расскажите про ваши откровения из своего опыта.


Ответ на: комментарий от asdpm

Вы еще не обсохли, а опять что-то пытаетесь привлечь мое внимание. А все уже, все, а надо было раньше (с).

Я с обоссышами не общаюсь и не теряю время читая их простыни. Оправдаться и вернуть взад свою репутацию не получиться. Чао, буратино.

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

Ладно, а что там с переносимостью на другой ЯП? Нинужно?

Подождите, причем тут другой ЯП? Мы обсуждаем переносимость между разными БД одного и того же кода, написанного с использованием ORM.

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

У вас аргументы закончились или что?

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

Ну пусть проверяют и на клиенте, я не возражаю. Только это не повод тащить мегакомбайн ORM.

Тут дело немного в другом. Вот ты говоришь, тогда надо оттуда из ORM взять некую защиту (выдуманный валидатор, видимо санитайзер) и только ее принести. Это ошибочно. Если оно fixable таким способом, то это баг который fixable в «драйвере» доступа к БД.

Если в библиотеке есть horrible баг, который fixable якобы неким «ORM валидатором», но он при этом не фиксится долгое время, то от использования такой библиотеки нужно просто отказаться, т.к. это что-то кривое и заброшенное. Если есть настройки, режимы в которых проявляется какое-то бажное поведение и оно не фиксится, то оно авторами объявляется небезопасным и неподдерживаемым, то есть вы в своем коде должны отказаться от такого способа использования.

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

Если например в psycopg что-то такое будет, то это будет исправлено в самом psycopg или такое использование будет объявлено строго нерекомендуемым и не поддерживаемым (и скорее всего оправданно). Корректным ответом никогда не будет использование какого-то там ORM валидатора поверх psycopg. Это четкое разделение.

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

Зато можно быстро напрототипировать CRUD, который будет непригоден для прода из-за N+1 problem.

Ничо, и так сойдёт! Или же расчехляются костыли, и начинается адова отладка с глубоким погружением в реляционную модель, которую хотели так красиво обойти.

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

У тебя есть ответы на Поделитесь мнением про оптимизации и подходы, которые вам никогда не пригодились или оказались ложными/вредными (комментарий) ? Или ты на своем трейни уровне даже осознать этих реальных задач не можешь? Там ведь от себя требуется свои заявления про ORM обосновать.

за 150 баксов отсосать готов был

Где подтверждения вот этого конкретно твоего заявления клоун? Тебе обидно что ты обосрался и теперь кидаешься?

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

Подождите, причем тут другой ЯП? Мы обсуждаем переносимость между разными БД одного и того же кода, написанного с использованием ORM.

А я хочу на другой ЯП перенести бэкенд, потому что пхп не вытягивает (или его закопали). Что делать? Переписываем всё с нуля. А без ORM можно было запросы переиспользовать. Таким образом, ORM ухудшает переносимость.

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

оносительно дискуссии, я правильно понял, что ты расписался в собственной некомпетентности и признал свой позор?

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

А я хочу на другой ЯП перенести бэкенд

А я хочу банан.

А без ORM можно было запросы переиспользовать. Таким образом, ORM ухудшает переносимость.

Переиспользуйте SQL-запросы при переносе с PHP в, например, Java (jdbc). Пробуйте. Только символами @ не поперхнитесь.

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

Ты понимаешь, что опозорился предельно сейчас?

  1. Ты некомпетентен в элементарных вопросах, как в sql-injection

  2. Ты порол чепуху, вдруг почему-то решил требовать каких-то кодов: чтобы тебя клоуна научили элементарным вещам

  3. Когда тебе стали пояснять что ты неправ - ты перешел на мочеполовые кукареки

  4. Когда тебя в эту чепуху ткнули носом ты пошел по кругу

Тяжело признавать реальность? Мания величия мешает?

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

О да, господин Фрилансер, ваше величие очевидно! Можете онанировать.

я уже много лет на обычной работе, до фриланса тоже был на обычной работе много лет

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

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

обоссышами не общаюсь и не теряю время читая их простыни

Так от тебя требуется публично извиниться за свою чепуху и враньё.

Общаться не требуется, для меня ты списанный клоун.

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

Господа, я уже пуст. Пойду чай попью, если кто хочет - подмените. Персонажу мало жидкости.

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

Да читал я твой топик. В ИТ ты с 2019го

Работаю программистом с 2005 года официально, а ты просто не умеешь читать и поэтому, скорее всего никем не работаешь.

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

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

Написаного не разпишешь, чувак, успокойся

Еще раз, я работаю программистом с 2005 года официально.

Покажи где написано другое или извинись.

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

Извините дядя фрилансер, не тыкайте в меня ничем, можно я домой пойду?

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

Вот здесь доводы против твоих быдлокодерских заявлений:

Поделитесь мнением про оптимизации и подходы, которые вам никогда не пригодились или оказались ложными/вредными (комментарий)

Ты чем-то возразить можешь или признаешь свою неправоту?

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

который будет непригоден для прода из-за N+1 problem

N+1 это проблема только для синхронного кода. Но если ты пишешь синхронный код в 2025 то у тебя проблема куда бОльшего масштаба.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

N+1 это проблема и для асинхронного кода, потому что накладные расходы на один запрос возвращающий много строк обычно ниже, чем на кучу запросов. Ты саму СУБД (и потенциально её диск) и сеть нагружаешь лишней работой и даёшь меньше пространства для оптимизации плана запроса.

Как ты потом считываешь результаты - синхронно или асинхронно - непринципиально.

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 2)
Ответ на: комментарий от no-such-file

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

чушь не болтай, писать не-асинк-авейт код вполне можно и нужно, если мы не про js

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

asdpm
()
Ответ на: комментарий от no-such-file

N+1 это проблема только для синхронного кода.

с чего бы вдруг? поясни пожалуйста

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

произвольному набору полей

тут тоже можно использоватать квотирующие (эскейпающие) функции в сочетании с плейсходерами

https://www.psycopg.org/psycopg3/docs/api/sql.html

для psycopg2:

https://www.psycopg.org/docs/extensions.html#psycopg2.extensions.quote_ident

https://www.psycopg.org/docs/faq.html#faq-identifier

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

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

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

даёшь меньше пространства для оптимизации плана запроса

Строго наоборот. Гораздо проще оптимизировать 100500 тупых независимых запросов, чем 1 убернавороченый кусок макаронного говна. В т.ч. и внутри БД.

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

А есть какие-нибудь замеры производительности по этому поводу?

ugoday ★★★★★
()

Попытки писать вместо конкретных максимально абстрактные вещи для «когда-нибудь пригодится» (код «в стол»)

ООП (то, которое в С++, а не то которое якобы какое-то там правильное из Smalltalk) - урон от тупака про «абстрагирование, инкапусляция, полиморфизм, наследование, блаблабла» не меньше чем от Cobol и BASIC в своё время

Отдельно вынесу попытки делать красивую стройную иерархию классов, вдохновлённую, кроме плохих книжек, фактом того, что браузер их иерархий был встроен Borland C++ 5.x

ahdenchik
()
Последнее исправление: ahdenchik (всего исправлений: 1)
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)