I am writing this out both as a mechanism to think out loud, but also as an ask to contribute suggestions.<p>I am building what I would describe as a "supplement store as an excel spreadsheet".<p>The idea is to allow discovery of supplements based on their active ingredients (e.g. Vitamin A, Calcium, etc), then sort, filter and compare supplements based on price of the supplement as measured per a microgram.<p>I am trying to figure out what URL schema to pick.<p>The schema should allow to:<p>* view individual supplement products<p>* search supplements based on their active ingredients<p>* compare one or more supplements<p>What I have at the moment is a simple pattern:<p><pre><code> /?q=vitamin-10,mineral-2
</code></pre>
`q` is a comma-separated list of ingredients (or products). The members of `q` are in a format `[data type]-[record ID]`, i.e. This example query would list all products that have `vitamin-10` and `mineral-2`.<p>I was thinking of using this pattern for all of the aforementioned requirements.<p>The biggest problem with this pattern is that you cannot tell just from the URL what is the supplement about. We know it is a vitamin and a mineral, but we don't know which one (e.g. Vitamin B12 and Calcium).<p>My first question: Is that important?<p>Assuming the answer to the above is yes, then I am trying to think of what's the way to fix it... one way would be to replace ID with a slug, e.g. it would become `/?q=vitamin-b-12,mineral-calcium`.<p>Second question: This could work, but is it needed?
I forgot one more option I considered: Even though every ingredient is stored in a different table, I could enforce unique PK across tables. Then I would not need to specify type in the ID. This would mean that I need to lookup every ID to know which tables it belongs in though.