Hi folks,
I'm facing a little db design dilemma. I'm constructing a used car
database, and one of the pieces of information that I need to store about
each car is what options it comes with. The options themselves are stored
in a table, and the structure of that table looks like this:
option_id int4
display varchar(40)
description text
Now, I also have a cars table, and each car has a basic set of information
that is stored there. The problem is this: the number of options that
will be associated with any given vehicle is variable. So, my initial
inclination was to create a separate table to store the options for each
car and put two fields in that table:
car_id int4
option_id int4
Then, to get the options for any given vehicle, I just select all its rows
out of the car_options table, and join that with the options table to get
the description for each option.
Trouble is, I anticipate there might be as many as 10 options for any
given vehicle, and once I get 500 or so cars in the database, then I've
got 500,000 rows in that table. If I'm allowing people to search based on
the options that might come with a vehicle, I'm afraid that my search
might take an awfully long time.
Is there a better way to design this? I thought about making the option
ids for each vehicle a comma-delimited text field, but maybe the search
would be even slower if I did that. Since I'm not a SQL expert, I don't
know, but I'm asking all the experts out there--how should I set this
thing up??
Many TIA...
_______________________
Eric McKeown
ericm@palaver.net
http://www.palaver.net