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

git, различные фреймворки и библиотеки - О печальном состоянии веб-программирования

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

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

любое разбиение, микросервисы, отдельные репозитории, отдельные библиотеки

«расширяемый код», который увеличивает писанину в несколько раз, а потом все расширяется в совсем другую сторону

orm, контейнеры, обвязки и все что скрывает суть и не дает отлаживать, расширять

Я в своём редакторе гексагональной графики изначально старался сделать формат файла как можно более компактным. И вот выделить до 12 байт на пиксель на цвет + 2 цвета дополнительных меня просто душила жаба. Дополнительные цвета я кодировал числом от 0 до 5 - цветом одного из соседних пикселей. Иногда рядом с пикселем нужного цвета не оказывалось и это решалось «инвертированием», когда наоборот основной цвет берётся из соседних пикселей, а один из дополнительных задаётся явно.

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

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

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

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

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

Объекты конечно сами по себе ненужны

Ну если вам объекты не нужны, то и не удивительно, что ОРМ вам мешает)

выбираться может половина объекта А одновременно с половиной объекта Б

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

данные которые строятся на основе данных нескольких объектов, и реального отображения на классы из кодовой базы не имеют

Если это что-то типа статистики, то никто не мешает для такого использовать запросы мимо ORM.

На данный момент все проблемы не в инструментах, а в людях. Не надо прикручивать всякие парсеры/генераторы и т.д. туда где можно обойтись ORM, не надо тащить ORM туда где 100500 запросов которые в любой момент могут специфически поменяться. Так же не стоит забывать про копипасты, иногда удобнее скопипастить какую-нибудь сложносоставную херобору из уже проверенного и готового проекта, чем заново писать что-то в 100500й раз. Тут нет единого ответа.

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

выбираться может половина объекта А одновременно с половиной объекта Б

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

Ну речь про один запрос.

Если это что-то типа статистики, то никто не мешает для такого использовать запросы мимо ORM.

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

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

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

Какая чушь.

Покажи какой-нить пример кода с GitHub, где есть запросы к базе с таким подходом.

Вот как-раз таки в «системе с сотней таблиц и сложной бизнес-логикой» за ORM бьют ногами.

Я такими сайтами не пользуюсь, еще в Outlook попроси переслать. Если брать простые примеры, в WooCommerce можно расширять сущности на EAV, что намного удобнее чем создание по отдельной таблице-объекту. В 1С есть прикладные объекты конфигурации, которыми можно пользоваться в дополнение к классическим таблицам.

Ну речь про один запрос.

В смысле одним запросом с джоином достать два объекта? Есть ОРМ, которые так умеют.

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

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

В смысле одним запросом с джоином достать два объекта?

Да, а куда запишутся данные которые связывают один объект с другим?

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

Можно ли смешивать две цепи в одном запросе? Я думаю это будет неудобно, и будет мешать переименованию символов если обращаться к ОО-таблице.

Да, а куда запишутся данные которые связывают один объект с другим?

Один будет иметь ссылку на другого. Типа post.author

Можно ли смешивать две цепи в одном запросе?

Все равно не понятно, лучше пример привести.

В чем минус ORM в такой ситуации? Если человек, который его использует, знает теорию БД и SQL, он и используя ORM, напишет эффективный код, при этом легко читаемый

Один будет иметь ссылку на другого. Типа post.author

Ну так если между ними нету ссылки никакой?

То есть ты хочешь выбрать данные из двух таблиц, не связанных между собой, одним запросом?

лол бред душевнобольных пошел.

Если нужно мэпить данные из таблиц на объекты, которые как раз и отрабатываться «сложной бизнес-логикой» то выбор между Active Record и Object Mapper, конечно можно не брать готовый ORM а реализовать собственный.

Да, ну вся суть моих примеров, что невозможно результат перевести просто в объект.

Про «оптимизации» не совсем понял, поэтому переформулирую вопрос и раскажу про «общепринятые» подходы, которые я считаю неверными.

1. Безопасность. На том же лоре в каждой теме про безопасность рекомендуют очень странные меры, которые к безопасности имеют очень отдалённое отношение. К примеру перевешивать порт ssh. Реализовывать всякие port knocking и тп. Использовать ключи вместо паролей. Много таких мер. При ближайшем рассмотрении оказывается, что к безопасности всё это отношения почти не имеет, а удобство порой ощутимо ухудшает.

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

3. Всякие прикольные языки программирования. Хаскель, скала, котлин, C++, зиг, лисп. Много потратил времени на изучение экзотики, не могу сказать, что жалею, разумные мысли в этих языках есть. Но по итогу пишу на Java, Go, C, Python и всем советую. Экзотика - не нужна. К Rust у меня отношение двойственное. C++ из этого списка на самом деле выбивается, язык вполне практичный, но в моём арсенале место не занял, ибо очень сложный, на нём можно писать, только посвятив ему свою карьеру, имхо.

4. Linux по безопасности впереди планеты всей. На самом деле macOS, iOS это самые передовые десктопные операционные системы в плане безопасности. За ними Windows, хотя может и обгоняет где-то макось… Linux ощутимо отстаёт, безопасность на линуксовом десктопе это 80-й год. На 99% линуксовых десктопах даже SELinux не включен, про грамотную настройку не говорю. В итоге в макоси у меня в терминале программа не может получить доступ к паролям сафари, а в линуксе - без проблем. В макоси из коробки фаервол включается одним нажатием в настройках и каждая программа будет требовать разрешения на прослушивание порта, в линуксе докер клал большой и толстый на iptables. Про macOS lockdown mode даже упоминать не хочется… Много такого. Зато мы ssh порт перевешаем, ведь порты просканить это так сложно.

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

