THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Louis Davidson

Design Book–Top level outline

The more I teach sessions about database design, the more I realize that two things are true. First, most people don’t dig the normalization stuff as much as I do (some do), and second, people really need the normalization stuff more than they think.

The really hard part is how to flavor the medicine just enough such that it will be read by more people, but no so watered down that it does what it should. In past editions, I have tried to mix a lot of examples, and long examples, in with the basic skills. As a complete read though, I think this works pretty well.  But for myself (whom is in fact my most important reader), I use the book for two things. 

1. A cohesive example that shows how to do the process

2. Learning and reviewing particular skills

I find that the examples are excellent ways to get a handle on the entire process, but rarely do these seem valuable in a reread. In fact, they basically get in the way. What is super useful, even as the writer of the book, is to have the fully searchable ebook to look for certain skills and an example of the skill. For example, on the rare occasion I need to write a trigger from scratch, I whip out the ebook, search for trigger, and bam, I have the basic code I need.

So the current plans are to separate the book into 2 sections, each with 2 minor sections:

  • Modeling The Database
    • Base Skills - Theory, Normalization, Alternative Modeling Techniques (Dimensional), Testing, Table Patterns, Testing
    • Logical/Conceptual Modeling – Several case studies that will use most of the base skills in a manner to show the reader an example of how to put it all together. This section will be the location for the cohesive examples
  • Implementing The Database
    • Techniques for implementing the Model – DDL, including Triggers, Constraints, etc;  Security; Examples
    • Physical Abstraction Optimization – Structures: Database, Table, Index; Concurrency; Datatypes; Data Quality,

Next step is to break down each of the sections into chapters and start a bit of discussion (if in fact, only with myself) about what to put in the main text of the book.

Published Tuesday, November 16, 2010 11:10 PM by drsql
Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Neil Hambly said:

Loius

I'd be happy to provide some input to this, if you are looking for any ?

As I'm also thinking of "1 day" myself authoring a SQL technical book - so very intrested in the process as well as the topic

About me...as an experiecend UK based DB/Dev/DB Architect with 12+ years SQL Server Experience (since 6.5).. think I have a good foundation for this type of activity & discussions

BTW.. I dig normalization and design.. it is key to the overall perfromance of the DB ultimately as we well know

Neil

November 17, 2010 5:42 AM
 

Adam Machanic said:

Have you found a better publisher to work with?

November 17, 2010 10:16 AM
 

drsql said:

Adam, no, gonna work with them again...The horror stories I hear from other publishers arent much better (and sometimes worse) other than the other publisher I work with, but they are a special case doing special titles...

November 17, 2010 10:46 AM
 

Alejandro Mesa said:

Hi Louis,

The plan looks good to me, and I look forward to have the four edition in my bookshelf too.

Quick question for you, why do you think that it will be useful including "dimensional modeling" in the new version of the book?

Personally, I think that "dimensional medeling" is another beast, and differ from most of the principles you teach about the relational model. This could bring confusion to the new readers.

May be you can start playing with the idea of writing a second book, but this one about dimensional modeling.

--

AMB

November 17, 2010 10:47 AM
 

drsql said:

Neil, I am definitely looking for input.  That is pretty much the idea behind the exercise of blogging about writing.  If you see anything you think is missing, dumb, or just a big mistake, I am willing to listen.  It is far more gratifying to get complaints during the writing process than after it (then it just makes you feel bad.

November 17, 2010 10:48 AM
 

Alexander Kuznetsov said:

Louis,

What is your target audience? Are you going to write for beginners? Are you planning to cover agile?

November 17, 2010 1:26 PM
 

drsql said:

Alejandro, Thanks! I kind of was thinking that a concrete example/introduction to dimensional design might be useful for the reader. Not too deep as there are a lot of nifty/interesting patterns that are available (got my intro to that stuff at Kimball's class on dimensional design).  In the first edition I demonstrated a technique for building a reporting database, but dropped it as dimensional has blown up.

I guess the question is, could I create an overview/example or two that would serve as a decent introduction that would demonstrate how to offload reporting to a different location rather than in their OLTP system.

I don't think I will ever want to write a book on dimensional design because I don't t think I could approach Kimball's level.  He seems to do a pretty good job of presenting to the masses, unlike most books that cover normalization and database design to any level.

November 17, 2010 4:06 PM
 

drsql said:

Alex,

The target will be beginner - somewhat advanced database designers (parts of the book are more interesting than others for advanced readers, but much of the techniques should at least be interesting.

Of course, in my mind, to be a beginner data modeler, you should be an intermediate to advanced relational programmer. When you are not advanced enough, you tend to cut corners to solve query concerns that you can visualize done the right way.  

As far as agile, I will likely spend a page or two on project management methodologies, but not too much. My feeling is that you do the same actions for 1 month as 1 year or 10. In all cases you need to have some idea of where you are going in the later steps, but only fully design as much as you can actually implement.  

Any ideas how I might do more with that?

November 17, 2010 4:11 PM
 

Jag said:

Will you be covering patterns for designing OLTPs for read performance? Apart from de-normalization.

Quite often the OLTP db is also used for reporting and Front End searching.

Thanks

November 24, 2010 8:35 AM
 

David R Buckingham said:

Alexander may have been driving at Agile Database Development as opposed to Agile Project Management.  Scott Ambler and Pramod Sadalage are the leading advocates of the database refactoring techniques used in Agile Database Development (www.databaserefactoring.com) if you are unfamiliar with them (though I doubt it).

November 24, 2010 10:45 AM
 

drsql said:

Jag, sort of. I guess I don't 100% know what you mean. A well normalized databsase is usally pretty fast to query just by it's nature. Reporting should be very limited, but searching is a constant issue and assuming you have your columns broken up to their lowest atomic level, you should rarely need to search on part of a column, so indexes will work great (names of people being one of the biggest contra-examples, since you may need to do nickname searches).

Usually the biggest factor is concurrency, and in one of the final sections of the book, I will cover all of this in some detail to make it easier for people to implement concurrent code. Using snapshot isolation level, you can easily make you databases serve both purposes if you must (assuming you have a decent hardware budget), but I still caution people that building even a smallish data warehouse (likely dimensional in nature) will be much faster to work with and far cheaper over the  long haul due to eliminating concurrent access for OLTP and Reporting needs.

November 24, 2010 10:52 AM

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

Links to my other sites

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement