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
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
