couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Copenhaver <sean.copenha...@gmail.com>
Subject Re: Help with data modelling
Date Fri, 10 Jun 2011 13:16:55 GMT
Ah I think I see what you mean:

"*all-or-nothing* - To use this mode, include "all_or_nothing":true as part
of the request. In the case of a power failure, when the database restarts
either all the changes will have been saved or none of them. However, it
does not do conflict checking, so the documents will be committed even if
this creates conflicts"

So even though you "transactional" committed multiple documents, when you
retrieved them you won't always get what you committed.

On Fri, Jun 10, 2011 at 8:47 AM, Robert Newson <robert.newson@gmail.com>wrote:

> The bulk documents API is not transactional in any useful sense.
>
> On 10 June 2011 13:42, Sean Copenhaver <sean.copenhaver@gmail.com> wrote:
> > It sounds like you are trying to combine things into a single document.
> What
> > were your concerns that you would want to put all manufacturers in a
> single
> > document or all log entries for example? That is instead of in a view
> query
> > result?
> >
> > I don't think there would be an issue with having everything as a
> separate
> > document. There are ways to pull back related documents in one query that
> > would resolve concerns of having to do many hits. As an example, you
> could
> > create a view to be able to pull back the device, user, and profile in
> one
> > query.
> >
> > The wiki has some information on managing relationships:
> > http://wiki.apache.org/couchdb/EntityRelationship
> >
> > On the flip side there are ways to perform CRUD operations on multiple
> > documents at once, including transactional (although with multiple dbs
> you
> > can run into inconsistencies as the transaction won't hold up across
> > replication):
> > http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API
> >
> >
> > 2011/6/10 Javier Rodríguez Escolar <javiescolar@gmail.com>
> >
> >> Hello, I'm a CouchDB newbie trying to migrate an existing application
> from
> >> SQL to NoSQL. I have designed different approaches to model the CouchDB
> >> documents and I have been leafing through a couple of books [1],[2] in
> >> order
> >> to figure out the possible problems each approach might cause, but I
> still
> >> have some doubts. Basically the data model of my application domain has
> the
> >> following scheme:
> >>
> >> *Data model overview*
> >>
> >>   - Mobile manufacturers (in the order of 60). Each manufacturer has
> >>   different models:
> >>   - Mobile models (in the order of 2000 per manufactorer)
> >>   - Errors. Each manufacturer has a set of types of errors (in the order
> of
> >>   1000 per manufacturer)
> >>   - User
> >>   - Mobile device
> >>   - Profile. Identified by a User and a MobileDevice
> >>   - DebugLog. Each debug log takes just 10 words and one DebugLog per
> >>   second is sent to the server.
> >>   - ErrorLog. Each error log takes just 10 words and they are generated
> >>   once in a while.
> >>   - So, my main doubts are listed below:
> >>
> >>
> >> *Doubt 1 (manufacturers and models)*
> >>
> >>   - Option 1
> >>      - One document for all the manufacturers: "Manufacturers". It just
> >>      includes a list of manufacturers, each of them has an identifier.
> >>      - One document per model: "ModelX". Each model includes a reference
> to
> >>      its manufacturer.
> >>   - Option 2
> >>      - One document for all the manufacturers: "Manufacturers". It
> includes
> >>      a list of manufacturers. Each manufacturer points to a list of
> models.
> >>      - One document per manufacturer: "ListOfModels". It includes all
> the
> >>      models for a given manufacturer.
> >>
> >> *Doubt 2 (logs)*
> >>
> >>   - Option 1
> >>      - One document per DebugLog: "DebugLogX".
> >>   - Option 2
> >>      - One document per application life cycle:
> >>      "DebugLogsDuringApplicationLifeCycleX". It includes all the debug
> logs
> >>      created by the application during its life cycle. An application
> >> life cycle
> >>      might takes from just a few seconds to some hours.
> >>
> >> *Doubt 3 (user, mobile and profile)*
> >>
> >>   - Option 1
> >>      - One document per profile: "ProfileX". It includes information
> about
> >>      the mobile device and the user.
> >>   - Option 2
> >>      - One document per user: "UserX"
> >>      - One document per device: "DeviceX"
> >>      - One document for all the profiles: "Profiles". It contains a list
> of
> >>      profiles, each one pointing to its associated user and device.
> >>
> >>
> >> *Doubt 4 (manufacturer errors)*
> >>
> >>   - Option 1
> >>      - One document for all the errors. Each error is associated to its
> >>      manufacturer.
> >>   - Option 2
> >>      - One document per manufacturer: "ManufacturerXErrors".
> >>
> >>
> >> I would appreciate any piece of advice.
> >>
> >> Thanks in advance and congrats for your project,
> >>
> >>
> >> [1]
> >>
> >>
> http://www.amazon.com/Beginning-CouchDB-ebook/dp/B003U890N2/ref=sr_1_10?ie=UTF8&qid=1307691243&sr=8-10
> >> [2]
> >>
> >>
> http://www.amazon.com/CouchDB-Definitive-Guide-Animal-ebook/dp/B0043D2E9U/ref=sr_1_3?ie=UTF8&qid=1307691243&sr=8-3
> >>
> >
> >
> >
> > --
> > “The limits of language are the limits of one's world. “ -Ludwig von
> > Wittgenstein
> >
>



-- 
“The limits of language are the limits of one's world. “ -Ludwig von
Wittgenstein

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message