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, such as 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. Their manager knows, he/she is simply going to copy and paste the code from google, without thinking the pros and cons.

We can’t blame the developers for this. They are innocent, and just following the commands. 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 already 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?

Management should be matured enough to understand the importance of data modelling. They should make it a must exercise 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 us, the situation is comparatively in favor during pre-production phase, as compared to post-production. I’ve seen people, struggling to fix repeated bugs and performance issues, as a product of poor database design.

Cost saved on development time becomes compound interest, which an organization pays everyday, 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’ve observed people struggling, with their database design, when they faced performance issue, or when they 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’ll 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. 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. I 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.

• Database Design & Architecture
• SQL Server