This is not what I want.
Most of what it says I’d boil down to.
Mostly be consistent.
Instead, I strongly recommend SQL and Relational Theory, 2nd Edition
How to Write Accurate SQL Code
By C.J. Date
If you want a bullet point style guide, see Date’s “Summary of Recommendations” appendix.
Date’s views are solidly and soundly based in the mathematical underpinnings of logic. ie. You can ignore Date, but while logic is still working (last I checked, it was) violations will be punished, in the corner cases, by illogical results.
If I were to add one thing to Date, it would be create a simple data dictionary.
For every project create a very simple table (column name, column type, description).
Every single time you add a column to any table, see if anything in your dictionary fits (exactly) the type / description, if so use the same name.
Else add your new column name as another row to your dictionary.
Do this religiously, and follow Date’s recommendations, then your SQL statements will simplify by a factor of 10.
Thank you for the book reference - I was previously unaware of Date’s work. For others there is a third edition too: http://shop.oreilly.com/product/0636920046158.do
I read the 2nd edition, so I missed this gem from the 3rd edition appendix on “NoSQL and Relational Theory”.
So what is it that unites these (NoSQL) systems?—what is it that they have in common, to justify
referring to them all by the same blanket label? Mostly, it seems they’re united in what they’re
not. To be specific, they’re obviously not conventional SQL systems, as that term is generally understood.
Unfortunately, however, I would have to say they’re also united in the extensive and
demonstrable lack of understanding of the relational model displayed by their promoters.
I haven’t had time to read the full appendix, but my initial impression is it’s going to be a keeper to refer people who over-hype NoSQL and under-understand Relational.
One thing you might consider adding would be a versioning component to stored procedures and or views. For example if you had a user_select procedure but then added a new column and wanted it available you wouldn’t change that procedure but instead create a user_select_001. This way you dont break or need to alter existing code. Maybe this doesn’t go into a style guide but more of a best practices guide though.
Object oriented design principles do not effectively translate to relational database designs—avoid this pitfall.
I am really curious what the author is thinking of here.
This is classically known as the object-relational impedance mismatch. Wikipedia has a decent primer.