Hi Everybody, as no decision was made yet, we would like to continue this discussion.
In his blog post http://www.oxid-esales.com/en/news/blog/zend-framework-and-oxid-eshop Erik asks for further opinions about this topic. Besides, a forum thread was started: http://www.oxid-esales.com/forum/showthread.php?p=13076 Cheers Marco -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Lars Jankowfsky Gesendet: Sonntag, 19. Juli 2009 12:22 An: [email protected] Betreff: Re: [oxid-dev-general] Evaluate Zend Framework for eShop Thomas, >> Magento is not slower than oxid because of the usage of ZF. It's the >> database layout. They use a normalized layout which - in fact - was >> also there in the oxid 0.1;) > Sorry for off-topic in-between asking here: Does it mean you would > prefer a denormalized relational db layout for performance reasons in, > yes well, in which case exactly? To be honest: When i first got in > touch with OXID i was wondering about the denormalized tables and > thaught it came from earlier times... Is this still a state of the art > "silver bullet" (with all its disadvantages) to increase performance > in these days (of e.g. server power availability at a low-cost > level)? Would be cool to hear a bit more about this in general and > OXID's evolution here, maybe you find time for a few notes. Actually when I've created OXID in the very first version the database layout looked more or less like magento nowadays. It turned out not to work.. Any layout where you have a multiplier in rows per article for depending tables does not work. It is ok for small shops but as soon as you do have a larger number of rows it doesnt work any more. Therefore I've decided to denormalize and - it works pretty well for many years now. Violating the theory which we've learned in university is sometimes needed - there is a decent difference in live between theory and practice. The funny thing is that magento does exactly the same now to solve their problems. They've created denormalized "cache" tables where they duplicate all rows from the "normal"ized tables. I do not believe that this way is a good one - keeping data synchronized between two sources always creates many problems and never works perfect. IMHO they will go the denormalized way one day in future fully. No way around. The books should be adopted. De-Normalizing is a key practice which you do first when talking about performance tuning. And to answer your question. Yes, there is no way around de- normalizing. For sure you can bring a pig to fly but for what costs? And where would be the reason todo so. The de-normalized layout is simple, stupid and works perfect. Everybody can understand it and change/adapt it to his/her needs. There are many advantages and simply no disadvantage (besides the 'ugly'ness which we've learned from the books). BTW - just as a small side note. ORM is also one of the first things you through overboard as soon as you run experience performance issues. HTH and a nice and relaxed sunday, D. _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
