Hi Mahesh, I am replying to the CouchDB Users' mailing list as well. You may find more help there than just my response. I recommend you subscribe to the list to see any other responses and to get in touch with other CouchDB users.
----- Original Message ----- > From: "Mahesh Kanniah" <[email protected]> > To: [email protected] > Sent: Thursday, July 16, 2015 2:20:58 AM > Subject: couchdb question > > > Joan, > Just saw a video on couchdb by you. Impressive! Thank you for your kind words! > I have a couple of questions on couchdb. I would be happy if you can > share your thoughts on the same. > > > I will give a background of what i am working on. I am making an all > in one organizer that stores all your contacts, todos, financials > and pretty much everything a person would want to store all the way > from BMI to pills and documents from passports to credit cards and > so on. Synced across their phones/tablets and pc. > > > I am using pouchdb on the client end for the replication and it works > pretty well at least under test environment. What i am confused is > how do i store the data correctly in the first place. > > > So Joan is a USER. She has different documents like todos and bank > statement records. > > > Here is are the questions. > > > 1. Should joan be given a single database. The per user database > system? > And should she store all the documents in the single database. If > each document has a different schema wouldn't it be taxing to filter > / query them. But again as finally the user is going to filter them > OFFLINE on their devices (phones) is it just as simple as replicate > the data and do all the filtering client side and shut the case? Yes, database per user is a good model for this setup. Filtering by document type is a very common CouchDB data model. > 2. Couchdb has this revisioning system. It maintains revisions which > i suppose is a good thing. Now 99.99% of the time my user or anyone > is just happy to get the latest data. Is there some funda of telling > couchdb not to store revisions or is it a part of couchdb that the > revisions are essentially important to make sure the synchronization > is effected correctly? I mean is it like hey if you want > synchronization then it needs to have revisions. Do not think of _rev as a revisioning system. It is only used to ensure that data is stored consistently across multiple replicas, especially when updates are done to multiple replicas and replicated with each other (so-called multi-master replication). > 3. In couchdb when a document is deleted there is nothing like > deletion but a revision setting the document to a state of RETIRED. _deleted: true, though depending on the delete method all other fields are typically removed (by using the HTTP DELETE verb, for instance) > This retired documents will keep growing. For ex. i make 10000 > records and delete all of them. When i bring in a fresh device and i > do my first time sync it is going to get me all the 10000 records > and then finally mark them off as deleted whereas the active > documents might be a handful. Filtered replication can remove these so-called tombstones if there is a very high volume of deleted documents. You can use views to determine the %age of tombstones in a db and use filtered replication to remove them if necessary. > Would it be wise that retired documents be re-used ? > Like for ex. I Create a bank statement record and instead of > inserting it into the database i check if there is a retired > document available. If it is available i update that instead and > mark it as active than creating a new document. No, because when deleted using the best method available all old fields are removed from the document. If you want to keep old documents, then do not use the DELETE method but create your own delete, such as an inactive: true/false field. In this setup your data will always grow (no documents will ever be deleted) but you can always undelete any document you need. The choice is yours depending upon the data access methodology you want. Hope this helps, Joan Touzet