У меня были переходы с MariaDB на Postgres в проектах, то что использовался eloquent - сильно помогло. Те самые 5%.

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

Тратить время на прокачку скила работы в Perl и Emacs было ошибкой. Сейчас вместо них Python и Vim (Lazy/Neo/etc).

что невозможно результат перевести просто в объект

Если у тебя ООП, то тебе как раз и нужно переводить в объекты и назад, лол)

Если у кого то ООП то это не приговор это не значит что ООП должен быть и в таблице. К примеру получили такой запрос нормальными запросами без ORM, возможно во что то трансформировали и передали в ООП часть.

Тайловые WM и отказ от мышки на самом деле не поднимают производительность и вообще ни разу не способствуют лёгкой жизни в 99% случаев. KDE с подпилом под себя гораздо удобнее.

Если невозможно результат запроса просто упаковать в объект то ОРМ действительно не нужен. Например я не вижу причин иметь ORM в каком-нибудь сервисе обмена сообщениями типа ЛОРа. И вообще там где не нужен ORM может возникнуть вопрос о нужности использования реляционной базы.

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

получили такой запрос нормальными запросами без ORM, возможно во что то трансформировали и передали в ООП часть.

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

лол бред душевнобольных пошел.

Не лечи меня, я сам доктор.

Если нужно мэпить данные из таблиц на объекты, которые как раз и отрабатываться «сложной бизнес-логикой» то выбор между Active Record и Object Mapper,

Если у тебя доменный объект прямо маппится на объект БД или результат выборки - у тебя не сложная система, возможно объёмная, но не сложная.

Если вся сложная бизнес логика упрятана в БД - в коде ты не управляешь бизнес-логикой и маппинг полей в доменные объекты тем-более ты будешь делать руками.

На самом деле macOS, iOS это самые передовые десктопные операционные системы в плане безопасности

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

И вообще там где не нужен ORM может возникнуть вопрос о нужности использования реляционной базы.

Так реляционная таблица как раз на ООП и не налазит, так что наоборот скорее.

Да мы вроде про другое говорим, зачем мне этот пример? Ну давай придумаю плохой сценарий:

Вот изменили мы возраст пользователя с 18 на 17, потому что он растет взад, а он как был приписан группе Клуб на ЛОРе, так и приписан, зайдет в Клуб и совратится, узнает нехорошие слова, и придет штраф. Потому что объект рассматривался как объект.

а он как был приписан группе Клуб на ЛОРе, так и приписан

Осталось только понять, при чем тут ОРМ)

ультразвуковой увлажнитель воздуха. нахер не нужен, не знаю куда выбросить.

Если у тебя доменный объект прямо маппится на объект БД или результат выборки - у тебя не сложная система, возможно объёмная, но не сложная.

Так вытаскивают не один объект, а граф объектов. В бизнес смысле из реляционных таблиц вытаскивается граф связанных записей.
И разумеется для производительности связанные данные вытаскивается одним запросом избегая lazy loading. Чтоб делать такое без ORM нужно просто исписаться SQL запросами с Join’ами на каждый случай.

Если вся сложная бизнес логика упрятана в БД

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

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

А что плохо, если есть объект пользователь, и он не является отображением таблицы 1 в 1?

Так вытаскивают не один объект, а граф объектов.

Уровень задачи: Показать все подтовары головного раздела (внутри есть еще разделы)

Требуемые ресурсы: Веб-мастер космоспек 15р час

документация это отдельная от кода где все в нормальном виде подано

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

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

А ООП почти и не используется в ОРМ

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

Однако даже в случае с PerlHashRM я считаю что вредно оставаться на уровне таблиц, если появляются однотипные объекты.

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

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

А что плохо, если есть объект пользователь, и он не является отображением таблицы 1 в 1?

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

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

Навесить пересмотр членства в клубе.

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

Не надо. Это не уникальная возможность ORM.

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

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

Показать все подтовары головного раздела (внутри есть еще разделы)

раздел JOIN товары, что SQL, что ORM.

Но тут иерархия разделов, чтоб не делать множество запросов к базе по открытию страницы остается вытянуть вообще все записи и построить иерархию в памяти, а потом запихнуть её в кеш (Что самое верное для инет магазина).
Либо использовать иерархически запросы которые есть не во всех СУБД, в Oracle есть, но они не быстрые. На практике такие иерархии/графы запихивают в таблицы в денормализованном виде (плоско) - /section/sub-section/sub-sub-section/ - как запись в колонке по которой будет выполнятся индексированный поиск.

Вы просто не любите всё русское ООП И ОРМ)

Показать все подтовары головного раздела (внутри есть еще разделы)

Взять готовую реализацию materialized path или nested sets для своей ОRM)

Если для тебя вся ценность ORM в том что бы в Java описать таблицу и построить удобный запрос,

Чтоб не писать свой data mapper, или не писать сотни RAW SQL запросов с Join’ам против самых разных таблиц на все возможные случаи.

Ну если рассматривать между mysql_query(string) и ORM то да.