Должны ли опытные программисты знать запросы к базе данных? [закрыто]

Есть так много программистов, которые также являются экспертами в написании запросов и проектировании баз данных.

Должно ли это быть основным требованием быть опытным программистом или программистом?

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

То, должно ли написание запроса к базе данных быть основным требованием, зависит от работы, но реляционные базы данных широко распространены в современной технологии.

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

1. Они вообще неопытны.
2. Они высокоспециализированы в другой области (например, встраиваемые системы) и никогда не нуждались в изучении этого.

Запросы к базе данных принципиально отличаются от более стандартных языков программирования. Они алгебраические и предназначены для работы с реляционными данными, в то время как C # или Java являются обязательными и работают с дисками, памятью, пользовательским вводом и т. Д. Даже функциональные языки, такие как LISP или Haskell, которые являются более алгебраическими по форме, менее ориентированы на реляционные данные.

РЕДАКТИРОВАТЬ: Как было отмечено в комментариях меня и других, есть несколько веских причин, по которым опытный разработчик может не знать запросов к базе данных хорошо:

• Их команда использовала ORM / NoSQL
• В их команде были программисты БД
• Сложность приложения заключалась в бизнес-логике, а запросы к БД были тривиальными
• Их команда распределила работу так, что некоторые программисты не писали запросы

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

Таким образом, наиболее опытные разработчики должны знать запросы к базе данных .

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

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

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

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

Если бы у меня был проект с базой данных, специалист по базам данных был бы вторым разработчиком, которого я бы нанял (после разработчика начальных приложений). Базы данных, как правило, не являются одноразовыми, так как через 20 лет данные будут оставаться в том же виде, что и на начальных этапах.

Проекты часто попадают в неприятности, потому что они не нанимают этих людей, пока база данных не содержит 100 000 000 записей и работает медленно. Или они обвиняют инструмент в том, что он плохой (никакой SQL Server не медленный, если вы разрабатываете правильно), а не в своей некомпетентности.

Политически правильный ответ: это зависит. Знание SQL не имеет никакого значения, если разработчик никогда не работает с реляционными базами данных (и в наши дни, и в эпоху приложений NoSQL, это на самом деле вполне вероятно).

Во-вторых, когда есть администратор базы данных или постоянный автор запросов (какой бы ни был заголовок), понимание также имеет меньшее значение.

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

Мое личное мнение: Нет. Опытный разработчик программного обеспечения должен быть в состоянии освоить новый навык (например, SQL), если и когда это необходимо, а не «по умолчанию». Гибкость и способность учиться и понимать - это то, что отличает хорошего разработчика от нормального. Правило «золотого молотка» также применимо - если у вас есть разработчик с обширными знаниями SQL, очень вероятно, что этот разработчик извлечет инструмент, который он знает лучше всего - реляционные базы данных - чтобы попытаться решить каждую проблему, хотя он не обязательно имеет быть лучшим решением. Конечно, это относится и к адвокатам NoSQL,;).

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

Посмотрите это введение в Википедию по компьютерному программированию:

Компьютерное программирование (часто сокращаемое до программирования или кодирования) - это процесс проектирования, написания, тестирования, отладки / устранения неполадок и поддержки исходного кода компьютерных программ. Этот исходный код написан на языке программирования. Цель программирования - создать программу, которая демонстрирует определенное желаемое поведение.

Запросы к базам данных имеют свои языки, они могут быть разработаны, протестированы, отлажены и поддержаны. Целью запроса к базе данных является предоставление вам необходимой информации в соответствии с вашими потребностями.

Так что я думаю, что это программирование, безусловно.

Хороший инженер-программист, имеющий опыт работы в корпоративных и бизнес-приложениях (EDIT: особенно в проектах, использующих СУБД), должен обладать экспертными знаниями по написанию запросов к реляционной базе данных в стандартном формате. Кроме того, они должны уметь понимать сложную схему и предлагать схемы, по крайней мере, средней сложности.

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

Это не значит, что у программистов баз данных тоже нет места. Сложные хранимые процедуры, сложные и эффективные запросы и программный дизайн и архитектура уровня базы данных, ориентированные на уникальные инструменты и предложения одного поставщика баз данных (например, Oracle, MySQL, SQLServer и т. Д.), Лучше всего по возможности оставить профессиональному программному обеспечению. инженеры, которые имеют опыт работы с этими высокоспециализированными и сложными предложениями.

Подавляющее большинство систем для бизнеса и предприятий, однако, на мой взгляд, не оправдывает необходимость в разработчиках данных и специализированных программистах баз данных, но я работал над такими проектами до того, как БОЛЬШОЕ воспользовалось знаниями и опытом, которые эти люди принесли за стол.

Другие уже ответили на ваш вопрос о запросах к базе данных.

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

Место, где я сейчас работаю, имеет тот же дизайн базы данных, что и в 1970 году. Мы переместили базу данных из IDMS в DB2, но это тот же дизайн базы данных сети. У меня была возможность создать 5 новых таблиц DB2 за 9 лет работы здесь.

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

Я искренне удивлен, что многие из нас думают, что каждая разработка вращается вокруг базы данных, и базы данных SQL.

Другие упоминали о многих способах, которыми мы можем избежать тщательности SQL в нашей работе, даже когда мы работаем (косвенно) с базами данных, но как насчет всех разработчиков, которые пишут прошивку для 101 электротехнической продукции, которую мы каждый обладать? А как насчет парней, специализирующихся на мониторинге в реальном времени?

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

Я думаю, вы переоцениваете важность баз данных в программном обеспечении.

Многие классы приложений не ориентированы на базу данных.

Нужна ли нам СУБД в текстовых редакторах и редакторах изображений? Как насчет систем распознавания речи и компьютерного зрения, они содержат много запросов к базе данных?

А как быть с линейными видеоредакторами и физическими движками видеоигр?

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

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

Однако, если этот программист может писать только запросы типа «select * from tblxxxx», я бы не стал считать этого программиста экспертом. Аналогично, если база данных, разработанная этим программистом, помещает отношения один ко многим в одну таблицу вместо двух таблиц, я бы не считал этого программиста экспертом.

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

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

Оглядываясь в нашем отделе, это зависит от:

• Наши разработчики десктопов / веб / серверов . По крайней мере, требуется написать базовые или расширенные заявления о грубости в зависимости от их специальности. Для оптимизации у нас есть несколько специализированных администраторов БД.
• Наши встроенные программисты . Многие из них никогда не проходили мимо «select * from mytable». Однако, это также изменилось за последние несколько месяцев с введением sqllite в их проекты.