couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From svilen ...@svilendobrev.com>
Subject Re: Beginners approach of designing documents
Date Mon, 16 Sep 2013 11:52:11 GMT
> My feeling says it will take me some more time to change my relational
> thinking into a NoSQL one. Feels a bit like learning OOP after working
> with functional code for a long time. :-(
exactly. or like Prolog vs procedural.
took me half-an-year to switch, and learns some pros/cons.

i would put separate notions in separate objects/docs. 
The more changeable pointing to less changeable.
But it all depends on volume and needs. Don't put extra
(artificial?) borders/limits where u don't needs them because it will be
hard to respect them. But make sure borders exist where they are needed.

Start with something, doesn't matter what, play with all
reasonably-important usages, then re-decide again. 
That is - prototype a lot, and don't hesitate to throw away and
re-start.

have fun
svilen


On Mon, 16 Sep 2013 13:20:44 +0200
Christian Grobmeier <grobmeier@gmail.com> wrote:

> Thank you Svilen and Robert for your responses.
> Apologizes for the top post. When I understand you correctly and apply
> this to my book store, i could create following databases:
> 
> - books (main source for books)
> - u11234 (a customer)
> - u11235 (another customer)
> - u... (a lot of other customers, maybe thousands)
> 
> While my books database would maybe have that:
> 
> {functional:"my-book", title:"my title", ... }
> 
> A customer would look like this:
> 
> {email : "john@example.com", pass : "hashed", salt : "salt",
>    books : [
>      {functional:"my-book", title:"my title", ... },
>      {functional:"second-book", title:"another title", ... }
>      ...
> ] }
> 
> Probably I could create a single database for all customers that way.
> Of course, then I would think twice with authentication which seems
> to work for databases, not for rows.
> http://guide.couchdb.org/editions/1/en/security.html
> 
> Replication seems to be the powertool in NoSQL world.
> Of course the drawback is when I would update the book and maybe
> change it's description. In this case I would need to update all my
> customers too.
> 
> My feeling says it will take me some more time to change my relational
> thinking into a NoSQL one. Feels a bit like learning OOP after working
> with functional code for a long time. :-(
> 
> Cheers
> Christian
> 
> 
> 
> 
> Am 16.09.13 12:53, schrieb Robert Newson:
> > A database per user is not unusual, don't fear it.
> > 
> > As for the users aspect, we have this built-in as the _users
> > database, it would be inappropriate to implement a new auth system
> > when one exists.
> > 
> > B.
> > 
> > On 16 Sep 2013, at 11:48, svilen <az@svilendobrev.com> wrote:
> > 
> >> It depends what are the goals of the usage. And who/what is doing
> >> the user-dispatch (access/rights).
> >> * if u need all the books of all users, u should somehow get them
> >> all together in one db (does not mean The only db).
> >> * if u need each user to access (and replicate) only hir stuff,
> >> then keep it in separate db. Or keep them all together and make the
> >>   access-control on top of it, outside couchdb (but no
> >>   easy replication).
> >> * u can keep same thing on multiple places. via internal
> >>   replications, auto or manual.
> >> * replications are easy in couchdb. relations are not that easy.
> >>
> >> For your case u can put everything in one db (or 2, or 3, depending
> >> on your wish, but not data-needs), thus couchdb being just a
> >> server-only data-storage, and then make all user-access related
> >> stuff/filtering on top. U can have sort-a relations by putting both
> >> ends of relation in single view, then ordering/grouping them.
> >>
> >> If u later need per-user replication (e.g. move to mobile, so users
> >> can have their stuff on their devices), u can organise extra
> >> internal per-user db that is replicating only that-user stuff
> >> from/to main db. And then replicate that one to external world.
> >> But i guess this is too far.
> >>
> >> ciao
> >> svilen
> >>
> >> On Mon, 16 Sep 2013 11:30:13 +0200
> >> Christian Grobmeier <grobmeier@gmail.com> wrote:
> >>
> >>> Hi all,
> >>>
> >>> for more than a decade I used relational databases. For a tiny
> >>> project I would like to try NoSQL and CouchDB and see for myself
> >>> why people are so fond of it. For me it is not much about tons of
> >>> data. I am using AngularJS and PHP and thought a schemaless
> >>> database would fit nicely.
> >>>
> >>> While I think I found the approach for most of my app, I am unsure
> >>> about one specific thing. I would like to enable my users to
> >>> register and add a book to their personal collection.
> >>>
> >>> My approach would be to create a database with books first. Like:
> >>>
> >>> {_id: 1, functional:"my-book", title:"my title", ... }
> >>>
> >>> Second I would like to create a database with my users, like:
> >>>
> >>> {_id: 20, email : "john@example.com", pass : "hashed", salt :
> >>> "salt", books : [ 1, 2, 3, 4 ...] }
> >>>
> >>> When a user logs in, I would like to search for him by email and
> >>> check user credentials. When it succeeds I would look up all the
> >>> books in his collection.
> >>>
> >>> On the net somebody wrote I should create a database per user. But
> >>> this seems completely wrong to me. Right?
> >>>
> >>> I am a little concerned because I am referencing books from my
> >>> user object. Is this the right approach?
> >>>
> >>> Or do I miss something?
> >>>
> >>> Glad over all links, points, hints and so on.
> >>>
> >>> Thanks!
> >>> Christian
> > 
> 

Mime
View raw message