Database design tips for developers

Some additional thoughts

As a general rule, if the database can do it for you, let the database do it for you. Databases know how to handle data about 453.7 times better than you do. Don’t try to do their job. 

If you ever feel like adding fields ending in 1, 2, 3, etc., don’t. Read up on normalization.

Use the correct data type for a column. Don’t use a number for a boolean or a string for a date.

Strongly consider adding CreatedAt and UpdatedAt timestamp fields to every table. You’ll be surprised at how often you end up being glad that you did. Automate these timestamps with triggers, and they will become useful and painless.

Parameterized stored procedures are your friends. Use them as much as you can.

Your query analyzer is an order of magnitude better at deciding what is the best way to query data than you are.

Beware of booleans. Null turns booleans into quantum states—neither true nor false until someone runs a query. Don’t use a boolean unless you know exactly what null means in that context.

Don’t depend on string values to define state. Use an enumerated value instead, ensuring that the data is never wrong. Don’t let status="bananna" cause an error because someone fat-fingered a field.

I’ve left you with a lot of dos and don’ts here. Again, the most important takeaway is to pick a set of rules and enforce them ruthlessly. Do that today, and you’ll save yourself many headaches down the road. Future you will thank you, believe me.

Donner Music, make your music with gear
Multi-Function Air Blower: Blowing, suction, extraction, and even inflation

Leave a reply

Please enter your comment!
Please enter your name here