Regarding keys – I have stated multiple times in this article that integer primary keys are a useful tool and that I would recommend them in a variety of scenarios. In fact, I even showed the use of a secondary key by using an integer primary key and a unique constraint on the SSN field, just as you suggested.

Regarding CHECK – I am aware that it is not supported in all database engines. As far as I know, it is not supported in MySQL, as already stated in this article. I believe the place for this kind of verification is in the database, in the middleware if applicable, and in the client application. Data integrity is more important to me than ‘portable’ SQL.

I do not appreciate your comment, “Google for ‘database normal form’ and learn something useful”. I do know many useful things. I know how to tie my shoes. I know how to purchase velcro shoes to avoid tying my shoes. I know how to buy sandles to avoid using velcro. I know not to wear socks with sandles (my wife taught me). And I know what database normal forms are.

And finally, notice that this is part 1 of a series of articles. Part 1 is entitled “Constraints”. I intend to write a great deal more that includes many of the topics you have suggested. I do not intend to write about database normalization — it does not fit in with this article’s topic of just-past-basic SQL.

And yes, Oracle certainly does have the dumbest implementation (or lack-thereof) of LIMIT/OFFSET — at least we agree on that.

That’s simply not a useful abstraction – you’re gaining a tiny amount of speed and size (but in some cases actually you lose some, ie with a composite primary key) but you are making development a lot more difficult. You can always add a different type of constraint (like a second key on the SSN/country pair to ensure they remain unique) or you can build this constraint outside of the dbase server. Whatever happends to work nicest.

Moving on, stuff like ‘CHECK’ doesn’t work in all database engines and where it does, notation tends to be different. The nice thing about just making a simple SELECT and doing whatever extra checks you need outside the dbase schema is that you end up with very simple ‘portable’ SQL. For high load huge schemas at some point you will just have to start designing to the strengths of the specific dbase app you are using, or commit to adding a LOT of metadata for some big iron middle layer like Java Hibernate or some such. Once you elect to go middleware these tutorials become effectively pointless.

Google for ‘database normal form’ and learn something useful. Alternatively, talk about basic dbase calculations in the form of SUM and JOIN – both of those, once you grok them, can help really speed up queries significantly, something that using the natural key as primary key never will. Also talk about how you can add indices to speed up selects on those specific fields, and perhaps hint at using the database local variant of TOP/LIMIT, which restricts output to a limited number of fields, just in case you actually just put in a query for an entire (huge) dbase table, freezing up the system for quite a hwile. (unfortunately the exact keyword tends to differ between dbase engines. Extra points for oracle for being the dumbest implementation of that ever. It’s something like WHERE columnid 100 and columnid

I think it’s a good idea to also introduce the concept that data validation often happens at the application level. Perhaps even discuss the pro’s and con’s.

Very nice work.

If you’re building a database for an application and you know what the business rules are go ahead and put in your constraints. If you’re still feeling your way and the busines rules are not really known yet, stay loose – you can always add them in later once the requirements are firm.