On Wed, 6 Feb 2008 08:49:19 +0100 "FGM" <fgm@osinet.fr> wrote:
It really depends on what you call "bulk". I have such a site with over 100k SKUs, updated weekly, and creating/deleting the whole node set every week is not something you want to do. OTOH, if you're in the 1k SKUs, this is still reasonable.
The key concept for such volume use, though, appears to be lazy node creation (only create product nodes when you actually want a transaction involving them). This has been discussed recently (maybe it was one some planet blog ?), and others pointed to similar mechanisms on their own project. The problem is that ecommerce (and AFAIK, ubercart) have no support for such mechanisms, only being able to work on product nodes, not create nodes on the fly from non-drupal data.
I'm developing ground up an ecommerce module and I chose the route to just use a MENU_CALLBACK to display products. Up to my understanding if I had used "plain" nodes I'd have gained comments and taxonomy but still I'd have to do a lot of customisation. If you're not going to edit products inside drupal there is no need to go the CCK way and the custom node type route doesn't give any advantage compared to just using different templates if you've different product lines. Taxonomy too is "too general" and may have a huge performance impact once your catalogue is 500K-1M items divided in several thousands categories. Since editing was not going to happen in drupal, linking products and categories to nodes and taxonomy would have made syncing the back-end with the front-end too complicated, especially if you're going to make a catalogue update 1 or twice a day. Furthermore I had to use a lot of pk/fk data integrity logic that didn't fit into node too well. Still drupal has plenty to offer: theming, table sort, fapi, block management, menu, javascript effects, administrative interface, permissions, localisation... I do think I'll still be able to use drupal infrastructure for adding comments to "non-nodes" somehow... but it is not a priority. I do think that having a more complex category system is important and drupal taxonomy could offer some inspiration if not code, but planning a more complex categorisation system is out of my reach now and taxonomy as it is doesn't offer anything I could really exploit now but impose a too high toll in terms of performances and complexity. If I'm going to glue taxonomy with the catalogue I'll have to beef up/specialise taxonomy to really take any advantage from a more complex system and right now I can't. Consider that if you don't have synonyms, multi-categorisation etc... coming from your back-end, feeding this extra data to drupal for several thousands categories and 500K products is not going to be easy anyway. Not really to much to wait to see if this pig can really fly... -- Ivan Sergio Borgonovo http://www.webthatworks.it