Re: vehicle to autoparts relationships

Jeff & Celko,

First of all, thanks for all of the input. I have to say I don't agree that all sectios of the automobile are parts and more than the vehicle itself is a part. Perhaps in real life, the consumer will but a 2000 Ford Escort, and later may purchase a head gasket for it, so to that customer each one is simply a part# on his invoice.

In regards to my current database, I have a Vehicle table, an EngineConfiguration table, a Transmission table, and a host of others. I believe each vehicle (make, model, year, body style, etc) must have different sections, and each section can have many parts. I know a part can be used in multiple sections, so this calls for an Xref (crossreference) table. I can only assume that this is the way your typical autoparts store handles things, but I'm not sure. I may have to post this on an autoparts site to get a better idea.

Thanks for the input, and any more ideas you may have.

Jeff Smeker wrote:
> -CELKO- wrote:
> > >> All things are parts (cars, sections, parts) <<
> > Yes
> >
> > >> Any part can be a parent <<
> > No, some parts are atomic
>
> I assume this means it is just a single part, with no children. If so,
> I didn't mean that every part HAD to be a parent, just that any part
> COULD be. From a DB structure point of view.
>
> >
> > >> Any part can be a child <<
> > No; there is a final assembly
>
> Again, a part does not HAVE to be a child, but any part COULD be.
>
> >
> > >> Every part can have supplier information (i.e. multiple suppliers,different supplier part
> > numbers) <<
> > Yes, but the intermediate assemblies are supplied by us from atomic
> > parts.
>
> Once again, this is fine. The part does not require supplier info, but
> could, if needed.
>
>
> I must be confused, I thought, per the OP:
>
> >I have a challenge, to figure out what part of the vehicle to relate parts to.<
>
> Well, the structure I presented does just that.
Received on Thu Dec 07 2006 - 17:56:05 CET