Database Design for Rental Listings

I'm designing a simple database for a rental listings website,

sort of like classified ads but only for home/room rentals.

This is what I've come up with thus far:

Question 1

For the "post" table, I actually wanted more information. For example, there would be a 'facilities' section where the users can select whether there's 'parking' available, do I need a separate table? Or just use 0 for no and 1 for yes?

Question 2

Here's what I did with the "category" table (sorry I don't know how to pretty print yet)

Category_ID 1 is Rent

Category_ID 2 is buildingType

For "categoryProperty" table

Category_ID 1 categoryPropertyID 1 House

Category_ID 1 categoryPropertyID 2 Room

Category_ID 2 categoryPropertyID 3 Apartment

Category_ID 2 categoryPropertyID 4 Condominium

Category_ID 2 categoryPropertyID 5 Detached

Does the above make sense?

Question 3

Users can post whether they are logged in or not.

Just that logged in users/members have the advantage of tracking their ads/adjusting the availability.

How do I record the ads that a member has posted开发者_运维技巧? Like their history.

Should I create a "postHistory" table and set the 'postHistory_ID' as FK to "member" table?

Thanks a lot in advance, I appreciate your help, especially just pointing me to the right direction.

Question 1:

make a separate table and make a One to One relation, that would be the simplest way:

POST -|-----|- EXTRAS

in EXTRAS you may have every extra field (parking=1/0, in_down_town=1/0,has_a_gost=1/0)

Question 2: This does not make sense, you've two options:

in the Post table create a "type_of_operation", that can have two vales (building_type,rent). Or you can create different tables, but would make this more complicate (you should analyise if the same type can be in both states, etc).

Question 3: I recommend you to make your users register. Even with a really simple form (email+password) .

Seems to be on the right track -- with respect to your specific questions:

Question #1: Assuming there's more than one type of facility (parking; swimming pool; gym) then you have a many-to-many relationship and you want 2 new tables: Facilities and PropertyFacilities. Each Property (or I guess "post") could have multiple rows in the PropertyFacilities table.

Question #2: Not really clear on what you're getting at -- is it that each property type can either be rented whole or rented per room?

Question #3: Good question, what you want to do is have an Active bit, or an ExpireDate, in your POST table -- then anything that becomes inactive or expired is automatically 'historical' data, no need to marshall it to a history table. Although you'll have to archive eventually of course.