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]
