I had been considering this solution, but didn't mention in my post,
out of fear that it would complicate the message.
I'm beginning to lean toward this solution, especially since you
offered it independently. It has the benefit of leaving my lookup
tables clean. However, I had been hesitant to take some meaning out of
the DB and put it into the app's business logic, but I guess that
doesn't matter much.
Thanks,
Jamie
On Mon, 9 Feb 2004 15:15:09 -0500, in cf-talk you wrote:
>Based on the question I would assume that the other field has an accompanied input box. What I would do is use a NULL value for both "Other" and "NA". And the "Other" input can be used to distinguish that it is "Other" and not "NA".
>
>Tyler Clendenin
>GSL Solutions
> ----- Original Message -----
> From: Jamie Jackson
> To: CF-Talk
> Sent: Monday, February 09, 2004 1: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]
