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:dave@medlab-group.com] > Sent: Monday, June 25, 2001 12:54 > To: php-general@lists.php.net > 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: php-general-unsubscribe@lists.php.net > For additional commands, e-mail: php-general-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >