From: alexander s. <al...@an...> - 2004-02-17 16:46:25
|
jws...@ra... wrote, at 17.02.2004 17:46: > The storage will be factored relentlessly, which means lots of small, > specialized tables. I would like to use SQLObject to wrap up(join) those > tables into convenient objects that can be manipulated. As an example, we > want to have a customer account object in our app. That would be stored in > the database as a number of tables- > > cust_account - main table > buyer - contact name, relates to customer account > buyer_info - contact address info, relates to buyer > county - relates to customer > shipping_rates - relates to customer > > Note that from the standpoint of the cust_account object, these are all > one-to-one relations. if the relations are strict one-to-one, then why data is divided into separate tables? perhaps relationships may be optional, e.g. some customers are buyers, and others are not? if this is the case, then you may consider using SQLObject inheritance patch by Daniel Savard. > It should be relatively simple to traverse these > relations and present the attributes of the sub-tables as attributes of the > root class. I will call these 'proxy attributes'. If x is an instance of our > cust_account class, I should be able to do 'print x.email_addr' and get the > address of the buyer back. Obviously this only works if there is one > traversal path across the tables- one-to-one relationships. we did attribute delegation like this, but it did not play well, so we recently switched to class hierarchies. thanks Daniel! best wishes, alex. |