incubator-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:29:39 GMT
Certainly not transactional, but the all_or_nothing option sounds very
useful so long as you understand that conflicts will occur and are already
handling those. Which is of course something you'll need to think about if
replication is involved as well.

Alternatively I see value in the default mode where you get back the results
for each document and then can turn around and handle the problems.

Thanks for bringing that up. My memory of the all_or_nothing was incorrect.
I haven't actually used that feature, but still want to keep my awareness
up.

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

> Yes, that's what I mean. The word "transactional" means far more than
> "sent in the same HTTP request". :)
>
> B.
>
> On 10 June 2011 14:16, Sean Copenhaver <sean.copenhaver@gmail.com> wrote:
> > 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
> >
>



-- 
“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