Subjects

I thought more about tags and found out it's even more flexible, than I imagined. All in the sense of the original idea of simplification for QetriX, tags is a generic group of anything.

It works well for users. Now tag is not only a group of users, but it acts as a role as well. You can tag users as “employee”, “customer”, “vip”

Tags! Tags everywhere!

I liked the idea for at least a decade: do not structure items into hierarchical categories, but assign them a bunch of tags and if needed, structure those tags into hierarchy.

Imagine a filesystem, where directories (folders) will be structured in a familiar tree structure, but you'd be able to assign them to files as tags. You'd copy a file simply by assigning another directory to the file and you'd be able to create a multitude of “virtual” directories to categorize the file.

Now I applied the idea on Qedy and upgraded tags to classifications. You do not specify a type of an entity, you assign it a bunch of tags to classify it. It's brilliant how elegantly it fits the whole concept.

The primary purpose is not filtering per-se, but rather creating lists of similar entities. You can specify particular tags for a menu items, for similar articles, you can define binary flags as tags (paid, published) and more. Tags are great for multi-language projects, because they are translatable.

Working with tags is easy and straightforward, but as usual, the major drawback is performance. It's fast to find all entities with a given tag, it's still quite fast to find all entities with given tags, but it's database killer to find all entities with such and such tags, that are missing another set of tags.

Wikipedia categories are a great example of tags

For example, in CRM you might want to list all customers, who ordered stuff during past 6 months, but didn't add some service you offer, like insurance, gift wrap or personification. Of course you can define a tag “no-insurance”, but you could easily end up with thousands of tags and millions of tag assignments, because you never know what you'll need to query one day, which quickly becomes a nightmare to manage and expensive to store.

Another nice, but resource heavy use case is to find similar entities just by their tags. You simply compare entities by their tags and find closest matches. It's quite easy for those with the same amount of tags, but becomes difficult when the count differs. How related are entities “A” with tags [a,b,c,d] and “B” with tags [c,d,e]?