you probably do want to have "other" in your look up table. It's a business
rule question more than anything. For example, if you want to be able to do
a query that says, "of the people that chose "other" fruits, how many also
preferred orange juice over grape juice," it'd be easier if you have other
as a real piece of data in the look up table.
Of course, that means you probably need to do some verification on input
such that if someone enters text in the "other" text field, that they didn't
choose something that isn't "other" in the radio group.
----- Original Message -----
From: "Jamie Jackson" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Monday, February 09, 2004 2:18 PM
Subject: Re: Select Field Values
> Hi Deanna,
>
> Actually, where to store the "otherFruit" field isn't the question,
> though I'd agree with your placement. Rather, the question is what
> goes in the database (i.e. the "fruit" field) if someone selects the
> "other" option (ignoring, for a moment, the implied "otherFruit"
> field). Is it simply a foreign key on the lookup table, which contains
> "Other" as a row? (It seems like this solution could potentially junk
> up lookup tables, but maybe that's what's called for?)
>
> Thanks,
> Jamie
>
> On Mon, 9 Feb 2004 13:38:34 -0600, in cf-talk you wrote:
>
> >I never use the "not applicable" in the database unless it's a
"meaningful"
> >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]
