When designing tables as part of a system, ID fields are more efficient for computers to link a master table to other transaction tables. ID fields are useless when humans need to lookup data. So the direct answer is, yes, all tables should have an ID field that links back to your master tenant table. Based on your description, the tenant table should also have a separate state field. Several other fields may be useful for searching such as Telephone Number, Zip Code and Rental Location. You may also want to split the tenant name into first name and last name fields. There are guidelines for database design call Rules of Normalization. You can search the Web for these. Try www.databasedesign-resourc
Main Topics
Browse All Topics





by: Helen_FeddemaPosted on 2009-08-21 at 09:06:42ID: 25153256
Each table should have a unique ID. I recommend using AutoNumber fields called TenantID, DeveloperID, etc., so you will know what type of record you are dealing with when you use these fields in queries. The table of states can be a lookup table, say with the 2-letter abbreviations for storing to other tables, and the full state name for selection from a combo box. You need tables for Tenants, Developers and maybe Use Types (I am not sure what that is; possibly it could be a lookup table). You might need a many-to-many relationship between Tenants and Developers. I presume one Developer could have many tenants (a one-to-many relationship), but is the reverse also possible? Could one tenant rent or purchase from multiple developers? If so, you need a many-to-many relationship between tenants and developers, with a linking table containing TenantID and DeveloperID, and possibly one or more fields pertaining to that particular combination of tenant and developer.