The Task: Define a system for filtering items of a like kind.
The world’s thinking would have one lean toward naming entities, such as one would find as an ORM (object relational mapping), determining what characteristics should be used to discern one entity from the other and presenting some interface for allowing the task’s achievement. This task is represented in the following scenario.
A library catalog has many resources. Some are fiction books, some are reference books, some are office hours, some are online subscriptions, etc. If more elaboration is needed, consider the web site of a public library; all of the information on the first page must first be clarified as something worth presenting, and the visual layout planned and orchestrated. It’s a quantifiable task, but requires one with intimate knowledge of the library system to organize.
A primary resource of a library system is its search catalog. This is the capability of a user to sort through what is available and discover the exact resource(s) which they want. For an individual making such a system, the task is Define a system for filtering items of a like kind. In this case the “kind” is “resource,” but the process of filtering allows the user to refine which resource with more specificity, for example “non-fiction book.”
The world’s thinking would have one lean toward naming categories, assigning each resource a category, and allowing the searcher to refine which category they are interested in. Further, there are more categorization strategies, such as tags or faceting. This is common terminology for the practice of ascribing a set of descriptors to a resource, rather than simply one resource category. By faceting, multiple queryable description fields are available to a searcher, and a more refined search is possible.
These two strategies, categorization and tagging, are actually the same strategy implemented two ways. Many content management system provide these tools as separate, and the system’s use case for the terms are different, but as data organization strategies, they are the same. For the user of the system, e.g. a searcher, they are the same.
Despite the similarities, systems engineers often build overly-complex representations of this one principle. The most common representation of this involves multiple resource tables, a categories table, a categories/resource join table, possibly a very simple tags table (nothing more than a list), and surely a resource/tags join table. Conversation may be had if this is the ideal way for relational-mapping of the system, but some similar solution will surely arise for a developer with a relational database.
The purpose of this article is to present the claim There is a Better Way. And this Better Way may be the end of relational databases supremacy, and the overly-complicated systems which arise.
The Answer: Qualities, the Only Table One Ever Needs.
The Task Define a System.
Next.