Есть несколько способов работать с базой данных при современной разработке, одним способом является использование ORM, другим — использование SQL.
Что такое SQL?
SQL — язык структурированных запросов (structured query language), используется для взаимодействия с базой данных напрямую.
Примеры запросов можно найти здесь
Что такое ORM?
ORM — объектно-реляционная проекция (object-relational mapping), тоже используется для взаимодействия с базой данных, но не напрямую, а через библиотеки, фреймворки или API, которые работают с языком, на котором разрабатывается программа.
Взаимодействие происходит посредством работы с моделями, уже написанных разработчиками. Разработчики придумали, как связать программный код с SQL-запросами, чтобы было удобнее. Теперь есть возможность не учить язык SQL, а работать непосредственно с кодом.
Разница между работой с SQL и ORM примерно такая же, как при работе с отсутствием синтаксического сахара, и с его наличием (на чем, по Вашему, легче писать, на Си или на Питоне, и почему? В Питоне много синтаксического сахара, а в Си его, насколько мне известно, нет.)
Примеры ORM-решений для некоторых языков программирования: Doctrine (PHP); Hibernate (JAVA); SQLAlchemy, Django (PYTHON); Sequalize (TYPESCRIPT).
Пример:
На скриншоте можно увидеть ту самую модель, о которой идет речь.
Теперь, для сравнения, делаются запросы.
На ORM:
На SQL:
Команды выполняются одни и те же, а записаны они по-разному.
Еще раз: при ORM мы общаемся с БД через программный код, а при SQL через SQL-запросы.
Что лучше использовать и почему?
- SQL-запросы работают с базой данных напрямую, а ORM-запросы нет. Поэтому при работе с ORM не обязательно хорошо знать SQL-запросы в деталях, знать их обязательно только тем, кто пишут библиотеки, фреймворки, API — абстракции. Разработчику, достаточно будет просто понимать язык, на котором он пишет.
Если Ваш проект будет небольшим, можно ограничиться знанием ORM, это сэкономит время и оптимизирует работу. - С ORM не нужно знать запросы под определенную базу данных. Существуют разные базы данных: реляционные и не реляционные, а те в свою очередь в каждой из групп подразделяются на отдельные продукты с отдельным синтаксисом.
Если Ваш проект небольшой и при этом в Вашем проекте вы используете несколько баз данных — лучше использовать ORM, тогда не будет необходимости учить синтаксис одновременно, для , например, PostgreSQL, MySQL, SQLite и прочих БД, если это больше не пригодится. - У ORM более высокая производительность на небольших проектах, а у SQL более высокая производительность на больших проектах.
Если все-таки Вы допускаете, что проект будет расти, то стоит выбрать изучение SQL, со временем это пригодится. - У ORM переносимости нет, у SQL переносимость есть.
Поскольку использование ORM — это все равно, что использование специальных библиотек, фреймворков, API заточенных под определенный язык, то при желании переписать программу с языка Python на, например Java, придется переписывать заново абсолютно все команды, поскольку в Java нет фреймворка Django, и интерпретатор ничего не поймет, зато он поймет Hibernate, а Django и Hibernate — это разные фреймворки, которые не обязаны понимать друг друга.
Если Вы допускате, что хотите переехать в обозримом будущем с одного языка на другой, лучше изучите SQL-запросы - Асбтракции — зло , если вы имеете дело с большими проектами.
Абстракции помогают ускорить разработку тем, кому это нужно, а так же позволяют уменьшить порог вхождения в разработку, но со временем приходит понимание того, что важно и нужно знать то, что происходит под капотом, поэтому рано или поздно приходится выходить из зоны комфорта — лучше рано.
Если Ваш проект будет каждый раз расти, лучше изучайте SQL-запросы, так как, во-первых, со временем придется все равно изучить SQL, и получится так, что знание ORM = ORM+SQL, а знание SQL=знание SQL, а во-вторых , гораздо легче будет с отладкой программы. - Полагаться на ORM = Полагаться на третьи лица
Продукт, который Вы используете в качестве вспомогательного — писали не Вы, но раз уж он используется Вами, вы берете на себя ответственность за все уязвимости, которые могут быть в этом фреймворке, поэтому если будет найдена бреш в фреймворке, то она будет и в Вашем продукте, это стоит учитывать.
Если Вы используете сторонние программы в Вашем проекте, будьте готовы к риску. - Присутствие SQL Injection в ORM сведена к минимуму
Поскольку Вам не приходится работать непосредственно с выражениями, гораздо сложнее будет проэксплуатировать уязвимость при наличии таковой.
Если вы боитесь допустить SQLi в Вашем небольшом проекте, лучше используйте ORM. Или же хорошо изучите SQL, в том числе Prepared Statements. - ORM занимается валидацией данных и уменьшает количество мусора, SQL — нет.
Просто приятный бонус - ORM занимается кэшированием данных, а SQL — нет.
Тоже просто еще один приятный бонус от разработчиков ORM. Кэширование — это хорошо, но еще лучше, если оно настроено, как следует.
