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

Question

По моему опыту, это была спорная проблема между "backend" (разработчик базы данных) и "frontend" парнями (разработчик приложений, клиент и сервер).

Было много горячих обсуждений в пабе на эту тему.

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

Answer 5

Хороший вопрос. На самом деле, почему разработчики делают Database Stuff, потому что там, где нет выделенных парней Database, разработчики должны это делать. Но у компании есть Database Guys, также есть разработчики.

:) какова твоя идея?

Answer 6

2 причины:

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

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

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

Answer 7

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

Мои две работы в качестве разработчика были в двух магазинах, которые лучше всего охарактеризовать как крошечные (включая 2 человека, а затем только меня) и крошечные (3 разработчика, кратко четвертый). Я не наблюдал насущных потребностей бизнеса и не работал нигде, у кого были ресурсы, чтобы нанять выделенного парня из БД. Я могу представить некоторые сценарии, где это изменится (включая новую работу: P).

Что касается остального, я согласен с тем, что абстракция также является фактором, и, как разработчики, мы находимся на вершине и вне пределов. Я не могу представить себе разработку веб-приложений без навыков работы с БД, и я рассматриваю Sql / DB Управление должно быть и важным инструментом, и областью, в которой я должен быть острым.

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

Answer 8

По моему опыту, разработчики приложений не делают все вещи базы данных. Рассмотрим всю администрацию, связанную с базой данных, резервными копиями, репликацией и т. Д.

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

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

Answer 9

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

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

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

Answer 10

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