Hello, I suggested already to create such an "EAV" pattern (attribute tables) indeed for OpenObject: https://blueprints.launchpad.net/openobject-server/+spec/base-eav-module However, it's very important not abusing it either. In the Magento ecommerce, the guys went full EAV pattern at first cause it was the simplest for them: once they implemented their EAV crap, it was easier for them to use it always for any attribute instead of having a decent DDL migration engine such as OpenERP. Result: even sorting products by price in Magento hit the EAV bloated tables... Anyone, used to Magento would know that this is the SQL pattern (along with the use of PHP) that make Magento dog slow for anything that can't be cached: http://inchoo.net/ecommerce/magento/escape-from-eav-the-magento-way/
So, yes, I'm for an EAV pattern in OpenObject, as long as it's used only to store some sparse attributes with very occasional search operations upon them (but yes this let room for many attributes indeed). I also recall one general principle: OpenERP doesn't have sufficient technology/consistency/functional scope to attract large companies massively yet. As it is, it really targets 10 - 50 employees SMB's (until it get clean + complete enough eventually). Those small SMB's don't really have large perf impact of using OpenERP. Perf trouble lies elsewhere eventually: too many HTTP requests (like the like of search_read in the GTK client etc...), too many clicks (cause of the lack of genericness of some widgets), widgets like many2many that were not paginated in v5, slow Python execution (top typically shows at least 40% of CPU usage in the Python part, some smart combo like Java/Mirah/Jython/JRuby would have allow to externalize some of the Python slowness to C fast languages that are still portable and reasonably powerful (I believe that Scala or Duby/Mirah are just as powerful as Python while featuring C speed and retaining a runtime compatibility with a Python impl (Jython) )). Some of the Python overhead would also be removed if we were using a smartest ORM (SQLAlchemy?) that would allow to abstract more complex SQL requests in Python rather than multiplying the DB calls and Python overhead as it is done currently all over the place in the modules (search/search/browse/relation sequences). Finally, I have some doubts: Sharoon, didn't you start some EAV pattern already? Raphaël Valyi Founder and ERP Consultant +55 21 3010 9965 http://www.akretion.com On Fri, Jul 9, 2010 at 12:35 PM, P. Christeas <[email protected]> wrote: > In a recent commit, I just noticed another module that inherits > "res.partner" > and adds 3-4 columns. > Counted the columns in one db, and found 50. > > I think we're doing something wrong here. > > Many modules need to store information per partner. They just add extra > fields > in the table. They also add one boolean field "is_member", "is_employee", > "is_clown" etc. > The same, of course, may be true for other tables, like product, for > example. > > I suggest, generally, that we avoid this pattern in setting up our schema. > My > feeling is that we waste resources (although pg's toast does compression) > in > storing NULLs for all these columns. > > At least, these booleans could be somehow covered by the partner > categories. > Then, other explicit data per partner, could be put in an "attributes" > table. > > wdyt? > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-expert-framework > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-expert-framework > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
