Re: Database Design Best Practices?

From: Carlos Bromanski <>
Date: Tue, 23 Oct 2001 22:05:22 -0500
Message-ID: <3bd630a1$0$35576$>

Obviously your task is more difficult than just structuring a new database, which is difficult enough. You also have to map an existing hairball of information into a new structure.

If you have a grasp of the relational model, then your experience with "smaller scale DBs" should apply well to this new task. Theory is practical. Theory scales well. What's wrong with the plans you used in the past?

The most difficult part of structuring a database, in my opinion, is not the database theory or the relational model, but defining the business rules. You say you'll be educating your customers as you proceed, so I assume that in the process you'll be refining their expectations and assumptions and getting a better definition of the business rules. But getting clear, precise descriptions from customers can be difficult. And where would you find "best practices" for finding out things that you don't even know to ask about?

And with best regards to Mr. Keller, performance tricks are part of the physical design of a system and they must be separated from business rules and the logical database structure.


"Wolfgang Keller" <> wrote in message
> Mike,
> > Any document templates, processes, what should I take note of, etc
> > would be greatly appreciated. I know the things I will keep track of,
> > but if anyone has experience doing this sort of thing, I would
> > appreciate any advice on what I should keep a detailed record off.
> >
> > Best practices? Doc templates? Ideas? Process? Any help is
> > appreciated. I'd be more than happy to repost my findings to the
> > group as a sort of "summary" of DB design best practices when (if) I
> > get responses.
> >
> maybe this helps - it's a bag of performance tricks ..
> ance/performance.htm
> --
> --------------------------------------------------------------
Received on Wed Oct 24 2001 - 05:05:22 CEST

Original text of this message