In an MRP context, I have several products that have varying attributes I need to keep track of. For example, we have Doors that need to track edge profiles / wood species / panel types and drawer pulls that we need to track, say, material and shape.
One approach would be to append all of the data to product.product:
class product_product(osv.osv):
_name = _inherit = 'product.product'
_columns = {
'product_type': fields.selection(('', ''), ('door', 'Door'), ('pull', 'Pull')),
'door_edge_profile': fields.char(size=40),
'door_wood_species': fields.char(size=40),
'pull_material': fields.char(size=40),
'pull_shape': fields.char(size=40),
}
This approach works, but is rather denormalized - all products have these extra fields, and they may or may not be used. The data is stored as columns appended to product.product.
Another approach is a separate class per product type:
class product_door(osv.osv):
_name = 'product.product.door',
_inherit = 'product.product',
_columns = {
'door_edge_profile': fields.char(size=40),
'door_wood_species': fields.char(size=40),
}
class product_pull(osv.osv):
_name = 'product.product.pull',
_inherit = 'product.product',
_columns = {
'pull_material': fields.char(size=40),
'pull_shape': fields.char(size=40),
}
This approach also works, but the data is now split between two tables, with a `product_id` column hanging off the child tables. This is nice because the code is easy to separate / deal with, but makes the UI component harder - The end user will need to visit a different section when editing door or pull details, and none of the existing views will incorporate any data about the door or product.
A third approach i've discovered is a little hacky, but works:
class product_door(osv.osv):
_name = 'product.product.door',
_columns = {
'door_edge_profile': fields.char(size=40),
'door_wood_species': fields.char(size=40),
}
class product_pull(osv.osv):
_name = 'product.product.pull',
_columns = {
'pull_material': fields.char(size=40),
'pull_shape': fields.char(size=40),
}
class product_product(osv.osv):
_name = _inherit = 'product.product'
_inherits = {
'product.product.door': 'door_id',
'product.product.pull': 'pull_id',
}
This approach keeps the data in it's own tables, and composes the fields into the product instance. The effect on the UI is the same as option 2 (in that it's somewhat negative), and the data is nicely separated. However, this implies again that every product has door or pull attributes in terms of the db design.
I really like [SQLAlchemy's inheritance mapping](http://docs.sqlalchemy.org/en/latest/orm/inheritance.html), so i'll use those names when i'm talking about them further.
The first example I showed, which seems like the "default way" people seem to add to OpenERP models, is single table inheritance.
The second example is Joined Table Inheritance, where the child tables point to their parent.
The third example is 'backwards' joined table inheritance, or composition.
====
Separate from these concerns is using, say, product_variant_multi and encode the product attributes as Dimensions. Or, one could not use Dimensions, and instead apply 'mrp.property' properties to the product. This is more of an [EAV](http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model) data store, but I'm not certain that this complexity is worth it.
--------------------
So, how do most OpenERP users generally model their databases?
Thanks for the advice.
↧