Question

I have a Shop table, a StaffRole table, and a ShopStaffRole table that serves as many-to-many, but with additional fields like IsRequired, etc.

Shop
  ShopId
  ShopName
  ShopAddress

StaffRole
  StaffRoleId
  StaffRoleName

ShopStaffRole
  ShopStaffRoleId
  ShopId
  StaffRoleId
  IsRequired

So my choices seem to be a Shop class and a StaffRole class with NHibernate many-to-many mapping between them, but that won’t map IsRequired well in my object model, so it makes sense to have a ShopStaffRole class as well, and one-to-many mappings between it and both Shop and StaffRole.

However, upon closer inspection, the StaffRole table has only an Id and a Name. Would it make sense to just use an NHibernate join to put the StaffRoleName directly into the ShopStaffRole class as a string, and do away with representing the StaffRole table as a class altogether?

I don’t anticipate the StaffRoleName changing within this application, so I should be able to get away with a read-only mapping that prevents one ShopStaffRole from affecting others with the same StaffRoleName.

Does this make sense, or am I missing something? It feels like my object model is just aping my relational model, table by table.

Answer 1

As it turns out, I sort of answered my own question. I can’t say it’s never a good idea to do this, but I feel now like there are so many potential gotchas that it’s extremely unlikely to be worthwhile.

In my case, I realised that although this application wouldn’t have to worry about StaffRole changing, there would be another table that found its way into the scope later on that referenced StaffRole as well, so if we ever wanted to look up a StaffRole of a Shop, then look up all the training material required by this StaffRole, then it would be a good way to have two-way accessors between StaffRole-ShopStaffRole, and StaffRole-TrainingStaffRole.