We tend to use one large table here, called "picklists". It basically has a unique ID, display value, display type and sort ordering columns. Now on some of the projects we do have the one large one and then some smaller ones, just depends on the needs.
The reason we stick to the large one a lot is because our CRUD tool uses an SP to check for FK violations when you go to delete a "picklist". If any violations are found it displays a message to the user stating what sections and amount of violations there are. Only thing about that is our data models end up with a ton of FK's off that one large table and can look like spaghetti(sp?) quickly.
I'd imagine if we were ever to rebuild/redesign our tool we would perhaps go about this differently. Although I tend to stick with this large lookup table method on my own projects.
On 2/8/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
----------------------------------------------------------I like method 2 myself...but you have to be sure you index the lookup types properly, and rather than having text values for the lookup types, I prefer to have another table for lookup types with an identity for the foreign key relationship in the lookup table. Obviously, some will argue that doing it this way could cause performance issues if the table grows too large, but on the other hand, I think cod writing is much easier, especially if you've got a lot of lookup tables.
Allen
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
