THE SQL Server Blog Spot on the Web

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

Browse by Tags

All Tags » Best Practices » Pillars » Database Design   (RSS)
  • Seventh pillar - Encapsulated

    The final numbered post in this version of my “pillar” series of posts ends in the most contestable part of the design/implementation process.  Encapsulation. The concept of encapsulation is not contested (or even contestable by sane programmers in any field of the art of system creation. Every time you use a Windows API call you are ...
    Posted to Louis Davidson (Weblog) by drsql on October 23, 2009
  • Checkpoint – Four pillars down, Three to Go

    With the previous post on the fourth pillar, I have reached the “end” of the design posts.  To review, these were: Coherent – cohesive, comprehendible, standards based, names/datatypes all make sense, needs little documentation Normal – normalized as much as possible without harming usability/performance (based on testing) ...
    Posted to Louis Davidson (Weblog) by drsql on May 14, 2009
  • The fourth pillar – Documented

    This blog probably won’t stir up a hornet’s nest or anything, but I would also expect that it would be the least popular in practice. The person who feels they can disagree with the need for a reasonable amount of documentation is probably nuts. In the first post, I defined documented as “Anything that cannot be gathered from the previous four is ...
    Posted to Louis Davidson (Weblog) by drsql on April 15, 2009
  • The third pillar – Fundamentally sound

    This one should be simple to anyone who sees it (once I decode what I mean by fundamentally… and sound…by then for sure!) In the initial post I defined this as – fundamental rules enforced such that you don’t have to check datatypes, base domains, relationships, etc.  The gist here is that you at a minimum don’t have to spend all of your time ...
    Posted to Louis Davidson (Weblog) by drsql on April 7, 2009
  • The second pillar - Normal

    The first pillar was easy, since no reasonable person is going to argue that having a design that is not coherent is desirable. No matter what the type of system, any design that isn’t easy to understand is likely to be a bad design (obvious caveats are that it must be understandable to other people of a given level of intelligence in the given ...
    Posted to Louis Davidson (Weblog) by drsql on March 1, 2009
  • The first pillar – A Coherent Design

    One of the definitions on for coherence is “a logical arrangements of parts”. In my initial post, I defined “coherent” for database designs in the following manner: cohesive, comprehendible, standards based, names/datatypes all make sense, needs little documentation.  Both definitions share one specific common theme: ...
    Posted to Louis Davidson (Weblog) by drsql on January 8, 2009
  • The phases of database design

    Before I get started with the pillars of a well built database, I want to reply (in long form) to a comment on the last post. I see the phases of the project to have five distinct phases (again trying to make memorable lists that an stick in your mind): Requirements – The process of extracting what needs to be done from the mind of the people ...
    Posted to Louis Davidson (Weblog) by drsql on December 16, 2008
  • The N pillars of a well built database?

    As I am starting the process of writing my next edition of the database design book (over the next 3+ years) I am starting to try to come up with some catchy way of stating that a database is well designed and implemented.  So I started to think of some metaphor and pillars is the best I could do. Catchy? Dunno, but the idea is that without ...
    Posted to Louis Davidson (Weblog) by drsql on December 9, 2008
Privacy Statement