I completely agree (again)! At the least, draw an E-R diagram
(entity/relationship) diagram. All your business logic must fit into that
diagram. It's okay to deviate from database form (such as 3NF), but in
general, you should try your hardest to fit your requirements into a schema
that doesn't allow duplication. If you can't simulate your program/business
logic from that ER diagram, like Mary said, your coding will turn into a
mess. And once you're in production, with live data, you won't want to
start dropping/recreating tables and constraints!
Also, make sure you're consistant with your object names... for example,
don't use a primary key of "OrderID" in one table while calling it "OID" in
another table- use "OrderID" for both. This especially helps for those
"automatic" mapping programs, such as Crystal Reports. (I believe VS.NET
does something similar in Visio?)
99.9% of my experience is with Oracle, and rather than rely on Oracle's
Enterprise Manager to design a database, I always write up SQL scripts. The
benefit is that I only have to write (and document) the script once for my
development server- when I'm ready to move to production, I just run the
exact same SQL scripts on the production rdbms. I believe that the SQL
Server equivilant of Oracle's SQL*Plus is Transact-SQL.
-Thomas
Mary Chipman said:
Database design is the most important part of the application -- get
that wrong and nothing you do on the coding end will make any
difference. I'd recommend Mike Hernandez book, Database Design for
[..snip..]
--Mary
Hi thanks for the information. Kind of new to database design so hoping
to start using the Enterprise manager soon. Also not sure what query
optimization is? It would be nice to be able to step through stored
procedures as well which I have not been able to do when running a .NET
application that calls the procedure.