10

I am a student and I am developing several projects as a part of my academia.

While developing the database for one of the projects, we came across a situation where we thought about whether ERD is necessary or not. Right now, not every one of us are in agreement on developing the ERD first, and then developing database from it.

The majority of people prefers developing the database on the fly verbally according to the system requirementd on paper directly.

Now, I am strict follower of Database principles. I think the database should be developed from the ERD only. So, I just want to know the following:

  • Is the industry following these principles?
  • Am I just wasting my time on developing an ERD?
  • What are the benefits of developing an ERD?
RolandoMySQLDBA
  • 185,223
  • 33
  • 326
  • 536
Ankur Trapasiya
  • 305
  • 1
  • 3
  • 13

5 Answers5

13

Plain and simple, think of developing a database without an ERD as building a house without a building plan. It might be doable because you think that simply laying a brick one over another is enough to build something, however the moment somebody else takes responsibility over the project there is disaster potential.

In my experience you will not benefit much from ERDs unless you use them in conjunction with CASE tools (ERWin, MySQL Workbench etc.) which will additionally allow you to perform some really helpful operations such as forward and reverse engineering. Even without these functions having a centralized schematic of the complete database is useful because sometimes the constraints implemented in the database itself are not enough to tell the full story about the relationships between particular database entities.

Here is an example involving MySQL which, as you might know, implements several internal storage engines, most notably MyISAM and InnoDB. There are significant differences between them one of the most important one being that MyISAM doesn't support constraints. Despite that fact MyISAM is heavily used for web applications which means that the relational logic needs to be implemented either through business logic (application code) or in another way. The problem is when you forward engineer an ERD with MyISAM tables (entities) MySQL will silently ignore the constraints set by the ERD and you will end up with a database which doesn't clearly identify the nature of the relationships between entities. In other words after you develop the database layout there is no way for the code developers to implement proper business logic without an ERD.

5

ERDs are really nice to have a clear picture of your database structure. Besides being an important document artefact to you project, it eases when you need to implement queries, especially joins among tables. Imagine how nice it's to have a dual monitor config, on the left side you have you ERD and on the right side your query editor. You can clearly see the relationships among tables and write your queries based on that. If your database project is quite simple, and your project doesn't require it, maybe it's ok to live without it.

gsb
  • 405
  • 1
  • 4
  • 10
4

ERDs used to be more mainstream some time ago. IMO they are more or less optional now.

Currently, some highly successful teams do not bother with ERDs at all, yet deliver excellent systems: robust, performant, and easy to maintain in the long run. This is especially true in Agile development, when we start small, with a minimalistic set of tools.

ERDs are a good way of communication, of course, but by no means the only way, or the best in all circumstances one. Some teams prefer other ways of documentation and communication.

There are no blanket rules in this industry.

A-K
  • 7,444
  • 3
  • 35
  • 52
3

ERD will save you much more time than you think, If you do everything on the fly then you will stuck when you want to generate junction tables.

If you come across to database a few years later without ERD, you have to spend a lot of time to see what is going on in your project.

I have company and we design ERD, don't ever think about database without ERD.(actually this is my own personal experiment)

Alireza
  • 3,676
  • 10
  • 38
  • 44
2

It's important to design before writing production code. It's also important to prototype; database people develop prototypes by writing SQL. (Remember what Fred Brooks said about prototypes?)

Graphical languages, of which ER is just one, have not proven to be very good at capturing all the semantics of a database in a way that's easy and simple to understand.

They also haven't proven to be very effective communication tools, except between developers. But in designing databases, the crucial communication isn't between developers; it's between developers and domain experts (between developers and business people).

Object-Role Modeling (ORM) has a graphical language, but it's based on "facts" (simple sentences). Business people can validate facts pretty easily. Business people can't easily validate an ER diagram or an ORM diagram.

Mike Sherrill 'Cat Recall'
  • 11,017
  • 1
  • 38
  • 45