The problem with doing it this way is that it is not extensible.
A manufacturer cannot add, say, MP3 players to the list at a later date
without breaking the car table. Also, in time, there could be quite an
extensive list of features - which would lead to an inefficient storage
system.
Dave
----- Original Message -----
From: "..s.c.o.t.t.." <[EMAIL PROTECTED]>
To: "Php-General" <[EMAIL PROTECTED]>
Sent: Tuesday, June 26, 2001 7:35 AM
Subject: RE: [PHP] [OT-ish] Optional Extras.
> off the top of my head, you could try using a
> "lookup table" to define the extra options...
>
> ford_spec table:
> id desc
> --- -------
> 1 air conditioning
> 2 whatever
>
> ford_cars table:
> car extra1 extra2
> ------ ------- ---------
> 'contour' 1 0
> 'probe' 0 1
>
> "contour" would have "aircond" but no "whatever"
> "probe" would have no "aircond" but would have "whatever"
>
> so to add more options specific to a manufacturer,
> you could make an entry into "ford_spec" and then
> create an "extra3" field in "ford_cars"... this system,
> at least, would enable you to have as many extras
> as you wanted for each manufacturer, and have
> different options available for different manufacturers.
>
> i dont know how efficient this would be, and there are
> probably a bunch of better ways to do it, but i've seen
> this method used before by someone who developed
> a batteries catalog and needed to store different
> manufacturers with different options for their batteries.
>
>
> > -----Original Message-----
> > From: Dave Mariner [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 25, 2001 12:54
> > To: [EMAIL PROTECTED]
> > Subject: [PHP] [OT-ish] Optional Extras.
> >
> >
> > Please excuse me if you consider this to be off-topic, but this is the
best
> > place I can think of to ask the (slightly long-winded) question.
> >
> > Imagine you have a car database (MySQL driven). Different models have
> > different optional extras (air-con, central locking, immobiliser etc). I
> > need to store the optional extras in a searchable form - i.e. the
customer
> > may have a wish-list of electric windows, aircon, and power steering.
> > However the optional extras list is not and will not be finalised when
the
> > system goes live (probably will never be finalised!). Therefore I cannot
do
> > the quick-and-dirty hack of putting all the options as binary fields in
my
> > car database, so must come up with a more elegant solution. I've thought
of
> > storing e.g. 10 tuples car.option1->aircon code,
car.option2->powersteering
> > code. etc. and also going down the header-detail route.
> > My current quandry is to which is going to be better for the search
> > aspect, considering I'd also like to give them a "best fit" option.
Would it
> > be to create a cursor on my fixed criterion (price, age etc) and then
> > iterate through each of those manually in my php script (see - it isn't
> > entirely off topic ;0) ) counting the matches for that record in the
> > optional-extra detail table? Or would it be to do a select where
> > (optionalextra1=mychoice1 or optionalextra2 = mychoice1 ......) and
> > (optionalextra2=mychoice2 or optionalextra2 = mychoice2...... ) and ....
etc
> > etc (yeuch!).
> >
> > I have a sneaking suspicion that there's a more elegant way than
either
> > of these, but can't think of it at the moment.
> >
> > If you come up with the solution there's a beer in it for you the
next
> > time you're in Paphos, Cyprus!
> >
> > Thanks in advance,
> >
> > Dave.
> >
> >
> >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
