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

12

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

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

С. Росс
источник
Может ли ORM обрабатывать динамические запросы? Я знаю, что вы можете изменить предложения where без особых проблем (в большинстве ORM). Но есть ли один, где вы можете изменить весь SQL-оператор на лету? Я знаю несколько случаев, когда это было бы бессильно и где с сырым sql было бы легче иметь дело.
Тони
краткий ответ, ДА.
таращиться

Ответы:

35
  • Вам удобнее писать SQL для запроса данных, чем процедурный код.
  • Ваш ORM, хотя и красивый на вид, генерирует ужасно медленный SQL в некоторой критической области.
  • Вам необходимо воспользоваться функциональностью, предоставляемой вашей СУБД, которая недоступна / недоступна через ORM.
  • Каждый раз, когда вы печатаете SELECT * FROM..., Бог убивает котенка. И ты ненавидишь котят.
  • Вы не используете ORM, OOP или современный язык.
Shog9
источник
8
Все веские причины. Эффективность была бы моим номером один все же. В определенных ситуациях ORM, как вы сказали, генерирует SQL, который можно оптимизировать вручную и точно настроить.
Крис
20
Если я уже знаю, что хочу сказать по-английски, зачем мне писать по-французски и пропустить через черный ящик, который переведет на английский? Я бы скорее написал это красноречиво сам, чем манипулировал французами в надежде на то, что это создаст правильный английский.
Майк М.
8
умри котенок умри !!
Медуза
3
Я говорю по-французски и по-английски. Аналогия очень хорошая: вы можете нести главное сообщение, но тонкие нюансы будут потеряны. Тонкие нюансы иногда более важны, так как они действуют как язык тела для обозначения невысказанных позиций. Я предпочитаю писать SQL.
Кристофер Махан
2
Оставляя в стороне негерметичные абстракции, люди здесь, кажется, забывают, что большинство ORM имеют много преимуществ по сравнению с простыми запросами SQL: кэш первого и второго уровня, ленивая загрузка (с возможностью быстрой загрузки, чтобы избежать проблемы N + 1) и возможность объединения протестировать уровень доступа к данным (переключив СУБД на базу данных в памяти), просто назвать несколько ...
rsenna
15

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

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

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

Темная ночь
источник
1
Я недавно переписал проект сотрудника. Я заменил 9 его C # проектов (которые включали 2 слоя доступа к данным) одним SQL-скриптом в 150 строк. Выполнение проекта (который импортировал данные из SchemaLogic в службу управляемых метаданных SharePoint 2010) теперь занимает 3 минуты вместо 15. Версия SQL настолько быстрее и короче, что даже не кажется смешной.
Муравей
Сто процентов согласен. Для реальных бизнес-приложений для любого крупного учреждения всегда возникают сложные ситуации.
Рик Хендерсон
10
  • Просмотры
  • Триггеры
  • Ограничения
  • Пакеты (SSIS, DTS и т. Д.)
  • В любое время вам нужно точно контролировать поток выполнения

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

Билл
источник
Я согласен, но вопрос в том, нужен ли SQL в моем C # (например) коде, а не в том, нужно ли выполнять работу с БД. ORM будет лежать над большей частью этого материала.
К. Росс
@c. Росс Да, и это, конечно, не частый случай, у меня была причина собрать / изменить / проанализировать все эти вещи с помощью кода в моменты моей карьеры. Если у вас нет причины делать эти вещи в коде, то у вас нет, но я не знаю ORM, который очень хорошо справляется с операциями схемы. Точный контроль потока выполнения является более распространенным случаем для большинства людей, но в некоторых случаях это также не требуется. Вы также правы в том, что ORM может лежать на вершине, и я думаю, что это верно во многих из этих случаев, если вы не измените схему достаточно, чтобы разозлить ORM.
Билл
4

Конечно:

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

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

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

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

Jé Queue
источник
3

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

  • Не могу контролировать sql
  • Страдает от проблемы n + 1
Тони
источник
2
Что такое «проблема N + 1»? Я не знаком ...
RationalGeek
Я думаю, что это так: stackoverflow.com/questions/97197/…
Axe
2
Не уверен, что я согласен. Хороший ORM должен позволять вам выполнять необработанный SQL при необходимости, а проблемы N + 1, как правило, являются ошибками новичка (например, вложенные циклы над загруженными лентами), которых можно легко избежать.
Ричейм
@richeym: Те, где первые вещи, которые всплыли в моей голове. У другого ответа есть моя спина все же. Дело в том, что ORM - это всего лишь инструмент, в некоторых случаях предпочтительнее использовать raw sql.
Тони
3

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

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

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

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

оборота HLGEM
источник
2

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

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

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

MDV2000
источник
1
PL / SLQ означает «процедурный язык / язык структурированных запросов», так почему же это не «программа»?
Кристофер Махан
Кристофер Махан: Точно. Основной продукт компании, в которой я работал, состоит примерно в 5 раз больше кода PL / SQL, чем Java Code (LOC).
user281377
0

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

Джонни
источник
0

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

TMN
источник
0

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

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

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

rsenna
источник
0

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

user281377
источник
0

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

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

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

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

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

оборота Гленатрон
источник
Точно: написав механизмы отчетности и модные отчеты из среды хранилища данных Oracle, я могу решительно сказать вам, что знание SQL - это не то же самое, что умение использовать ORM.
Кристофер Махан
0

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

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

programmx10
источник
2
«Любое крупномасштабное приложение должно использовать слой постоянства памяти (в ОЗУ), который должен быть частями кэширования памяти в БД, которые часто используются». - Любая приличная база данных тоже будет этим заниматься.
Мэтью Фредерик
Android и iPhoneOS используют SQLite, совместимую с SQL-92 систему баз данных. Смотрите stackoverflow.com/questions/2011724/…
Кристофер Махан
0

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

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

Пол Натан
источник
0

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

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

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

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

Ozz
источник
Я полагаю, что администратор БД, который беспокоится о разработчике, использующем ORM, похож на разработчика, который беспокоится об аналитике / менеджере / клиенте, имеющем инструмент, который позволяет им писать код!
gbjbaanb
0

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

Уайетт Барнетт
источник