Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jeff.l@mavericklabel.com
 designates 209.85.219.44 as permitted sender)
MIME-Version: 1.0
Date: Sun, 6 Oct 2013 14:31:07 -0700
Message-ID: 
 <CANHC0ZK118PUBqnBUBW9kGMNS49jvmJKewRqjR7qRUZ5wku40Q@mail.gmail.com>
Subject: Data modeling questions
From: "Lowery, Jeff" <jeff.l@mavericklabel.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=089e0117601fe5bd1304e819405d

--089e0117601fe5bd1304e819405d
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I'm evaluating CouchDB and have some questions about our domain and how it
might be modeled. I have used JMX in the past, so I'm not entirely
unfamiliar with key-value data stores. At this stage I'm still trying to
formulate the right concepts and questions, so forgive me if I come across
as a bit confused.

We have product definitions with multiple specs, such as size, shape,
material, color. The user is allowed to select a set of spec options for
the product they want. However, some options are dependent on others, and
the desired workflow does not direct the user toward a particular sequence
of option selections.

The use cases are:

1) given a partial set of selected spec options, what are the available
options in the yet-to-be-selected specs?

2) given a complete complete product definition (all spec options
selected), what suppliers support that product definition?

My first inclination is to use composite keys based on selected spec
options to look up valid values for unselected options.. for example:
 material spec determines available color spec choices.  However, the
reverse holds true: color determines material choices.  If I understand
right, it would require two view definitions, one with a color key, another
with a material key, to support both scenarios.  But there may actually be
compound dependencies:  material/color in tandem determines available
options for proof (online or none).  And proof/color in tandem would
determine available material selections.

On the supplier case,  I may have supplier that doesn't support a
particular material, or maybe not a particular material/color combination.
 Rather than assign every possible product definition to a vendor or
vendors that support it, I wonder it there's easy way using wildcards (any
shape, any material but red polyvinyl, any size, any color except red if
polyvinyl, etc.). It's possible these sort of restrictions might be better
encapsulated in a rules engine.

>From what I recall of JMX, keys were named and unordered (map-based). If I
supplied a set of key/values, all data with those key/value pairs would be
returned.  It looks as though CouchDB composite keys are array-based and
ordered;  I'm also not sure that wildcard values ({}) or ranges would work
(or be efficient) for any composite value in a composite key query.

Anyway, I've got a lot of data I can load up and play with tomorrow and I
hope to have more specific questions later.

-- Jeff

--089e0117601fe5bd1304e819405d--