I want to thank *everyone* that sent me a reply on this matter. Trouble
is you guys' messages were so good that I have to study the suckers
first before I know if I need to ask for further clarification. So I
might be back in a couple of days ;) Thanks a bunch, guys! Later
--
-duke
Calgary,
Duke,
Long time no chat. How are you?
Try having a look at this link:
http://www.gslis.utexas.edu/~l384k11w/normover.html
which gets absolutely useless as soon as you hit 3 rd normal form, so
scroll down to the puppies example later in the article, "AnOutline of
Normalization" by Marc Rettig.
Duke,
The best thing is to get a good book on the subject. There is 1st normal
form, 2nd normal formetc. (quite a few).
I would think that 1st normal form should do (i.e. no repeating groups as in
address1, address2...addressN) Look at how the data relates to each other.
The nature of relat
On Sun, Apr 22, 2001 at 01:28:34AM -0500, Phil Jackson wrote:
> Good Point, Richard - sensible normalization - if duplicating a value
> here and there saves you from having to reference 12 tables instead of
> 3, yes, by all means. Also, adapting some standards as to using
> meaningfull names fo
t;<<<<<<<<<
On 4/21/01, 10:10:19 PM, Phil Jackson <[EMAIL PROTECTED]> wrote regarding
Re: [PHP-DB] Designing a database:
> Well to start with, I would examine the nature of the data you want to
> store, it's datatype, size, ect. Follow the other re
Well to start with, I would examine the nature of the data you want to
store, it's datatype, size, ect. Follow the other reccommendations as to
not repeating data
across tables. I tend to use autonumber fields for keys quite often. Also,
think about what data could go into "domain" tables where
thing else if
it appears elsewhere - and don't change it's type!
Phil J.
- Original Message -
From: "Richard Scott Crawford" <[EMAIL PROTECTED]>
To: "Phil Jackson" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, April 22, 2001 1:17
You've gotten some good general instructions here! The design of the
database depends on its intended use -- with more information about the
application, we could give your more specific assistance on the db design.
What's it going to be used for?
How will it be accessed? By motherboard serial
>So if you could give me some tips and pointers for what tables to create
>etc I would be grateful.
You can find a few articles on www.devshed.com about database normalization.
The whole idea is to put every piece of data only once in your database.
And refer to them as an ID. Every ID must be
Designing DB's is an entire domain of study in itself!
However the rules (guidelines rather) I stick by at present but am open
to new ones as I need them,- are:
* Don't repeat data across tables (leads to 'data redundancy' = more
complex to update the DB)
* If in doubt 'put it' in a new table
10 matches
Mail list logo
