Hi, in my opinion it's hard to discuss that item without knowing how deep an integration of ZF into the oxid eshop would be.
If it is really meant to replace the oxid-framework by ZF I cannot see any sense in it at all - at least not today - because: Many partners and shop-owners have just suffered all the pain by changing from version 3 to version 4. Oxid has done a good job of refactoring all the stuff and building up a stable unit test environment. So a lot of human and financial ressources have been spent to reach the fairly goog state we have today. Do you really want to think about kicking all that away just for the - maybe - marketing effect of the name "ZEND"? Do you really want to tell shop owners that next year they will again have all ther modules to be ported to a new version? Do you really want to tell partners that they will - AGAIN - have to port all their commercial modules, which have just been ported to version 4? and which mostly have not been sold enough for earning some money? I know - these are NOT developer issues, but from my point of view the question if ZF should be used in the oxid eshop also is NOT mainly a developer issue but a marketing one. Allthough from a developers point of view - if somehow possible - it could be interesting to have an oxid branch (CE) which starts making use of ZF suff, helping us to get an impression of how that could look like. But for the commercial version in my opinion it's a no-go to have that big changes in near future (24 month). Andreas Ziethen CEO of anzido GmbH -- Jetzt NEU: PHP- und OXID-Schulungen in der anzido Akademie: http://www.anzido-akademie.de anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: [email protected] Web: http://www.anzido.com USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -----Ursprüngliche Nachricht----- Gesendet: 31.08.2009 10:56:09 Von: Marco Steinhaeuser <[email protected]> An: <[email protected]> Betreff: Re: [oxid-dev-general] Evaluate Zend Framework for eShop Vorgang: 5BFMIE3I5U > 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
_______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
