I have a new three hour tutorial called Advanced Databases for Beginners. There were two main reasons why I thought it would be useful to write it.
- I keep coming across databases that were designed by “professionals” who obviously have no idea about good database design practices
- I keep reading articles by the authors of various application frameworks encouraging people to treat the database as a dumb data store and to put all of the clever stuff into the application rather than using the database’s native features for describing data
Both of these are ideas that can only lead to databases that are harder to maintain than they should be. Now, whilst I’m happy to turn up on a client’s site and spend six weeks cleaning up the mess left by a database designer who didn’t understand database design, it would obviously be better for my clients if these mistakes weren’t made in the first place.
Hence this tutorial. It introduces things like referential integrity, normalisation and views to people who didn’t previously know of their existance. It was a struggle to get it down to three hours, there was a lot I had to miss out, so don’t be surprised if it turns into a longer course, a series of articles or even a book over the next few months.
But in the meantime, the slides are available online. I hope they make sense on their own, but if you’re interested in having me give the presentation to you or your company, then please let me know.
So what’s the professional opinion on creating fields for data like email address sizes, for example I have a set of users who register via the internet. Basically 99% of them have an email address of less than 32 chars, and 100% have an email less than 64 chars, but according to RFC the local part can be 64 chars, and the domain part can be 255 chars. Should I just use 64 chars, and notify the users that they were silly to choose such a long email address…?
If you use a VARCHAR column then there’s no problem. You’ll just use the amount of storage that you need.