I’m new to CouchDB, and much more accustomed to relational databases, so please excuse any naivety in this question.
I’m going to dive right in a build an iOS app using CouchDB instead of iCloud, but before I do so, I’d just like to clarify a few fundamentals if I may: The app is a simple idea, designed to help management of large classes in University: A tutor creates a classroom session with a unique session id; students sign in and join the session using the session id; when students have a question, they tap a button (join the queue) - the teacher(s) can then help students in order (so it’s fair etc..). 1. I'm assuming the client app will connect directly to CouchDB, as there is little motivation to write any middleware - unless I’m missing something here? 2. What is the best practise for managing users and sign-in? There is the notion of ‘users’ in couch, but I’m unclear where they fit into the greater scheme of things. For a traditional middleware + SQL server, there would typically be one database user with imposed limited privileges (for security, no drop table etc..), and end-user credentials would be hashed and stored in tables by the middleware. Is the model similar in CouchDB, or more fluid? I could also use client side encryption and store student credentials in a single document (as described in the Wiki). May thanks in advance, Nick ________________________________ [http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass> This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, Plymouth University accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. Plymouth University does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.
