couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <robert.new...@gmail.com>
Subject Re: Help with data modelling
Date Fri, 10 Jun 2011 13:21:20 GMT
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
>

Mime
View raw message