THE SQL Server Blog Spot on the Web

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

Browse by Tags

All Tags » Best Practices » Database Design   (RSS)
Showing page 2 of 2 (18 total posts)
  • 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
  • Business Rule Enforcement

    I know this is a topic that could cause a few heads to spin around uncontrollably if taken the wrong way, but I preserve.  Today I was having a conversation with an end user, an influential one at that, about a business rule that was needed for the time entry system we are putting together (and no comments on make/buy decisions, no way I ...
    Posted to Louis Davidson (Weblog) by drsql on February 16, 2009
  • The first pillar – A Coherent Design

    One of the definitions on wiktionary.org 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
  • Inheritance in Database Design

    As I have been walking around Disney World this week, my mind starts to wander to matters of database design. Sad, perhaps, but I will guess that most people who read this blog do the same much the same thing with whatever technology they are good at when they are relaxing also.  It also may actually have helped me come up with an example for ...
    Posted to Louis Davidson (Weblog) by drsql on October 15, 2008
  • Commenting your code

    As I am easing back into real life from writing the book, I am in search of easy targets for blogging.  My boss mentioned this blog over on Jeff Atwood's Coding Horror Blog and it got me thinking about commenting.  His advice is to only comment "why" the code works.  I can't quite agree, because the code he claims to be ...
    Posted to Louis Davidson (Weblog) by drsql on July 30, 2008
Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement