CouchDB中的Schemas详解

jieforest · 发表于 2012-9-12 10:08

Nesting

You could have a nested object structure like:

01.{
02."datatype": "pattern/v1",
03."data": [
04.{
05."datatype": "triangle/v1",
06."data": [
07.879.07395066446952,
08.84.607510245708468,
09.1.4444230241122715,
10."red"
11.],
12."owner": "Simon",
13."location" "space"
14.},
15.{
16."datatype": "triangle/v1",
17."data": [
18.879.07395066446952,
19.84.607510245708468,
20.1.4444230241122715,
21."blue"
22.],
23."owner": "Fred",
24."location" "space"
25.},
26.{
27."datatype": "square/v1",
28.data: [
29.10,
30."green"
31.]
32.}
33.]
34.}

复制代码

jieforest · 发表于 2012-9-12 10:08

But if you're going to have a schema you may as well reflect the nesting inside it, e.g say that you have a list of triangles and a list of squares:

01.{
02."_id": "datatype/pattern/v1",
03."fields": [
04.["triangle/v1"],
05.["square/v1"]
06.]
07.}
08.
09.
10.{
11."datatype": "pattern/v1",
12."data": [
13.[
14.{
15."data": [
16.879.07395066446952,
17.84.607510245708468,
18.1.4444230241122715,
19."red"
20.],
21."owner": "Simon",
22."location" "space"
23.},
24.{
25."data": [
26.879.07395066446952,
27.84.607510245708468,
28.1.4444230241122715,
29."blue"
30.],
31."owner": "Fred",
32."location" "space"
33.}
34.],
35.[
36.{
37.data: [
38.10,
39."green"
40.]
41.}
42.]
43.}

复制代码

jieforest · 发表于 2012-9-12 10:08

Schema evolution

A nice feature of this way of working is that you can deal with schema evolutions; changing the format of your data.

01.{
02."_id": "datatype/triangle/v2",
03."fields": [
04."opposite_length_in_cm",
05."hypotenuse_length_in_cm",
06."angle_in_degrees",
07."colour_label"
08.]
09.}

复制代码

jieforest · 发表于 2012-9-12 10:09

There are only so many ways you can represent the data. While sometimes you may have a major schema evolution, one where old data is completely unusable, often changes are just tweaks for consistency (say changing the units of a quantity) or extending the schema by adding in optional data. In either case you should be able to use data from multiple schema versions together by using appropriate manipulations on the data. For example you could instantiate shape objects via a factory which knows how to create the right object for different schema versions.

jieforest · 发表于 2012-9-12 10:09

Validation

The above does no validation of the data; the color field in the input data could be set to a number instead of a string, the angle to something non- physical etc. If you really needed validation you could do it with CouchDB's validation functions.

If you go the fully validated route you'd want to define the schema in the design document (instead of as a normal doc) and use a CommonJS include to make sure that the validator in the app was doing the same thing as the schema. This ties you to a version of the design document (which is where the validators live), which may or may not be an issue. It will also considerably slow down insertion rate as CouchDB has to do more work to add your data.

Personally I prefer to put validation logic in the client making writes.

jieforest · 发表于 2012-9-13 12:57

Views

If I were using this way of working I would want to have a view which returned all the schema's defined on the database. This then allows me to build objects appropriately. A view to return schema's documents would look like:

1.function(doc) {
2.if (doc._id.slice(0, 'datatype'.length) == 'datatype') {
3.emit (doc._id.slice('datatype/'.length, doc._id.length), doc.fields)
4.}
5.}

复制代码

jieforest · 发表于 2012-9-13 12:57

You can pull out documents that have a schema with a simple view like:

1.function(doc) {
2.if (doc.datatype){
3.emit(doc.datatype, doc.data);
4.}
5.}

复制代码

jieforest · 发表于 2012-9-13 12:58

This can be queried to find objects of a given shape using CouchDB's view slicing

(e.g. ?startkey="square/v1"&endkey="square/v2") which returns data like:

1.{"id":"datatype/square/v1","key":["square/v1",0],"value":["side_length_in_mm","colour_label"]},
2.{"id":"f98ffe7e4cd91cbb0d904f9098499ca8","key":["square/v1",1],"value":[872.4342711412228,"green"]},
3.{"id":"f98ffe7e4cd91cbb0d904f909849a218","key":["square/v1",1],"value":[370.29971491443905,"yellow"]},
4.{"id":"f98ffe7e4cd91cbb0d904f909849acd0","key":["square/v1",1],"value":[8.799279300193753,"yellow"]}

复制代码

jieforest · 发表于 2012-9-13 12:58

You'll notice the name of the "schema" is the key and the values are held in value.

This means I can parse the data into a set of appropriate objects with something like:

01.var objects = [];
02.
03.function build(schema, data){
04.// Build the appropriate object for the schema...
05.}
06.
07.for (row in data){
08.// build up the objects in a factory
09.var obj = build(row.key, row.value);
10.objects.push(obj);
11.}

复制代码

jieforest · 发表于 2012-9-13 12:58

If I wanted all versions of a shape the query would be, and used a vNUMERIC_COUNTER notation for versioning, ?startkey="square/v1"&endkey="square/vXXX" as numbers sort lower than strings.

Taking it to the extreme

If you are really worried about data size you can take this technique to the extreme by encoding the data arrays as a byte string and using the schema documents to describe that byte array. This effectively turns your JSON structure into something not dissimilar to a protocol buffer, at the expense of human readability and view complexity. If you are particularly concerned with data size over the wire (for example are writing an MMORPG) then this may be an acceptable trade off.