|
|
Posted by asdf on 01/30/07 04:31
[snip]
>
>
> Well I appreciate the answer, and that sounds fine, except with just 1000
> entries, that's 150,000 records, and thinking about writing the queries to
> get
> the data out and use it makes my head hurt!
>
Not really... it's a simple SQL join - potentially a one-liner to retrieve
all the records. Add a where clause if you need to get just the detail for a
single (or multipe) master record(s), and Bob's Your Uncle. Not so hard,
believe me. If you are using mySQL, then it should be able to handle this
easily. 150,000 records isn't *that* many. I've got db's that handle
*millions* of detail table records with little performance degradation.
> I've never built a table with more than about 30 fields before,
> normalizing
> data usually precludes that, and just naming that many fields becomes a
> lot of
> typing. I guess I could just use a1, a2, a3, etc. Using descriptive names
> for
> this data would require about 16-20 characters each, and that seems a lot
> for
> data that's a single byte!
>
He's right you know :) ... normalising things out usually (but not always)
*enhances* performance, and more important... flexibility. When your
business rules change so that you have to store 151 details, you won't have
to touch the data structure... just add more detail rows. ...a simple
example I know, but designing things properly and flexibly at the outset
saves a lot of headaches later on :)
Hope this helps.
[snip]
Navigation:
[Reply to this message]
|