关系数据库MYSQL / PHP

Question

I am building a classified ads website, similar to craigslist.

The site is divided in to several sections; i.e. Forums, For Sale, Services Offered, etc.

Under each Section there are several [categories], i.e.Forums[pets], Forums[Books], For Sale[barter], Services[Barter], etc. (Notice that some categories are only uniquely identified by their section, such as in the case with barter and barter from two sections "For Sale" and "Services".)

Users will post to the categories from post links within each section. Users can upload photos and select certain amenities for their products, if applicable. A forum post will not need an amenity attribute whereas a Vehicle Ad might. Amenities include: auto transmission for vehicle ads, or furnished for housing rentals.

I am trying to figure the best logical setup for the database schema.

Currently I have this type of logical structure for basic input/query:

SECTIONS TABLE- section_id, section
CATEGORIES TABLE- cat-id, category, section_id(foreign key)
AMENITIES TABLE- amen_id, amenity
PHOTOS TABLE- photos-id, file

POST TABLE- post_id, category, timestamp, description

SECTION_POST TABLE- section_id, post_id
POST_AMENITY TABLE- post_id, amenity_id
POST_PHOTO TABLE- post_id, photo_id

I made the [SECTION_POST] my main many-to-many because the category in the [POST] must be related to the section. I related CATEGORY to SECTION in the categories table, which looks to me like a M-to-M with the addition of category attribute. Is this ok?

Also, do you have any other suggestions as to how i should be thinking on this schema? I think the problem I am having is mostly related to ignorance not lack of organizational skills. Maybe one of you can educate me or refer me to a decent link that tackles my general problem.

Answer 1

Your design is fairly standard. Here's a couple of comments, and some things to consider:

• For your keys where you have an implied dependent relationship (SECTION_POST for example) many ORM libraries have issues with
  dependent relationships and the resultant concatenated keys. There's also the issue of key allocation. For both of those reasons, many
  people will instead give that table its own independent key (which
  can conveniently be made AUTO_INCREMENT) and move the original PK to foreign keys.

• In terms of SECTION/CATEGORY, only you can say how important of a concept/entity SECTION is, however the obvious questions would be, how is a SECTION in any way different from a CATEGORY. You could have the same structure, with even more flexibility by having only CATEGORY with a self referencing "PARENT_CATEGORY_ID" column. This would allow you to define a tree structure of categories, while at the same time, it's simple to get the top level categories using IS NULL on the PARENT_CATEGORY_ID.

• I'm not clear on how you plan to relate photos to a POST, but it would be nice from a design standpoint to support a M-M relationship so that you can have multiple photos for a single post.

Otherwise, you seem to have a good handle on relational design basics. I do a lot of database design, and prefer to use a commercial erd design tool, but there are some free options like Mysql workbench (assuming you're designing for mysql) that can help you visualize your design, and insure that all the SQL DDL is correct. It's also nice to have documentation for the development phase of your project.