value to the application. In other words, if the select box is optional and
the client doesn't want to make sure that they explicitly said, "no value"
then it doesn't need to be stored in the database. Otherwise, I use null, as
you do.
As for the "other" fields, I usually handle those in the join table if it's
a many to many situation, such that you'd have a join table like so:
userid number,
fruitid number
other varchar2
Or, if it's a "select one" I'd handle it in the main table:
userid number
fruitid number
otherfruit varchar2
Not sure if this is "correct" but it works for me.
----- Original Message -----
From: "Jamie Jackson" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Monday, February 09, 2004 12:55 PM
Subject: Select Field Values
> Here's a rudimentary little question, but one that I go back and forth
> on:
>
> Say you have a dynamically driven select box:
>
> What's your favorite fruit? [select name = "fruit"]
> -Apples [value = 1]
> -Oranges [value = 2]
> -Other
> -Not Applicable [value = NULL]
>
> (Feel free to take issue with any of the following:)
>
> I'd assign the "Not Applicable" option a value of NULL in the DB
> field, so it would have neither a foreign key nor lookup value.
>
> However...
> 1. Generally, should the "other" option be in the database (as a field
> in the lookup table)?
> 2. Or alternatively, should the "other" option be a static one (if so,
> how is it best represented in the DB)?
>
> Thanks,
> Jamie
>
>
>
>
>
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
