Properties and Tenants Database

[wealthpro]

Hello,

First let me say that I'm new to this stuff. I've been reading a lot lately, but I decided that I needed to jump on a forum and ask.

I set up a database for a friend that manages 400 apartments. She wanted to store the tenant information such as contact info, rent, deposit, move-in date, etc and be able to easily look up the info.

While I was setting up the database, I heard her talking about all of the information that they keep on each apartment and that they do weekly reports about the properties. They do this by hand.

I'm thinking that they should have all of this info on the computer also. Should this be in a separate table? Some of the data would be in common, such as the move-in and move-out dates.

I just want to do this correctly from the start. Any advice would be appreciated.

Thank you,
David

 

[Uncle Gizmo]

>>>I set up a database for a friend that manages 400 apartments<<<

There have been quite a few questions asked about property management databases recently. I presume this is either a sign of the times, or possibly that it represents some sort of exam question.

In any event I should search the forum, I'm sure you will find some useful information.

 

[The_Doc_Man]

Let me add to this that before you commit too much to an actual database, you should do some serious reading on the subject of 'database normalization' via the Web. If you already know this topic, then go ahead. If not, NOW is the time to learn - BEFORE you paint yourself into an ugly little corner.

The theory and design topic has a large number of posts on how to build a database. You will need to learn about problem analysis. Since you are building an oddball sort of "model" of the management process, you need to understand about identifying the objects of the model. (I.e. for a model, a rentable unit is an object. A renter is an object. If the apartment was furnished, the furnished items are objects.) Objects go in tables that segregate them from each other. You then establish relationships between different objects.

Example: A renter rents a unit. (AND a unit is rented by a renter; it's a two-way street, of course....) So there would be some way to track who had rented which unit. This is what we mean by "relationships" in Access.

Read the Access Help files on "normalization" and "relationships" which are actually a couple of sides of the same coin. Wikipedia (.org) has a couple of nice, if brief, articles on the subject.

I'm giving you this advice now because the earlier you learn to do it right, the less amount of rework you will have to do later when something breaks. No slur intended on you, either. Stuff breaks. For the best of us, stuff breaks. NOBODY consistently gets it right the first time. But if you do things from an informed position, you will do it closer to the correct way the first time and have less to fix later.

 

[wealthpro]

Thanks for the replies.

After doing a lot of reading, I have decided that I will just put the simple tenant form up with a search function.

They were keeping track of 400 tenants on a Rolodex and they were having trouble keeping it up to date.

If they want to do more, I will refer them to an expert! This was my first Access project and I think I could quickly get in over my head.

Thanks again,

David