Есть ли еще необходимость в написании SQL?

Имея так много инструментов ORM для большинства современных языков, есть ли еще вариант использования для написания и выполнения SQL в программе, в языке / среде, которая их поддерживает? Если так, то почему?

Для ясности: я не спрашиваю, нужно ли программистам знать SQL, или мне нужен инструмент SQL на моем рабочем столе. Я спрашиваю конкретно, почему у меня это может быть в коде (или конфигурации, или что-то еще), в отличие от ORM.

• Вам удобнее писать SQL для запроса данных, чем процедурный код.
• Ваш ORM, хотя и красивый на вид, генерирует ужасно медленный SQL в некоторой критической области.
• Вам необходимо воспользоваться функциональностью, предоставляемой вашей СУБД, которая недоступна / недоступна через ORM.
• Каждый раз, когда вы печатаете SELECT * FROM..., Бог убивает котенка. И ты ненавидишь котят.
• Вы не используете ORM, OOP или современный язык.

Написание сложного SQL

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

Короче говоря, SQL, безусловно, необходим, и так будет всегда.

• Просмотры
• Триггеры
• Ограничения
• Пакеты (SSIS, DTS и т. Д.)
• В любое время вам нужно точно контролировать поток выполнения

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

Конечно:

• Обычно ORM много инкапсулирует, но в конце вы должны знать, что происходит за кулисами. Это очень важно для производительности и масштабируемости. Хотя внутри приложения я не пишу так много SQL, но я примерно знаю, как выглядит SQL или DDL.
• Прямой SQL часто удобен для написания запросов только для чтения. Гораздо проще, если сформулировать это на языке запросов ORM, и вы также можете ограничить набор результатов (например, «выбрать идентификатор из .....»).
• ORM вообще не должен держать вас подальше от SQL. Я часто использую SQL для специальных запросов непосредственно на DB-клиенте (например, mysql-client). Это дает вам очень хороший единый интерфейс и функциональные возможности группировки.

ORM существуют из-за несоответствия импеданса между нашими распространенными реализациями реляционных БД и нашими возможностями языка ОО. Они всего лишь мост, но большинство людей относятся к SQL, как сыр Лимбургер в холодильнике.

Если вы с полным основанием можете сказать, что вы всегда будете использовать ORM или другой абстрактный уровень доступа к данным вместо того, чтобы рассматривать SQL / хранимые процедуры / представления в качестве первоклассного интерфейса (ов), то вам, скорее всего, будет лучше, не касаясь SQL.

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

ORM - это инструмент в наборе инструментов для программистов. У них есть свои проблемы. Вот некоторые примеры:

• Не могу контролировать sql
• Страдает от проблемы n + 1

Если вы знаете, что делаете, вы можете эффективно использовать ORM для замены большей части кода типа CRUD. Однако они не так эффективны для сложных вещей, их сложно настраивать на производительность (вы знаете, что производительность является одной из важнейших частей проектирования баз данных, а не эмулировать объекты), и они совершенно ужасны и опасны в руках того, кто не сами не понимаете или не пишите SQL.

Я также хочу отметить, что сложную отчетность сложно легко сделать с помощью ORM. И, кроме того, если вы не изучите простой SQL на материале easy crud, как вы когда-нибудь сможете написать сложный SQL для создания отчетов? Я никогда не работал в приложении, в котором не было необходимости составлять отчеты, и часто это было довольно сложно.

Также ORM не являются полезными для процессов BI или ETL по большей части. Они также не полезны для запросов администратора базы данных или для поиска информации в таблицах аудита и отмены определенного набора изменений базы данных. Есть много вещей, которые по-прежнему наиболее эффективно работают с SQL. Приложение, запрашивающее базу данных, представляет собой небольшую часть того, что необходимо для запроса в корпоративной среде.

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

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

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

Кроме того, при использовании базы данных, такой как Oracle, с очень богатым и мощным языком процедур, вы можете многое сделать, даже не нуждаясь в «программе». PL / SQL на Oracle в правильных руках очень быстро и эффективно.

Если вы хотите использовать базу данных самостоятельно, да. Большинство ORM, которые я пытался использовать, просто были недостаточными или не покрывали мою базу данных. Кроме того, как вы собираетесь устранять неполадки или писать собственные запросы, которые не рассматриваются?

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

Да, вы можете избежать написания SQL. Но вместо этого вы будете писать HQL (или Linq, или DQL ...)!

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

(Но о проблеме N + 1: это связано с отложенной загрузкой, и большинство инструментов ORM имеют некоторый способ запрашивать загружаемую загрузку, таким образом избегая этой конкретной проблемы.)

ORM только доведет вас до некоторой точки. Но бывают случаи, когда вам нужно выполнить действительно сложный запрос со сложными объединениями, подзапросами, объединениями, минусами, аналитическими функциями и т. Д. Именно тогда вам нужен SQL. Но как вы должны писать сложные запросы, когда оставляете все простые запросы в ORM?

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

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

В остальное время вам может не понадобиться SQL для CRUD, но SQL гораздо шире, чем простые SELECT, INSERT, UPDATE и базовые запросы JOIN. Вы можете делать очень умные вещи с этим, и хотя вы можете не использовать их часто, полезно знать, что они есть.

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

Кроме того, конечно, кто-то должен знать достаточно, чтобы написать лучшую систему ORM, если нынешние не слишком хороши. Это помогло бы им, если бы они знали SQL ...

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

Если вам нужно что-то делать с мобильными устройствами и т. Д., Которые не имеют много памяти для работы, где программируемое приложение выполняется как «клиентское» или автономное приложение на мобильном устройстве, планшете и т. Д., Чем такие вещи, как использование SQL, все еще распространены и важны, потому что память на устройстве настолько мала, что вы не можете кэшировать много вещей в памяти.

Сложность и объем написанного мною SQL недостаточны, чтобы сделать перехват ORM разумным.

(Я пишу SQL, может быть, один раз в месяц, если)

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

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

И да, инструментами ORM можно управлять, чтобы делать такие вещи, но я видел места, где они будут принимать только хранимую процедуру (Sql Server) и будут спрашивать вас о том, что вы делаете в ней.

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

Одна важная вещь - DDL и миграция базы данных. Иногда вам нужно вручную сшить эти вещи, чтобы обновить вещи, не ломая существующие данные.