Hi folks,
This post could probably fit in any/all of three forum/threads... but I will go for this one - well, because I'm here.

I read with interest the issues of the eCommerce gate etc.
My Main) issue is also with multiple categories... thought I'd put two pennies worth.

I have been hunting the Business Directory issue - up down and sideways... on XOOPS - xDirectory and derivitives such as xyp4all (still cannot se the diff!).
On Mambo the Phil Taylor Directory (AUD$73) and another for US$99 etc. etc. etc... And all the other so-called "Yellow-Pages" efforts.

Many discussions seem to be about (a) money or (b) the layout/design of presented output. Easy.

I'm beginning to think I'm going to have to roll-my-own. But for anyone who is interested, the way to go about multiple categories should, I think, be as follows:

IMHO, THE central issue of providing a fee-for-listing (Premium level) service is that of allowing users to list in MULTIPLE categories. The core issue expressed by Wired2 and xueming.

I note also the post from "xueming" going down the road of trying to address the multiple categories issue by way of "cid1,cid2,cid4" in the xidr_links table (of xDeirectory).

With respect, IMO this is is a flat-file database way of thinking. The point here is that, the keyword in RDBMS is "relational".

The way to go about Multi-Cats is to use the database correctly. This not really that big an issue if an additional MySql table is employed to allow for Category_Links.

It means inserts/updates to more than one table at the Add or Edit an entry time. So what?

On the Add/Edit html form, simply provide three or four drop boxes with appropriate names, for category selectors with appropriate values. Obviously, these are populated from the categories table... A bit of nifty javascript can eliminate the possiblity of being able to select the same category more than once.

So, the business listing Table gives a business an (auto) ID - let's say 169. The categories might have category values of say, 1534, 1535, 1536....

Then to the links table - let's call it "dbPrefix_cat_links" needs only two columns (Usually, I use three and allow for an auto-ID for each row as well, but is not essential):
The business (id=169) is then listed one or more times by ID only, in the links table thus:
biz_id cat_id
----------------
169 1234
169 1235
169 1237

When it come to putting records on the page, it is a matter of looking up the cat_links table AND the content table in one (more sophisticated) SQL statement.

So that, if a visitor selects ANY category where there is a match from the cat_links table, list it! Being mindful of the fact in the SQL ORDER clause, that Premium entries are flagged and need go to top of the listing.

That's more or less it.

On another tangent...:
Generally (there are a few exceptions) in the XOOPS schema, when we select a menu item (module) we essentially run ONLY that module as though it were a stand alone system, rather than an integrated set of modules.

The principle of Links Tables could be employed much more broadly and make XOOPS modules much more flexible across an entire set of installed modules and the info therein... but that is the stuff of another story. Not to mention a version 6.0 of XOOPS!

That's all I've got.
Hope this helps someone... I do not really have time to build muy own, but if I can help with methodology, I will try.

Regards

Chris