Part 1 : Does database modelling matters ?

This article is the part of Does it matter ? series.

Data Modelling is waste of time. Do you agree ?

Most of us must have noticed that data modelling is not given due importance. Application developers are given liberty to create the schema.

When I talk about schema then it refers to DDL statements which includes creating database, tables, indexes etc.

I’ve also noticed, developers who do not have any prior experience of database and data models are told to create the schema. Manager of these developers knows, he/she is simply going to copy and paste the code from google without thinking the pros and cons.

Every Manager/Tech Lead understands the importance of a good database design but most of them occasionally ignores it. When they realize it, the arrow had left the bow. There is very less opportunity to improve the design post Go-Live unless one wishes to have another stabilization project. Isn’t it true?

We can’t blame the developers for this. They are innocent and just following the commands. Management should be matured enough to understand the importance of data modelling. They should make it a must exercise well documented as part of SDLC process.

Do you think cost is saved by ignoring Data Modelling ?

As we all know very well, there are no short-cuts to success. We can reduce the Development time to some extent by ignoring it but that will not justify your achievement as compared to struggle you will face post-production.

You must agree, for every developer, the situation is comparatively in favor during pre-production phase as compared to post-production. I’ve seen people struggling fixing repeated bugs and performance issues as a product of poor database design.

Cost saved on development time becomes compound interest which an organization pays every day by way of loosing customers, internal escalations, more efforts on stablization/support etc.

Investments (time & cost) made in a good architecture and design pays back in terms of less support and maintenance cost.

I must say, don’t ignore Data Modelling !

Your model defines the fate of your database and application. The person defining the model should be visionary and experienced to model your database in such a manner that it can perform in all the situations. Sorry I’ve used word ‘Perform’ because what I have seen, people are more concerned with ‘Survival’.

In my own personal experience, I have observed, people struggling with their database design when they faced performance issue and get change requests.

What to consider for a good database design ?

I’m not going to tell you the best practices for data modelling. There are plenty of nice contents already available over web. But sometimes later, I shall write about it if I get requests to do so from my readers.

You can also checkout my following blogs that should give your some insights.

Best practices for designing tables in SQL Server

Best practices for Stored Procedures in SQL Server

Normalization vs Performance – SQL Server

Decoupling vs Performance – SQL Server

But, I’ll definitely highlight the things to be considered while data modelling.

Followings are few important points that must be taken into consideration for data modelling.

  1. Estimating row size of each table so that data growth can be anticipated for capacity planning;
  2. Maintaining the balance between read and write load;
  3. Flexibility to accept and manage the change requests;
  4. Data archival;
  5. Re-usability;
  6. Performance (Balance of read and write performance);
  7. Data security (Data at rest, data at motion, data masking and access control);
  8. Easy maintenance & support;
  9. Source Code versioning;
  10. Quick debugging;

Carpenters are also a database architect !

You are at liberty to choose your model and I must say there is no golden rule applies to data models. Each use case has its own model. The very same way you will find variety of cupboards. You will find few similarities between different cupboards but not all of them are same. Same way our database is. It’s a cupboard which you have to design based on your own requirements.

Sorry to take you to the cupboards while we are discussing database. But trust me, there are lots of similarities between them. I’ll not compare the similarities between cupboard and database and leave it up to you to relate it and share in the comments (if you wish to).

Stay tuned for the next article on Does it matter ? series.

One thought on “Part 1 : Does database modelling matters ?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s