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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
