What an excellent ad for SQLite, where you could do this with a simple schema: Table 1: <piece id> <combo id> <location>
Table 2: <combo id> <glaze id> <priority>
That's.. it.Location specifies where the combo is applied to the part; priority specifies ordering of the glaze layers (glazes whose order doesn't matter have the same priority). The only thinking that needs to be done is understanding that you don't mix glazes and combinations in a single project, but a project has a set of combinations associated with it, some of which may only have one glaze. Writing the requisite SELECT queries (getting all pieces that use a glaze, or vice versa) is left as an exercise to the reader (which, I hope, is straightforward - but the same can be said of the schema). This article does a lot of mental gymnastics to avoid using a relational database to store relations. NoSQL has its places (e.g. sometimes, a KV store is a KV store), but this isn't it. Sometimes I feel like the NoSQL hype did some collective damage to the way people think about data. But then again, I'm not a database architect, so what do I know. |