Кто проектирует базы данных в веб-разработке? [закрыто]

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

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

Я понял, что ( ПРАВИЛЬНО ) дизайн базы данных - задача не из легких (я читаю этот 672 пейджер) и может легко стать целой профессией. Тем не менее, поиск вверх и вниз по Интернету привел к удивительно небольшим результатам для тех, кто, как ожидается, справится с этой задачей в контексте веб-разработки.

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

По моему опыту

• Дизайн базы данных - это совместная работа разработчиков и администраторов баз данных.
• Разработчики делают грубые или часто очень хорошие проекты баз данных. Все зависит от опыта программистов.
• Часто разработчики создают таблицы в своей базе данных разработки, и концептуальная модель подвергается обратному проектированию.
• Часто концептуальные диаграммы ER обсуждаются с другими членами команды, часто с клиентами. На этом этапе обнаруживаются очевидные концептуальные ошибки, которые, мы надеемся, выявляются и исправляются.
• Работа администратора баз данных заключается в том, чтобы проанализировать такой дизайн и настроить его для обнаружения нарушений нормальных форм.
• Кроме того, администратор баз данных применяет соглашения об именах таблиц и столбцов.
• Кроме того, администратор базы данных предвидит возможные узкие места в производительности и пытается понять, как будут запрашиваться данные, чтобы впоследствии создать соответствующие индексы.
• Цикл пересмотра / проверки / исправления между разработчиком / разработчиком приложения и администраторами баз данных проходит несколько итераций, пока модель не станет достаточно зрелой для создания физической модели.
• Обычно инструмент проектирования баз данных используется во всех, кроме очень небольших базах данных, чтобы помочь этому процессу.

Нижняя граница:

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

ОБНОВИТЬ:

Существует 3 вида администраторов баз данных:

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

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

Это зависит от того, для чего используется база данных.

Во многих приложениях (веб-приложениях или нет) база данных тесно связана с этим приложением, поскольку она служит для нее постоянным хранилищем. Тогда база данных концептуально является частью приложения, поэтому она спроектирована вместе (и вы предполагаете, что никакая другая программа не получит значительного доступа или обновления этой базы данных). Кстати, постоянство может быть достигнуто с помощью других средств, кроме базы данных, например, простых текстовых файлов, двоичных файлов (в частности, индексированных файлов, таких как GDBM ), git (или других VCS), каталогов или деревьев файлов, разделов сырых дисков, выделенного оборудования (например, вспышка), удаленные файловые системы, чекпойнтингметоды. Для баз данных, разработанных для и с одним приложением, вы должны заботиться об общих шаблонах поиска и обновления и проектировать схему базы данных (и индексировать!) С учетом их.

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

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

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

Я понял, что (ПРАВИЛЬНО) дизайн базы данных - это не маленькая задача ...

Читайте также о NoSQL , базы данных документов , ориентированных на , баз данных ключ-значение , управление знаниями , представления знаний и рассуждений , онтологии , экспертных систем , бизнес - правила приближаются , ERP , CMS . Возможно, рассмотрите возможность использования REDIS , MongoDB и т. Д.