Data Modeling/Architecture

I need some help with data modeling that someone else may be able to advise me on with only of a few seconds of your time.

I have a number of different data that needs organizing. It's pretty easy to think about conceptually and is all common stuff we've all seen before. I just would like a little advice with the appropriate route to take as I begin this task.

Anyone got any good book recommendations on this subject while I'm asking?

So, here's what's up:

I'm creating a website that has a few roles:
1) Finding car part numbers and part diagrams
2) Provide data on cars (performance stats, sales info, stats, stats, stats...)
3) Give users a way to post classified adds, write reviews for parts, review parts companies, users who might have sold them a car and deserve recognition, responses to our site's blog, etc.
4) Give users a resource that tracks their own vehicle and its maintenance/performance upgrade history and even allows them to post up and have other users verify 1/4 mile time slips and stuff like that.

Tables as I see them:
1) Users and their browsing habits plus their car profiles
2) Cars and their stats
3) Part numbers and the associated vehicles
4) Aftermarket parts associated with OEM parts and reviews written about them
5) Blog posts and responses
6) Car sales data submitted by users
7) Local repair shops and their rates
8) Vendors

Would performance increase on the site if I, say, broke the database up by make or some other common statistic? Does that all sound about right as far as how you would typically model out some tables for the site?

I liked Database Design by Ryan Stephens and Ronald Plew.

Don't break the database up based on model, etc. Be sure it is normalized to the 3rd form. Looking at your sample tables, I don't think you are. Add indexes as appropriate. If probably designed, speed will probably not be a problem. Only after your database is properly designed should you consider making it less normalized to increase performance.