Re: [OT-ish] Optional Extras.

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.." <scott@furt.com> To: "Php-General" <php-general@lists.php.net> 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: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 > > > > -- > 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 >