Forums / Developer / Need tips on a big project

Need tips on a big project

Author Message

Jorge estévez

Sunday 01 July 2007 3:59:56 am

Hi,

I have this big project in hands:

4 languages
4 designs
250 000 products

I will be doing lots of studies : Usability is the main issue and within usability comes findability, to be able to find products for different needs in the site products must be classified not only by their known keywords but also by color, manufacturer, family of products, design, material, etc. (metadata)

This will not only help me develop new ways to find products in the Web site but show different related products by different classification to the user.

As categories for objects could be quite a lot (multiple categorization for each object);

How do I develop the best solution to "activate" an object into several categories?

Which is the efficient way for administrators to classify products when creating and inserting their data? I will need a solution that will shorten the mouse-clicks and time to set the object into many categorizations.

250 000 products and their possible relations is not a joke at all, so please if someone out there has any hints in a project similar to this one I will appreciated any word of advice before I start, any guidelines, experience, list of do and do not, a must read, anything...

I can also be reached at yamiletms [at] cubarte [dot] cu

Thanks, Jorge

Diseño Web Cuba
Web Design Cuba
www.elfosdesign.com

Paul Borgermans

Sunday 01 July 2007 11:10:52 am

That's al lot of objects! You will need top notch hardware for this

For the user side: to set up an efficient way of finding, your best bet is actually to use a form of facetted navigation/search .... some major e-commerce sites use this. The user side may be implemented with the Solr search plugin as faceted navigation on meta-data is one of the main goodies it provides. It will be released soon now. If you want early access code, mail me. Another advantage of this plugin is that it stores the index outside of the eZ Publish DB.

For the administrators, you can use object relations or select fields, with a customised edit template for quickly adding the meta-data. Object relations are the way to go for meta-data like manufacturer, family of products, categories. For the others, maybe select fields are more appropriate.

In order to keep performance levels, use either manufacturer or categories as main nodes. The number of children you can have should not exceed a few (maybe tens of) thousands per subtree.

I hope this helps you a bit
Paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Xavier Dutoit

Monday 02 July 2007 3:07:07 am

Hi,

Good suggestions of Paul.

For the main node, I'd suggest to use the category, as it fits better the category/subcategory logic than the manufacturers (assuming you don't have sub manufacturers).

As for the edit of the template, I'd suggest to have some kind of ajax systems, as on one of my web sites with a long list of potential related content, it's becoming quite slow to fetch the list and display it with the checkboxes. Shouldn't be too complicated (I had a something that got stuck in a beta stage).

X+

http://www.sydesy.com

Betsy Gamrat

Thursday 12 July 2007 10:50:54 am

Hi,

This is a really interesting challenge.

I would consider the number of manufacturers, products, categories, families, designs, materials, etc. prior to choosing a navigation scheme.

For administration, I would probably organize the products under main nodes of manufacturers, then categories. For the site visitor view, I would offer the products under both category and manufacturers.

I would also consider dividing the system to make it more managable. 250 000 products is a huge number, and most site visitors would only access a subset of them. Based on the target market, it may be good to create a portal approach, where a top-level site offers access to a group of subdomains, which group related products. This would greatly reduce the size of the database needed to run the system, and improve performance. Development would not be significantly impacted, because the same code could manage all the subdomains.

Good luck!