couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Beginners approach of designing documents
Date Mon, 16 Sep 2013 10:53:12 GMT
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