Categories can get a bit tricky and messy. About half the time I’ve created custom fields, for the sole purpose of being able to divide content in a channel tag. The other half of the time I’ve used categories. You can’t sort entries by categories, so if you think that’s how you’d use them, use custom fields for that instead.
Not sure how much you’ve gotten into the way things work, so I’ll explain a bit (forgive if you know this already). The advantage of categories is that the content that is served up can be dynamic, with nothing more than a click on a link. It can cut down on the number of templates you need to create for content that is only unique by category. A URL that has the category in it, template_group/template_name/Cn (where ‘n’ is the category number), limits the content displayed to only entries belonging to that category, in the same way that an entry ID limits the content to a specific entry.
You can always turn that off, by adding dynamic=“off,” but if you’re going to have to turn it off more than leave it on, then there’s an argument that it isn’t its best use.
You can get into conflicts with related entries if the categories with each don’t match. BUT! You can use embedded templates, and set the child to be “dynamic off,” when they don’t share the same category structure, and still take advantage of the category heading tag for the parent templates, or the reverse, by setting the embedded parent template to off.
Sub-categories make things even more complex, and you’ll stare at the setting to have “automatically include parent” and wonder which is the best approach.
I think it is something you are going to have to play with. Set up a test with a few different category groups and see if it works the way you think it does.
Categories are NOT channel attributes, as fields might be attributes. Channels are a completely separate DB table. When you click to add a category to an entry, the system creates records linking the category to entry ID (for however many categories are selected). It isn’t like a multi-select field in the channel. For that reason, some of the things you might be thinking categories should/would do, won’t.
Categories are really powerful tool, but I think they can be over- or wrongly-used. IMHO, categories should be fairly consistent across data that is consistent, and they should be more conventional than non. If you think of a grocery store, that is a easy to understand example where traditional segregations of data with categories makes sense: produce, dairy, HBC, bakery, etc. If it becomes something more like an attribute, those should be fields, not categories.
(You could not create a “Products” channel and use categories in its place… and use the same category group for all your channels to link everything.)
Also, because category is in the URL, you can test for it in your templates, formating/selecting different elements based on what appears there. This is done with conditionals, such as if segment_3 == C57, show X, if segment_3 == C58, show Y. I’ve used this to create dynamic menus, where the menu option changes color, based on what’s in segment_3, giving the illusion that the system knows what page the person’s on. You can also force sub-menus to display in the same way… but you gotta be careful with sub-categories with a technique like that.
The bottom line is that categories should be something that will allow the user to display different content on the same page, not as a field that you hard-code in a template to limit the data.
I like Playa, and a matrix field is another field type that can be used with it. Sorry, probably too much superfluous information. I like the interface of Playa because dragging across multiple selections from one pane to another is an interface people understand intuitively. It allows you to have a one-to-many relationship. This can be useful for creating inventories, where you have product “bundles.” Let’s say you have a components channel and then a products channel, where the products are made up of the components (like a kit that contains 5 or 6 discrete items that can also be sold separately). If you’re only linking a one-to-one, the standard EE relationships will work. If you need to keep track of discrete part numbers that can be sold alone OR in a batch/bundle, Playa is what you’ll need to do that. If you need to create many-to-one then you’ll need something like Playa.
You might have a video or download that applies to more than one product, or a product that will have more than one video. If that’s the case, you might need more than the standard EE relationship field. If you start adding fields such as video_one, video_two, video_three, etc., that’s when you should use Playa. (There may be other one-to-many relationship add-ons. I only know of Playa.)
I no longer do this stuff for a living, and I’m torn between envying you and extending my sympathies. It sounds like your project is enormous and you’ll wish you knew at the beginning what you’ll know at the end. EE is an incredible tool. I’ve been using it in its various incarnations for almost 10 years. The learning curve is a bit steep, not because of any fault on the developers part, but because it IS so flexible. You have ENDLESS flexibility, which means you can also have endless complexity. Just know that there is a way to do anything you want to do. You just may not know the best way to go about doing it.
Once again, hope that helps. I’m (temporarily) disabled/retired, so helping out buddies with this stuff is how I keep my hands in it and keeps my mind sharp, I hope. Feel free to drop me an email if you need someone to run an idea past. I’m a total flake with reliability (I’m disabled for a reason), but I’d be happy to try, when I can.