CF'ers
Thank you all for your fast posts! Thats what I was thinking but it's
always nice to hear it from others!
Have a great weekend!
Regards,
JB
Mosh Teitelbaum wrote:
>Separate tables, because you should be relating those tables to your "main"
>tables in the DB. For example, for a user da
If it's not related to other information in the database and don't change,
I'd put them into a file (CFM, TXT, XML, whatver) and then cache them in the
APPLICATION scope. If it's not even application dependant (like states),
then put it in the SERVER scope. If it's application dependant data
(pro
Separate tables, because you should be relating those tables to your "main"
tables in the DB. For example, for a user database where you also store the
user's state, you might have a DB design like:
Users xState
-
UserI
seperate tables...I've tried a universal lookup table with classifications
and it made FK relationships impossible in some situations...didn't like
that ;-)
If your universal tabel was huge the lookup for an individual select box
would take longer as well (more records = slower query)
Bryan Steve
4 matches
Mail list logo
