The main problem with tables denormalised to contain more real world entities is possibility to fill unrelated fields (e.g. both from Group and Role). But if you let the persistency completely on mapping tool (OJB), you don't have to worry about it - OJB will not mangle them..

The main remaining con of mapping to one table (in most situations) is the size of the database - it will be a bit bigger.

But, across as there will be no need to joins, the scenario will be faster than separate tables..

But I'm also not a db expert, so I may be wrong..

David

[EMAIL PROTECTED] wrote:
David,

thanks for your comments. The main problem that I see with this approach is that each of the classes inheriting from the abstract class have very different attributes - so there will be a lot of empty fields in the table - I am not an expert, however I would assume that this is not good table design? For example, the actual classes I am trying to build are "PermissionHolder" (abstract) and User, Role and Group (concrete). User has many more attributes than the Group and Role. Do you see this as an issue?

It is interesting that if I use a concrete class as the parent (rather than abstract) I seem to be able to store and retreive - a least in simple test cases.

Marcus




Marcus Young wrote:


Each class is mapped to a separate table.

I persuaded, that it's much easier to map the whole hierarchy to one table and provide ojbConcreteClass..


David

--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to