Я понимаю запросы и синтаксис SQL из-за предыдущей работы с веб-формами и хранимыми процедурами ASP.NET, но я бы не стал называть себя «экспертом» в этом.
Поскольку я использую ASP.NET MVC и LinqToSql, кажется, что большая часть тяжелой работы сделана за меня и инкапсулирована в конце SQL, что я сомневаюсь, есть ли какая-то польза от продолжения пополнения моих знаний о SQL-запросы, или мне лучше сосредоточить свое «время обучения» на других вещах.
Твои мысли?
Вы должны абсолютно точно знать SQL и поддерживать свои знания в актуальном состоянии. ORM разработан, чтобы облегчить боль от выполнения чего-то утомительного, что вы знаете, так же, как графический калькулятор предназначен для того, чтобы делать то, что вы можете делать вручную (и должны знать, как).
В тот момент, когда вы позволяете ORM выполнять в базе данных действия, которые вы не полностью понимаете, - это минута, когда вы теряете контроль над своей моделью.
На мой взгляд, знание SQL более ценно, чем любая технология конкретного производителя. Всегда будут случаи, когда эти хорошо подготовленные фреймворки не смогут решить конкретную ситуацию, и потребуются знания продвинутого SQL.
По-прежнему важно изучить SQL-запросы / синтаксис. Причина в том, что вам нужно хотя бы понимать, как Linq to SQL транслируется в базу данных за кулисами.
Это поможет вам, когда вы обнаружите проблемы, например, что-то не обновляется правильно. Или производительность запроса должна увеличиться.
Это то же самое, что вам нужно понять, что такое ассемблер и как он в конечном итоге становится машинным. Однако не обязательно быть экспертом, но, по крайней мере, уметь писать и понимать.
По-прежнему важно знать SQL и стоящую за ним парадигму (основанную на множестве), чтобы иметь возможность создавать эффективные операторы SQL, даже если вы используете LinqToSql или любое другое OR / M.
Всегда будут ситуации, когда вы захотите написать запрос на собственном SQL, потому что его невозможно записать в LinqToSql / HQL / что угодно, или LinqToSql просто не сможет сгенерировать для него эффективный запрос.
Всегда будут ситуации, когда вы захотите выполнить специальный запрос к базе данных с использованием собственного sql и т. Д.
Я думаю, что LinqToSQL (или другие поставщики Linq to SQL) не должны мешать вам знать SQL.
Если ваш запрос не возвращает то, что вы ожидаете, или когда для выполнения в производственной базе данных требуется 30 минут, вам лучше понять, что сгенерировано LTS и почему он дает сбой.
Я знаю, это переработанная тема, и она может быть неприменима к тому, что вы делаете («маленькая» база данных, которая никогда не столкнется с подобными проблемами и т. Д.), Но иногда стоит не слишком упускать из виду уровни абстракции.
Другая причина в том, что Linq не предоставляет весь спектр того, что вы можете делать в SQL, поэтому вам, возможно, придется прибегнуть к написанию «сырого» SQL, даже если результат материализуется в виде объектов.
Это зависит от того, над чем вы работаете, и от того, что вы сказали, может иметь смысл сосредоточиться на других областях.
Сказав, что я считаю, что знание SQL позволяет следующее:
Большинство из них больше помогают в более сложных системах, поэтому, если вы не работаете над ними, это может быть не так уж и полезно.
В вашей ситуации может помочь перечислить технологии, которые могут быть полезны, и затем определить их приоритетность.
Чтобы слова составили план развития для себя, который может включать в себя больше, чем просто изучение технических знаний, но позволяет более широкую направленность, например шаблоны проектирования, коммуникативные навыки и другие области.
SQL - это инструмент. Linq to SQL также является инструментом. Иметь больше инструментов на поясе - это хорошо. Это даст вам больше возможностей при решении проблемы.
Рассмотрим сценарий, в котором вы можете выполнить несколько запросов или несколько обновлений базы данных за одну операцию. Если вы можете написать TSQL, вы потенциально можете сэкономить много обращений к базе данных.
Я бы сказал, что вам определенно нужно знать свой SQL глубоко, потому что вам нужно знать, какой код генерирует ваше Linq-выражение и какие эффекты будет иметь код, если вам нужны высокопроизводительные запросы. Конечно, в большинстве случаев вы можете выполнить свою работу, но иногда есть огромная разница в производительности из-за очень тонкой разницы в синтаксисе Linq.
Я столкнулся с этим сегодня утром, где я сделал .Any (d => d.Id == (...). First (). Id) вместо того, чтобы делать where (...). Any (i => i.Id == d.Id). В результате запрос выполнялся в пять раз медленнее.
Иногда вам нужно проанализировать фактический Sql-запрос, чтобы понять, какие ошибки вы делаете.
Всегда полезно изучить базовый язык для таких вещей, как Linq To SQL. SQL в значительной степени стандартизирован и поможет вам понять новую парадигму программирования.
Рано или поздно вы столкнетесь с проблемами, для решения которых потребуется хотя бы практическое знание SQL. И рано или поздно вы столкнетесь с требованиями, которые лучше всего реализуются в БД (будь то в SP, в триггерах, представлениях или в другом месте).
LINQ To SQL будет работать только с .NET. ЕСЛИ вы получите другую работу, на которой вы не работаете с .NET, вам придется вернуться к написанию хранимых процедур.
Знание SQL также даст вам лучшее понимание того, как работает сервер, а также, возможно, сделает вас лучшим дизайнером базы данных.
