github linkedin
Unstructured Thoughts on Database Design
02 February 2020
2 minutes read

Consistency is the (primary) key

Whatever you do, stick to it.

The only thing worse than a bad convention is a good convention, inconsistently applied.

Don’t change your schema in the middle of a huge project because you think you’ve found the next best thing. It hurts a little, but unless you’re willing to make the entire migration, don’t do it.

Don’t bind your schema to the UI

Your job is to create a structure to store the persistent data for your application in an well-structured way. Your job is not to design a structure that matches what is displayed on screen.

First of all, whose interface? Is it your application’s database or is it your application talking to a database? If it’s the former, will that always be true?

Often, the database design will match what’s displayed to the user. This is great. Applications change, and views come and go, and the relationships of the entities may change as a result. A well-considered schema can survive changes on the application-side without issue.

Your database is your data, not your application.

If your application lives or dies a death, it’s still your data.

Use the Database’s Features

Do you think that constraints/triggers/views/procedures are just for show?

Why are database engines developing these features if we should be implementing this in the application layer?

Don’t think don’t-be-evil… think can’t-be-evil

When the bad data finds its way into your database - and it will find it’s way in - You should know what your app is going to do.

Using constraints in such a way as to get a fatal error on the bottom level seems preferential over storing data that doesn’t make sense. That ship has sailed - it’s not like you can recover it anyway.

Back to posts

comments powered by Disqus