在CouchDb中创建新文档而不进行更新的可能的缺点是什么？

Question

I have started using CouchDb in conjunction with PouchDb in my new project and am relatively new to it. I had a basic doubt.

To update a doc, I need to have the _rev value, which means querying the database, eg as shown here

// fetch mittens
db.get('mittens').then(function (doc) {
  // update their age
  doc.age = 4;
  // put them back
  return db.put(doc);
}).then(function () {
  // fetch mittens again
  return db.get('mittens');
}).then(function (doc) {
  console.log(doc);
});

After update, there are two revisions of the document present in the db. Older revisions of the document are purged only during the compaction process.

If I add a timestamp to my doc id's, eg shashi@stackoverflow.com-user-1464772888286, then instead of having different revisions of the same document, there are different documents in my db.

After adding a new document, I can delete the document with older timestamps. Thus, when querying I can query all_docs with

startkey="shashi@stackoverflow.com-user-"&endkey="shashi@stackoverflow.com-user-\uffff"   

and take the latest doc based on timestamp. (In any case, since I am deleting older docs when creating a new one, this query gives back only one doc.)

In the app I am building, a desktop app, docs will be created and modified only on the desktop and are synced to the server for wareshousing/reporting/analysis purposes. Thus, the scenario that somebody else will modify a doc leading to conflicts is minimal.

Initially, I had gone with the approach of keeping the id same. However, I encountered a weird error where pocuhdb threw an error when trying to update the doc, but different revisions with the identical data were being created on CouchDb, to which pouchDb is configured to sync. Since I was short of time and was building a Proof of Concept, I went ahead with the approach of timestamps in _id.

However, now I am wondering what are the potential pitfalls of this approach? I have an instinct that there are, since nowhere have I seen anyone take this approach, but I am not quite sure what are they.

Answer 1

CouchDb is most efficient doing lookups by the main id. To use the start and end key you will need to use a view meaning you will loose performance and deal with the somewhat more complex views.

For example if you do a lot of inserts there will be a small delay in getting responses from the view while it updates. It will also require more disk space.

I would also argue that the delete you will do will impact your performance much more than first retrieve the doc before updating. Better to have the compaction deal with old versions during quiet time.

Finally, since you are always creating new docs I assume you will always have access to the full doc when you do the write (how would you otherwise be able to store without retrieving), maybe you could also store the "_rev" param (comes back when you do the PUT) and then use it for updates and not have to request the doc.