On 19 March 2010 11:43, Tom M. [email protected] wrote:
why everything is stored in a single table
That’s called Single Table Inheritance (STI)
Can we store each items for say staff,director etc to
there own tables? Or Am I wrong?
You’re not wrong; you can do it with different tables if you want.
Data modelling is done however is best for you. Sometimes you might
start with STI, refactor to associations, and then refactor back to
STI as your project requirements evolve.
Problems may occur when, for instance, your Managers also need to have
elements of the properties of Staff - you can’t inherit from two
base-classes, so you have to start looking at mixing-in modules
instead, or of some other method of structuring your data to make it
make sense. Also, what happens if you have someone who’s a staff
member of two offices (if that’s possible for your organisation)? Can
they have different roles in the different places? etc…
Personally, I tend to keep “users” as a table for
authentication-related info, and in my “people” table (I’d tend to
avoid STI for people) I keep personal info, link to a user record, and
assign a “role” which is used for handling permissions. I’d rather
have lots of associations for data, because that’s more flexible than
one wide flat table (the likes of which STI generally leads to…)