Basic document/bucket design questions for muti timezone/language/country sites

Couchbase Server
1

Hi,

Having read most of the couchbase docs/white-papers I have still some basic questions on document/bucket design:

  1. Storing timestamp/date values, which format do you recommend.

On the linux server I would define GMT timezone and display the date/time value according to the user’s defined timezone.
I’m using java as a client so I would use a java.util.Date to store the value according to the user’s timezone.
Because nosql is all about performance, should I store the timestamp (with milliseconds) as a long value or in a human readable value or maybe BOTH, using the long value for indexing/sorting and the human readable value when accessing the document from the console.

  1. Designing document for multi-lingual sites

In a RDBMS, I would create one database, create separate tables for labels with a language key:

2.a. Entity with a lot of ids and many attributes, eg products:

  • external table for the language dependent attributes
    Product Table
    PK: productId
    Product labels Table
    PK: productId, languageId

2.b. Entity with few ids and few attributes, eg countries:

  • all in one table
    Country Table
    PK: countryId + languageId

In couchbase I could:

  • create one bucket/database for language independent data
    1 document per product
  • create one bucket/database per language, language key is part of bucket name
    In this last bucket:
    1 document per product in that language (info changed by many users)
    1 document for all countries in that language (table managed by site admins => few users => no concurrency problems)

With this set-up I would need 2 separate client connections, 1 for each bucket to retrieve a product and the language dependent data.

  1. Couchbase having integrated CouchDb, can I use CouchDb best practices found on the net?

  2. Please add a full-text search on the forums.

Before writing to a couchbase forum I would like to check if any similar question with answer exists before writing a new post :slight_smile:

Your help will be appreciated

Fred

2

0.How do you plan on searching for data Couchbase Views or ElasticSearch?

  1. Use Zero GMT as you base time for all transactions + add user timezone.
    {“timestamp”:{“Unix”:12039481209,“TimeZone”:“PST”}}
    this way all items time are the same and then you can also map/reduce by timezone.
    In elasticSearch it likes a standerd time stamp of “Y-m-d H:m:s”

2.How many languages are you going to support? if 5 languages making 5 buckets is a good Idea, but you can to aggregate all your sales. if its 100 then add elements inside json doc about country or language is best. Also you can namespace your keys EX.“en_”,“jp_”. This way just prepend your GET()s.

Think of :
Couchbase Bucket = filing cabinet
doc = paper doc
"DocumentType":“Invoice” = doc type
"DocumentCategory":["",""] = folder(s)

3

Thanks for your answer.

Answer 0) My intention is to use Couchbase Views only for minimal query in the early versions of my application. Couchbase is still new to me and I need to understand all the features it can offer before adding ElasticSearch.
As I read it, adding ElasticSearch capabilities to Couchbase is not like adding a software layer to it, one must build an ElasticSearch database first, decide which data will be duplicated (transfered from Couchbase to ElasticSearch) and how this duplicated data will be synchronized.

  1. ok, you suggest storing the timestamp as a long. The user’s timezone will depend on his connection ( a same user could connect from different timezones) so I keep that info in his session and the date / time values will be transformed according to the session’ timezone, before sending to the client side.

  2. wow designing primary keys that includes application data, not easy for somebody coming from the RDBMS world :slight_smile:
    In Couchbase all documents are equal (no mandatory type), the only retrieval method included by default is the retrieval by id, in RDBMS by creating a table one can retrieve rows only by knowing the name of the table.
    So the selection of the format of the ids is important.
    I found this unofficial site:
    http://couchbasemodels.com/
    An official site backed by couchbase for Couchbase document design (and ids) Best practices would have been better :slight_smile:

Regards

Fred