Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Best
Prac*ces
for      Good
Document
DesignDus*n
Sallings          @dlsspy
QUICK
POLL Normaliza)on
SCHEMA‐FREE
DATABASE• schema
defini)on
is
op#onal
at
write
)me  – 
no
need
to
define
schema
before
adding
data   –
write
any...
HOWEVER!There
are
constraints.                         4
INHERENT
SCHEMA      sort
of                  5
UNIQUENESS• Document
ID
is
the
only
(DB‐side)
way
to
make
  something
unique• App
could
de‐duplicate
from
map/reduce  – 
b...
IMPLICIT
BASICS                  7
JSON
DOCUMENTS{    “json”:
“key
/
value
pairs”,    “_id”:
“specified
id
or
auto
generated
UUID”,    “_rev”:
“mvcc”,    “key...
KEY
NAMES• JSON
Object
restric)ons  – 
they’re
all
strings• 
Couchbase
Server
reserves
these
prefixes
on
top‐  level
keys  ...
VALUES• JSON
restric)ons  – 
objects,
arrays,
strings,
numbers• Consider
how
you’ll
be
using
it
in
your
app  – 
template
s...
ONE
DOC
OR
MULTIPLE
DOCS?                            11
DECISION
MAKERS• what
does
this
document
look
like
in
real
life?• how
oeen
will
I
update
this?• does
this
need
its
own
rev...
QUERYINGcan
I
get
at
the
doc’s
data
easily?                                      13
UPDATING• When
things
change,
do
I
want
to
update
the
doc?  – 
or
record
the
document’s
changes
as
individual
docs• Freque...
REPLICATION  the
biggie!                15
REPLICATION• Where
possible...  – 
avoid
conflicts  – 
leverage
small
pieces• Keep
uniqueness
and
conflicts
in
balance      ...
CONVENTIONSpaving
the
caBle
trails                          17
CONVENTIONS
&
GOOD
HABITS• “type”:
“contact”• “created_at”:
Unix
)mestamp• “status”:
some
status
for
this
doc
(ex:
publish...
MORE
CONVENTIONS• “created_by”:
username  – 
typically
from
_users
database• “profile”:
CouchApp
profile
contents  – 
from
_...
TOOLS        20
VALIDATE_DOC_UPDATE• op&onal
schema
enforcement• func)on(newDoc,
storedDoc,
userCtx)• throw
errors
to
prevent
save• cannot...
SAMPLE
DOCS
(IN

2.0) HANDY
FOR
QUICK
DOC
“SCHEMA”
REFERENCING                                            22
ADVANCED
DOCUMENT
DESIGN   more
tools
and
tricks
in
this
session                                           23
EXAMPLES           24
1.{2.     "_id": "2011-10-20T00:32:58_101D8A2A000000F7",3.     "_rev": "1-0c9914a4695b67a4f38cb5f8e345d28f",4.     "readin...
1. {2.    "_id": "0017dcf0149c130229f35b537df48073",3.    "_rev": "7-ef6c5723edafb9828dbc36467493341d",4.    "old_id": 734...
ANY
QUESTIONS?• catch
me
in
the
lounge• or
online: • @dlsspy • dsal
on
irc.freenode.net:
#couchdb,
#couchbase,
#membase • ...
Upcoming SlideShare
Loading in …5
×

CouchConf-NYC-Best-practices-good-document-design

953 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

CouchConf-NYC-Best-practices-good-document-design

  1. 1. Best
Prac*ces
for Good
Document
DesignDus*n
Sallings @dlsspy
  2. 2. QUICK
POLL Normaliza)on
  3. 3. SCHEMA‐FREE
DATABASE• schema
defini)on
is
op#onal
at
write
)me – 
no
need
to
define
schema
before
adding
data –
write
any
sort
of
JSON
you’d
like• schemas
can
be
enforced• but
(by
default)
only
maBer
when
wri)ng
queries 3
  4. 4. HOWEVER!There
are
constraints. 4
  5. 5. INHERENT
SCHEMA sort
of 5
  6. 6. UNIQUENESS• Document
ID
is
the
only
(DB‐side)
way
to
make
 something
unique• App
could
de‐duplicate
from
map/reduce – 
but
that
can
be
tricky• So,
be
prepared
to
handle
conflic)ng
IDs 6
  7. 7. IMPLICIT
BASICS 7
  8. 8. JSON
DOCUMENTS{ “json”:
“key
/
value
pairs”, “_id”:
“specified
id
or
auto
generated
UUID”, “_rev”:
“mvcc”, “keys
are
strings”
:
[1,
2,
3,
“four”,
null], “schema
free”
:
true} 8
  9. 9. KEY
