On Tue, Mar 23, 2010 at 9:13 PM, Phpster <phpster@xxxxxxxxx> wrote: > Most if that stuff should only be in the db as a reference and when editing > te lists. The actual user acessed data should sit in simple XML files that > can be passed to the client, broken out by category or prod line. The > reasons are simple, database access time is going to suck, no matter what > you are running. And why would you ever need to run translation real time. I > can tell you from persoanl experience that such solution totally blows. I > lost that battle at work and the current solution build every field on the > fly each time with translation ( supporting 12 languages) and it's damn > slow. Cache out whatever you can, to an in memory cache or to the file > system. Let the web server do it's job of serving files, not processing > upteen little bits of data from a db. > > It's about design, from all I've seen, threading introduces about as many > challenges as problems it solves. > > Bastien If having the products info in categorized XML files as you mention, why the need for DB then? What about some product name changes to correctly describe the product without the informed shopper having to read the description/specifications? The translation is fetched from the DB and not using any 3rd party software translation on the fly. > > Sent from my iPod > > On Mar 23, 2010, at 9:17 PM, Tommy Pham <tommyhp2@xxxxxxxxx> wrote: > >> Let's go back to my 1st e-commerce example. The manufacturers list is >> about 3,700. The categories is about about 2,400. The products list >> is right now at 500,000 and expected to be around 750,000. The site >> is only in English. The store owner wants to expand and be I18n: >> Chinese, French, German, Korean, Spanish. You see how big and complex >> that database gets? The store owners want to have this happens when a >> customer clicks on a category: >> >> * show all subcategories for that category, if any >> * show all products for that category, if any, >> * show all manufacturers, used as filtering, for that category and >> subcategories >> * show price range filter for that category >> * show features & specifications filter for that category >> * show 10 top sellers for that category and related subcategories >> * the shopper can then select/deselect any of those filters and >> ability to sort by manufacturers, prices, user rating, popularity >> (purchased quantity) >> * have the ability to switch to another language translation on the fly >> * from the moment the shopper click on a link, the response time (when >> web browser saids "Done" in the status bar) is 5 seconds or less. >> Preferably 2-3 seconds. Will be using stopwatch for the timer. >> >> Now show me a website that meets those requirements and uses PHP, I'll >> be glad to support your argument about PHP w/o threads :) BTW, this >> is not even enterprise requirement. I may have another possible >> project where # products is over 10 million easily. With similar >> requirements when the user click on category. Do you think this site, >> which currently isn't, can run on PHP? >> >> Regards, >> Tommy >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
