Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Is this entity relationship diagram okay?
- Thread starter nick9191
- Start date
- Sort by reaction score
I would flatten it out some more.
For example you have 4 tables devoted to storing information about people: resstaff, student, adviser, and next of kin. I would create one table for people, and use role definitions to type the person. If one person can have multiple roles, then you would need to store that information in an associative entity table to resolve the many to one relationships. You also have address information stored in multiple places: hall, resstaff, flat, student, leases, and next of kin. Create a single address table and have the other tables reference it as required. That way you only need to write one chunk of code to maintain address information and not one chunk for each table. Finally, your invoice design limits an invoice to having one line item. Most invoice structures use a master-detail pattern where one invoice header can have many detail lines.
For example you have 4 tables devoted to storing information about people: resstaff, student, adviser, and next of kin. I would create one table for people, and use role definitions to type the person. If one person can have multiple roles, then you would need to store that information in an associative entity table to resolve the many to one relationships. You also have address information stored in multiple places: hall, resstaff, flat, student, leases, and next of kin. Create a single address table and have the other tables reference it as required. That way you only need to write one chunk of code to maintain address information and not one chunk for each table. Finally, your invoice design limits an invoice to having one line item. Most invoice structures use a master-detail pattern where one invoice header can have many detail lines.