I have done a lot of reading on database design but I can't figure out how to design my OWN database. The examples i see are very neat and make perfect sense but I can't make sense of my own (see attached doc). However I will have 125000+ entries.
I was thinking of having brands in one table, makes in another, years in another, parts in another and then having one large master table with a bunch of foreign keys referencing the aforementioned tables.
I wasn't sure if this was the best way, is it too granular???
What does brands mean? Can it have a name only? Or is it tied to a company too?
Same goes for your other tables.
When I design my databases I try to describe what different parts I have in my system, usually one name (becoming the table name) grouping a bunch of properties representing the name (becoming the column names).
It completely depends on what you're using the database for.
I can see how parts may be it's own table.
year/make/model/brands(?)/style are describing a vehicle, and they go together. It seems odd to me to split them up.
Again, it depends on what the database is being used for. Maybe the question you should ask yourself is:
"What's the relation between parts and vehicles in my system?"
If you were a client and had already made this table you're showing me. I could probably think of 25-30 questions to ask you.
Looking at normalization alone, I agree with you and would put, at least, brand, make, model, and fuel in their own tables. Looking at the parts fields, I agree with that also, if they same value shows up over and over again in your records, you've definitely got stuff you can normalize.
From the sounds of your post, you're definitely on the right tack.
I've switched careers...
I'm NO LONGER a scientist,
but now a web developer...
awesome.
Bookmarks