ORM
Я всегда интересовался базами данных. И сейчас. И вообще. Вся моя профессиональная и околопрофессиональная деятельность связана с базами данных.
В целом очень сложно представить современное ПО более-менее сложное и без использования БД. Это данность. Под капотом хоть сколько-нибудь не примитивной программы зачастую лежит некое хранилище данных и всё чаще это именно СУБД. Может H2 или SQLite, а бывает и вполне себе серверное что-нибудь
В общем, очень часто используется SQL.
К сожалению подавляющее большинство программистов для общения с базой данных использую какие-то суррогаты вида ORM.
Современные СУБД позволяют автоматизировать многие процессы сами собою. Это их задача, их природа. Они созданы для этого. А их пытаются использовать просто как тупое хранилище.
И именно поэтому появляются различного рода ORM.
Что такое ORM?
ORM — прослойка между базой данных и кодом, который пишет программист, которая позволяет с элементами БД работать в «привычной» манере основного языка или фреймворка.
Так что же не так? А не так вот что.
ORM становится очень быстро «забором» между базой данных и остальным кодом. Очень быстро обнаруживается, что реальные дынные, которые имеются в базе, не соответствуют состояниям объектов.
А ещё, и это в первую очередь, используя ORM, программисты злоупотребляют и не пишут логику базы данных. Почти всегда в таких кодах обнаруживается полное отсутствие хранимых процедур, триггеров, ограничений и прочего, всего того, за счёт чего база данных может поддерживать целостность и согласованность данных. Дальше больше. Если проект не примитивен, если он критичен, почти всегда обнаруживается костылирование функционала, который по определению есть в СУБД, например журнал транзакций.
Просто выбирая путь ORM, многие пренебрегают всем этим. Не следят забазой данных. Костылируют.