Важность ER диаграмм

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

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

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

Теперь я неукоснительно следую принципам базы данных. Я думаю, что база данных должна быть разработана только из ERD. Итак, я просто хочу знать следующее:

• Соблюдает ли отрасль эти принципы?
• Я просто трачу свое время на разработку ERD?
• Каковы преимущества разработки ERD?

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

По моему опыту, вы не получите большой пользы от ERD, если не будете использовать их вместе с инструментами CASE (ERWin, MySQL Workbench и т. Д.), Которые дополнительно позволят вам выполнять некоторые действительно полезные операции, такие как прямое и обратное проектирование. Даже без этих функций полезно иметь централизованную схему всей базы данных, потому что иногда ограничений, реализованных в самой базе данных, недостаточно для того, чтобы рассказать полную историю об отношениях между конкретными объектами базы данных.

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

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

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

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

У меня есть компания, и мы разрабатываем ERD, никогда не думайте о базе данных без ERD (на самом деле это мой личный эксперимент)

Раньше ERD были более популярными. ИМО они сейчас более или менее опциональны.

В настоящее время некоторые очень успешные команды вообще не беспокоятся о ERD, но предоставляют отличные системы: надежные, производительные и простые в обслуживании в долгосрочной перспективе. Это особенно верно в Agile разработке, когда мы начинаем с малого, с минималистичным набором инструментов.

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

В этой отрасли нет общих правил.

Важно разработать дизайн перед написанием производственного кода. Также важно создавать прототипы; базы данных люди разрабатывают прототипы, написав SQL. (Помните, что Фред Брукс сказал о прототипах?)

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

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

Object-Role Modeling (ORM) имеет графический язык, но он основан на «фактах» (простых предложениях). Деловые люди могут легко проверить факты. Деловые люди не могут легко проверить диаграмму ER или диаграмму ORM.