First, I wish to apologize if the title is vague, the question is hard to summarize – please feel free to edit as appropriate.
In a website I am building, I have products within categories (and the categories are being expanded constantly) that have attributes (I can’t think of a better word, I apologize for the fact that this crosses with database terminology, but I mean attribute as in color, size, weight, not as in a field of a database table). Those attributes may or may not be defined depending on the category, and sometimes specifically the product.
Now, individuals using the website will want to create a query that searches for items matching specific attributes (think “is green, weighs less than 4 lbs., rated 3 stars or higher”), and save that query in the database as a tuple of a table that they can reference. Mind that these will be end-users, so they will not be able to actually write the query themselves. Also note that there may be a great deal of redundancy in some types of queries, and that there will be many more of these queries than there are items.
My first thought:
Store the items all in one table (items), with an id, category id, name. Store attributes types in attribute_types with id, name, type (which would be int, string, enum, etc). Store attributes in a separate table with item_id, attribute_type_id, and value.
Then, create the query based on HTML selections as though I were actually querying the database, save the exact query, and store it as a string in a table with an id and query. Check for the existence of a query before storing it.
This seems as though it would work, but I can’t immagine that this is the best way to go about it. Is there a more efficient, or frankly less ugly, solution? Am I even storing the items in an appropriate manner?
Thank you,
James
If the number of specific attributes and categories is small enough, this is usually solved using Concrete Table Inheritance (or some other derivation of it), if not you need an Entity-Attribute-Value model – which is difficult to do complex queries with and, in the long run, can lead to GIGO pretty fast.
Another alternative approach is to use schemaless datastores, such as MongoDB or serialized blobs.