More Database Design Mistakes To Avoid
Architecture Mistakes to Avoid
The saying goes, a picture is worth a thousand words.
If an organization has a good database model, with meaningful table and field names, a look at the model should give you a pretty good idea what the system does.
Like a picture, when you look at a model, it’s supposed to communicate. Consider a model car, or airplane, or a scale model of building.
Without a model or picture, can you communicate how to build the special research car, XOF1? How it runs? Or what it looks like?
Similarly, can you look at an ERD (Entity Relationship Diagram) diagram your of database, and have a pretty good idea of the system does? Or not?
At so many places, I’ve have to look in many places to understand the system.
– Many queries to the Oracle Data dictionary
– Values in database fields.
– Rows in database tables.
– Extensive data analysis.
– Requirements documents, that don’t give any specifications, most always outdated.
– Lots and lots of source code; triggers, external programs
– Documentation for the middle tier.
– Directories on file systems.
– Files, including parameter, or initialization files.
– Error logs.
– Scheduling systems.
– Perl scripts.
– Someone else’s head.
– Once I even had to poke through source code, line by line, as the program ran, with a debugger!
Sometimes you will see a Visio diagram of the servers and the network. And that’s great for the networking folks, and some DBAs. And sometimes there might even be a process flow diagram, at the big picture, without the actual names of any programs.
But neither Visio or process flow diagrams detail database tables. Database tables and fields are what a database architect or developer is concerned with. Eventually, everything boils down to a table, a field, and a value.
At so many places, I’ve had to look everywhere, EXCEPT at the database model!
And not coincidentally, in most places I’ve worked, there was no ERD diagram to be had in the office. Sometimes, the reason given was the cost of ERD software. Although, there are some very inexpensive data modeling tools out there.
Even if there had been a modeling tool to show all the tables, at so many places, I would have still had to look in the other areas.
The database design was simply not thought about in any meaningful way.
The DB design was so bad, the database “model” really didn’t tell me anything.
It is what I call, the “meaningless model”.