On 4/27/07, Ed W <[EMAIL PROTECTED]> wrote: > Hi > > Can I respectfully suggest that you missed the point that David was making? > > Sybase wrote some great DB design books that cover this stuff really > well and no doubt there are other books. But basically:
<snip> In general, the process is similar to what you describe, but I would suggest it is subtly different. This is my understanding having been raised by a math geek and having read as many of Chris Date's shorter papers as I could find. 1) Understand what information the software needs to work. Build a high-level logical model for that information. 2) Build a relational algebra model for that information. This is your base physical model and is highly normalized. 3) Due to implementation issues and limitations of SQL (which is not quite semantically equivalent to relational algebra) some workarounds may need to be applied. However, many of these either a) break semantic clarity or b) break the mathematic model and so should be used sparingly. Summary tables and fields are a good example of workarounds. You are almost certainly correct about orders, invoices, and quotations as being cases of the same object because they are essentially phases of the same document. There are some issues that need to be addressed in doing this merging, but that is the general plan. Personally, I would love to get to the point where we could enforce NOT NULL constraints on most fields. That may not be practical, however. Best Wishes, Chris Travers ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
