On Wed, Jul 03, 2002 at 05:18:04PM -0500, Michael D. Schleif wrote:
|
| Over the years, I've done sql work on various databases; but, my
| programming expertise lies elsewhere.
|
| Now, I have an opportunity to build a database application for a client
| and I need guidance on good _database_ design.
Plan to throw one away. You will anyway.
(Fred Brooks, The Mythical Man-Month)
I'm not a database guru either, but recently I've had the task of
developing a couple of database-based (web) applications. I've found
that as I worked I got a better grasp of how a RDB works and what I
can do with it (through SQL). When I first started I didn't
understand how to work with the tables. I didn't know about joins or
sub-selects or anything. Now that I do I can actually visualize how
some data will come together.
Work with your data some, try some table layouts, try and visualize
how the data will be used and that will show you how to organize it.
| Since the primary function of this will be scheduling, it would be most
| helpful if such a guide was specific to scheduling, pim's, &c.
|
| What howto's, books, websites, &c. ought I to investigate in preparation
| for this project?
Google. Find everything you can on SQL (that is actually useful) and
learn the ins and outs of it. (well, at least scratch the surface and
start working. learn as you go. it's what I've been doing.)
HTH,
-D
--
You have heard the saying that if you put a thousand monkeys in a room with a
thousand typewriters and waited long enough, eventually you would have a room
full of dead monkeys.
(Scott Adams - The Dilbert principle)
http://dman.ddts.net/~dman/
Attachment:
pgp3h5Z0cXLlo.pgp
Description: PGP signature