Hi Andreas, thank you for your opinion!. Great ! It is explicitly intended to also include 'non-development' issues into the discussion. Because integrating ZF will effect everything.
And that's actually why we started this discussion in the first place. It's not _just_ technical issues here. Keep adding that part into the discussion ! > in my opinion it's hard to discuss that item without knowing how deep an > integration of ZF into the oxid eshop would be. Actually that's one of the many answers we seek. - If we do integrate ZF, how deep do we want to do that ? - Do we really want to replace as many eShop framework places as possible with ZF ? Or do we just want to augment eShop framework with ZF ? Personally I believe that - if we do integrate - we should be doing it with a easy transition phase where old style modules should be still working for a long time .. For me that means that we shouldn't replace eShop classes that quickly with ZF framework classes. Only there where it really has a large benefit. More likely will be that new features will start using ZF first. We do intend to do some spike version. I'm pretty sure we will publish that so everybody can join in. Regards, Erik -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von anzido GmbH Gesendet: Montag, 31. August 2009 12:09 An: [email protected] Betreff: Re: [oxid-dev-general] Evaluate Zend Framework for eShop [Vorgang: #5BFMIE3I5U] 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
