> 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 <[email protected]> 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 : "[email protected]", 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 <[email protected]> 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 <[email protected]> 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 : "[email protected]", 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 > > >
