Это работа программистов для разработки базы данных?

Я был программистом в течение последних шести лет. На протяжении всей своей карьеры я работал над многими веб-приложениями.

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

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

Разве это не в интересах приложения и компании, чтобы сделать это экспертом?

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

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

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

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

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

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

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

Программисту выгодно делать это (меньше людей), предполагая, что программист знает, что он делает. Конечно, есть тысячи неудач, на которые можно указать.

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

Кроме того, если вы посмотрите на Entity Framework Code-first, то это предполагает, что та же мысль, что и при построении низкоуровневой модели данных, приведет к созданию разумной схемы или, по крайней мере, намека на одну из них.

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

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

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

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

С учетом вышесказанного, особенно для больших приложений, жизненно важно правильно настроить базу данных в первый раз (схема, индексирование и т. Д.). Если у компании есть доступ к квалифицированному администратору базы данных, эта задача должна упасть на их тарелку; в общем они будут более квалифицированными. Потенциально необходимо провести обзор / обсуждение с ведущим разработчиком, который будет работать с базой данных на стороне клиента и работать с ней, чтобы не было никаких неожиданностей. Если нет DBA, программист проектирует базу данных.

Я вижу два вопроса здесь:

• Должны ли разработчики баз данных моделировать бизнес-логику?
• Должен ли я знать, как сохранить данные в базе данных?

Бизнес Логика

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

• Вы всегда можете заменить одну базу данных другой или даже решить использовать решения NoSQL для решения потенциальных проблем с производительностью.

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

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

Постоянные данные

• Вы должны знать, как сохранять данные на разных носителях, включая решения SQL и NoSQL.

• Уровень требуемой квалификации зависит от размера системы, над которой вы работаете.

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

Обобщить:

• Доменная модель - это основа вашей системы, а не базы данных.

• Если вы работаете в небольшой компании над сравнительно небольшим проектом, вам, вероятно, следует разработать базу данных самостоятельно.

• Если вы работаете в крупной компании в корпоративной системе, то, вероятно, имеет смысл передать работу экспертам по предметной области.