what you describe is called 'normalization'; if you'll always only have 20
people in a table it may not be worth it for you - though it's poor practice
to continue to design tables in this fashion. come up with a nice naming
convention and design tables that break contact information such as
Phillip Jackson mailto:[EMAIL PROTECTED]
on Tuesday, February 24, 2004 11:47 AM said:
first of all i'd like to say that my comments below are based upon the
way i understand things to be. i could very well be wrong. so someone
(phillip) correct me if i'm wrong.
what you describe is called
blah blah blah semantics aside;
what i was saying with 20 records is that you wouldn't necessarily find a
performance increase rdbms-side; but you will experience a headache trying
to port your current app over to another schema; unless there's a good
reason for this - leave it. but if you want
Phillip Jackson mailto:[EMAIL PROTECTED]
on Tuesday, February 24, 2004 4:59 PM said:
blah blah blah semantics aside;
you know what's interesting though is that communication, or as you call
it semantics is an important thing. especially when communicating via
the written word.
so if you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
i think if the most accessed fields are much smaller than the hole
thing, you can consider splitting it
whats the average size of your records?
whats the size of the fields you access the most? (check your sql's for
that one...)
amount of records
5 matches
Mail list logo