NAMES• JSON
Object
restric)ons – 
they’re
all
strings• 
Couchbase
Server
reserves
these
prefixes
on
top‐ level
keys – 
“_”
underscore
‐
also
reserved
by
CouchDB – 
“$”
dollar
signs• cannot
have
duplicate
key
names
on
a
single
level – 
{“key”:
1,
“key”:
2}
is
invalid
(thankfully) 9
  10. 10. VALUES• JSON
restric)ons – 
objects,
arrays,
strings,
numbers• Consider
how
you’ll
be
using
it
in
your
app – 
template
system
constraints – 
Mustache
needs
arrays
of
objects
vs.
arrays
of
arrays• Be
careful
of
numbers
as
strings• Date
formats – 
ISO8601 – 
unix
)mestamps – output
as
an
array
for
grouping
reduc)ons 10
  11. 11. ONE
DOC
OR
MULTIPLE
DOCS? 11
  12. 12. DECISION
MAKERS• what
does
this
document
look
like
in
real
life?• how
oeen
will
I
update
this?• does
this
need
its
own
revision/transac)on
path? – 
does
all
this
data
need
upda)ng
together? – 
or
rolled
back
together? 12
  13. 13. QUERYINGcan
I
get
at
the
doc’s
data
easily? 13
  14. 14. UPDATING• When
things
change,
do
I
want
to
update
the
doc? – 
or
record
the
document’s
changes
as
individual
docs• Frequently
wriBen
docs
might
make
replica)on
 harder
due
to
higher
conflict
probability• Will
I
have
de‐normalized
por)ons
of
data
on
hand
in
 the
client
app
when
upda)ng? 14
  15. 15. REPLICATION the
biggie! 15
  16. 16. REPLICATION• Where
possible... – 
avoid
conflicts – 
leverage
small
pieces• Keep
uniqueness
and
conflicts
in
balance 16
  17. 17. CONVENTIONSpaving
the
caBle
trails 17
  18. 18. CONVENTIONS
&
GOOD
HABITS• “type”:
“contact”• “created_at”:
Unix
)mestamp• “status”:
some
status
for
this
doc
(ex:
published)• “tags”:
[“couch”,
“db”,
“nosql”] 18
  19. 19. MORE
CONVENTIONS• “created_by”:
username – 
typically
from
_users
database• “profile”:
CouchApp
profile
contents – 
from
_users
database – 
stored
on
the
doc
for
convenience 19
  20. 20. TOOLS 20
  21. 21. VALIDATE_DOC_UPDATE• op&onal
schema
enforcement• func)on(newDoc,
storedDoc,
userCtx)• throw
errors
to
prevent
save• cannot
modify
newDoc• can
enforce
field
types,
values,
formats• can
prevent
docs
or
fields
from
being
changed
 (created_at,
user)• runs
every
)me
a
document
is
updated – 
even
during
replica)on 21
  22. 22. SAMPLE
DOCS
(IN

2.0) HANDY
FOR
QUICK
DOC
“SCHEMA”
REFERENCING 22
  23. 23. ADVANCED
DOCUMENT
DESIGN more
tools
and
tricks
in
this
session 23
  24. 24. EXAMPLES 24
  25. 25. 1.{2.   "_id": "2011-10-20T00:32:58_101D8A2A000000F7",3.   "_rev": "1-0c9914a4695b67a4f38cb5f8e345d28f",4.   "reading": 22.98,5.   "sn": "101D8A2A000000F7",6.   "ts": "2011-10-20T00:32:58",7.   "type": "reading"8.} 25
  26. 26. 1. {2.    "_id": "0017dcf0149c130229f35b537df48073",3.    "_rev": "7-ef6c5723edafb9828dbc36467493341d",4.    "old_id": 7343,5.    "height": 1800,6.    "keywords": [7.        "wrx"8.    ],9.    "cat": "Public",10.    "size": 1711223,11.    "tnwidth": 194,12.    "exif": {13.        "EXIF ApertureValue": "367/100",14.        /* ... */15.        "EXIF SensingMethod": "One-chip color area",16.        "MakerNote AEWarning": "Off",17.        "Thumbnail Orientation": "Horizontal (normal)"18.    },19.    "descr": "My car had fun this weekend.  It got all dirty in the snow and then ran into a sign. ",20.    "ts": "2006-02-22T17:47:16",21.    "addedby": "dustin",22.    "width": 2400,23.    "extension": "jpg",24.    "tnheight": 146,25.    "taken": "2006-02-21",26.    "type": "photo",27.    "annotations": [28.    ],29.    "_attachments": {30.        "800x600.jpg": {31.            "content_type": "image/jpeg",32.            "revpos": 4,33.            "digest": "md5-HB0NfWVLWeQJn8j79214Fw==",34.            "length": 84388,35.            "stub": true36.        }, 37. // [...] 26
  27. 27. ANY
QUESTIONS?• catch
me
in
the
lounge• or
online: • @dlsspy • dsal
on
irc.freenode.net:
#couchdb,
#couchbase,
#membase • dus)n@couchbase.com 27

×