John,

Thanks for the feedback.  The code I put up is not part of any real 
system.  I'm just playing off of the existing examples in the docs and 
trying to get comfortable with SA inheritance.

Randall

John M Camara wrote:
> 
> Randall Smith wrote:
>> For discussion, consider the Employee, Manager, Engineer example from
>> the docs.  If I were designing the tables, I would not normally have a
>> "type" field.  I would use the null status of engineer_info or
>> manager_data to determine the employee type.  Or if that data was in
>> separate tables, I would use the existence of records in those tables.
>> And these are simple cases.  I can think of some real life cases where
>> the values of multiple fields would determine the class.
> 
> IMO you always need to keep your people/place/things data separate from
> your roles data.  If you put the 2 together you end up developing a
> system that is highly inflexible and the code will start to look ugly.
> After all a user can wear many hats.  He can be an Employee, Manager,
> Engineer, etc.  He can even be an Employee of 2 different companies, a
> manager of multiple groups, etc.
> 
> So I would keep user tables/classes separate from role tables/classes.
> For the database design you would have 2 basic choices.
> 
> First option:
> 
> User Table
>   userID
>   ...
> Role Table
>   userID
>   roleType
>   roleData
>   ...
> 
> Where roleData would likely contain serialized (pickled) data.
> 
> Second option:
> 
> User Table
>   id
>   ...
> Role Table
>   id
>   userID
>   roleType
>   roleDetailsID
>   ...
> Role1Details Table
>   id
>   ...
> Role2Details Table
>   id
>   ...
> <other role details tables>
> 
> I would only go with the second option if you actually needed to do ad
> hoc queries of the Role#Details tables.  Otherwise, the first option is
> far quicker to code and provides more flexibility.
> 
> John
> 
> 
> > 
> 


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to