Can .NET (managed code) read and write to CouchDB? 

I would like to build a part of my project that does document management using CouchDB

Use CouchDB with .NET

I&#39;m currently designing an architecture for a web-based application that should also provide some kind of image storage. Users will be able to upload photos as one of the key feature of the service. Also viewing these images will be one of the primary usages (via web). 

However, I&#39;m not sure how to realize such a scalable image storage component in my application. I already thought about different solutions but due to missing experiences, I look forward to hear your suggestions. Aside from the images, also meta data must besaved.
Here are my initial thoughts:

1. Use a (distributed) filesystem like HDFS and prepare dedicated webservers as &quot;filesystem clients&quot; in order to save uploaded images and service requests. Image meta data are saved in a additional database including the filepath information for each image. 

2. Use a BigTable-oriented system like HBase on top of HDFS and save images and meta data together. Again, webservers bridge image uploads and requests. 

3. Use a completly schemaless database like CouchDB for storing both images and metadata. Additionally, use the database itself for upload and delievery by using the HTTP-based RESTful API. (Additional question: CouchDB does save blobs via Base64. Can it however return data in form of image/jpeg etc.)?  


Scalable Image Storage

I haven&#39;t got my hands dirty yet with neither [CouchDB][1] nor [MongoDB][2] but I would like to do so soon... I also have read a bit about both systems and it looks to me like they cover the same cases... Or am I missing a key distinguishing feature?

I would like to use a document based storage instead of a traditional RDBMS in my next project. I also need the datastore to 

- handle large binary objects (images and videos)
- automatically replicate itself to physically separate nodes
- rendering the need of an additional RDBMS superfluous

Are both equally well suited for these requirements? 

Thanks!


  [1]: http://couchdb.apache.org
  [2]: http://www.mongodb.org

Are MongoDB and CouchDB perfect substitutes?

What are the best practices for NoSQL Databases, OODBs or whatever other acronyms may exist for them?

For example, I&#39;ve often seen a field &quot;type&quot; being used for deciding how the DB document (in couchDB/mongoDB terms) should be interpreted by the client, the application.

Where applicable, use PHP as a reference language. Read: I&#39;m also interested in how such data can be best handled on the client side, not only strictly the DB structure. This means practically that I&#39;m also looking for patterns like &quot;ORM&quot;s for SQL DBs (active record, data mapper, etc).

Don&#39;t hesitate making statements about how such a DB and the new features of PHP 5.3 could best work together.

NoSQL best practices

Are there any essential differences between [CouchDB][1] and [Couchbase][2].


  [1]: http://couchdb.apache.org/
  [2]: http://www.couchbase.com/

Difference between CouchDB and Couchbase

Why should I use document based database like CouchDB instead of using relational database.
Are there any typical kinds of applications or domains where the document based database is more suitable than the relational database?

Why should I use document based database instead of relational database?

What are the advantages of using NoSQL databases? I&#39;ve read a lot about them lately, but I&#39;m still unsure why I would want to implement one, and under what circumstances I would want to use one.

When should I use a NoSQL database instead of a relational database? Is it okay to use both on the same site?

I am a complete noob when it comes to the NoSQL movement.  I have heard lots about MongoDB and CouchDB.  I know there are differences between the two.  Which do you recommend learning as a first step into the NoSQL world?

NoSQL - MongoDB vs CouchDB

I am stuck between these two NoSQL databases. 

In my project I will be creating a database within a database. For example, I need a solution to create dynamic tables. 

So users can create tables with columns and rows. I think either MongoDB or CouchDB will be good for this, but I am not sure which one. I will also need efficient paging as well.


When to use CouchDB over MongoDB and vice versa

NoSQL has been getting a lot of attention in our industry recently. I&#39;m really interested in what peoples thoughts are on the best use-cases for its use over relational database storage. What should trigger a developer into thinking that particular datasets are more suited to a NoSQL solution. I&#39;m particularly interested in [MongoDB][1] and [CouchDB][2] as they seem to be getting the most coverage with regard to PHP development and that is my focus.


  [1]: http://www.mongodb.org/
  [2]: http://couchdb.apache.org/

Use cases for NoSQL

I am in the middle of designing a highly-scalable application which must store a lot of data. Just for example it will store lots about users and then things like a lot of their messages, comments etc. I have always used MySQL before but now I am minded to try something new like couchdb or similar which is not SQL.

Does anyone have any thoughts or guidance on this?

SQL (MySQL) vs NoSQL (CouchDB)

I have a question that I&#39;ve been trying to answer for some time now but can&#39;t figure out:

How do you design, or divide up, CouchDB documents?

Take a Blog Post for example.

The semi &quot;relational&quot; way to do it would be to create a few objects:

- Post
- User
- Comment
- Tag
- Snippet

This makes a great deal of sense.  But I am trying to use couchdb (for all the reasons that it&#39;s great) to model the same thing and it&#39;s been extremely difficult.

Most of the blog posts out there give you an easy example of how to do this.  They basically divide it up the same way, but say you can add &#39;arbitrary&#39; properties to each document, which is definitely nice.  So you&#39;d have something like this in CouchDB:

- Post (with tags and snippets &quot;pseudo&quot; models in the doc)
- Comment
- User

Some people would even say you could throw the Comment and User in there, so you&#39;d have this:

 &lt;pre&gt;&lt;code&gt;
`post {
	id: 123412804910820
	title: &quot;My Post&quot;
	body: &quot;Lots of Content&quot;
	html: &quot;&lt;p&gt;Lots of Content&lt;/p&gt;&quot;
	author: {
		name: &quot;Lance&quot;
		age: &quot;23&quot;
	}
	tags: [&quot;sample&quot;, &quot;post&quot;]
	comments {
		comment {
			id: 93930414809
			body: &quot;Interesting Post&quot;
		} 
		comment {
			id: 19018301989
			body: &quot;I agree&quot;
		}
	}
}`
&lt;/code&gt;&lt;/pre&gt;

That looks very nice and is easy to understand.  I also understand how you could write views that extracted just the Comments from all your Post documents, to get them into Comment models, same with Users and Tags.

But then I think, &quot;why not just put my whole site into a single document?&quot;:

 &lt;pre&gt;&lt;code&gt;
`site {
	domain: &quot;www.blog.com&quot;
	owner: &quot;me&quot;
	pages {
		page {
			title: &quot;Blog&quot;
			posts {
				post {
					id: 123412804910820
					title: &quot;My Post&quot;
					body: &quot;Lots of Content&quot;
					html: &quot;&lt;p&gt;Lots of Content&lt;/p&gt;&quot;
					author: {
						name: &quot;Lance&quot;
						age: &quot;23&quot;
					}
					tags: [&quot;sample&quot;, &quot;post&quot;]
					comments {
						comment {
							id: 93930414809
							body: &quot;Interesting Post&quot;
						} 
						comment {
							id: 19018301989
							body: &quot;I agree&quot;
						}
					}
				}
				post {
					id: 18091890192984
					title: &quot;Second Post&quot;
					...
				}
			}
		}
	}
}`
&lt;/code&gt;&lt;/pre&gt;

You could easily make views to find what you wanted with that.

Then the question I have is, how do you determine when to divide the document into smaller documents, or when to make &quot;RELATIONS&quot; between the documents?

I think it would be much more &quot;Object Oriented&quot;, and easier to map to Value Objects, if it were divided like so:

 &lt;pre&gt;&lt;code&gt;
`posts {
	post {
		id: 123412804910820
		title: &quot;My Post&quot;
		body: &quot;Lots of Content&quot;
		html: &quot;&lt;p&gt;Lots of Content&lt;/p&gt;&quot;
		author_id: &quot;Lance1231&quot;
		tags: [&quot;sample&quot;, &quot;post&quot;]
	}
}
authors {
	author {
		id: &quot;Lance1231&quot;
		name: &quot;Lance&quot;
		age: &quot;23&quot;
	}
}
comments {
	comment {
		id: &quot;comment1&quot;
		body: &quot;Interesting Post&quot;
		post_id: 123412804910820
	} 
	comment {
		id: &quot;comment2&quot;
		body: &quot;I agree&quot;
		post_id: 123412804910820
	}
}`
&lt;/code&gt;&lt;/pre&gt;

... but then it starts looking more like a Relational Database.  And often times I inherit something that looks like the &quot;whole-site-in-a-document&quot;, so it&#39;s more difficult to model it with relations.

I&#39;ve read lots of things about how/when to use Relational Databases vs. Document Databases, so that&#39;s not the main issue here.  I&#39;m more just wondering, what&#39;s a good rule/principle to apply when modeling data in CouchDB.

Another example is with XML files/data.  Some XML data has nesting 10+ levels deep, and I would like to visualize that using the same client (Ajax on Rails for instance, or Flex) that I would to render JSON from ActiveRecord, CouchRest, or any other Object Relational Mapper.  Sometimes I get huge XML files that are the entire site structure, like the one below, and I&#39;d need to map it to Value Objects to use in my Rails app so I don&#39;t have to write another way of serializing/deserializing data:

 &lt;pre&gt;&lt;code&gt;
`&lt;pages&gt;
	&lt;page&gt;
		&lt;subPages&gt;
			&lt;subPage&gt;
				&lt;images&gt;
					&lt;image&gt;
						&lt;url/&gt;
					&lt;/image&gt;
				&lt;/images&gt;
			&lt;/subPage&gt;
		&lt;/subPages&gt;
	&lt;/page&gt;
&lt;/pages&gt;`
&lt;/code&gt;&lt;/pre&gt;

So the general CouchDB questions are:

1. What rules/principles do you use to divide up your documents (relationships, etc)?
2. Is it okay to put the entire site into one document?
3. If so, how do you handle serializing/deserializing documents with arbitrary depths levels (like the large json example above, or the xml example)?
4. Or do you not turn them into VOs, do you just decide &quot;these ones are too nested to Object-Relational Map, so I&#39;ll just access them using raw XML/JSON methods&quot;?

Thanks a lot for your help, the issue of how to divide up your data with CouchDB has been difficult for me to say &quot;this is how I should do it from now on&quot;.  I hope to get there soon.

I have studied the following sites/projects.

1. [Hierarchical Data in CouchDB](http://probablyprogramming.com/2008/07/04/storing-hierarchical-data-in-couchdb/)
2. [CouchDB Wiki](http://wiki.apache.org/couchdb/)
3. [Sofa - CouchDB App](http://github.com/jchris/sofa)
4. [CouchDB The Definitive Guide](http://books.couchdb.org/relax/)
5. [PeepCode CouchDB Screencast](http://peepcode.com/products/couchdb-with-rails)
6. [CouchRest](http://github.com/mattetti/couchrest)
7. [CouchDB README](http://svn.apache.org/repos/asf/couchdb/trunk/README)

...but they still haven&#39;t answered this question.

Principles for Modeling CouchDB Documents

I&#39;m looking for a database to pair with a node.js app. I&#39;m assuming a json/nosql db would be preferable to a relational DB [I can do without any json/sql impedance mismatch]. I&#39;m considering:

- couchdb
- mongodb
- redis

Anyone have any views / war stories re compatiability/deployability of the above with node.js? Any clear favorites?


node.js database

I know there are three different, popular types of non-sql databases.

- Key/Value: Redis, Tokyo Cabinet, Memcached
- ColumnFamily: Cassandra, HBase
- Document: MongoDB, CouchDB

I have read long blogs about it without understanding so much.

I know relational databases and get the hang around document-based databases like MongoDB/CouchDB.

Could someone tell me what the major differences are between these and the 2 former on the list?

Difference between Document-based and Key/Value-based databases?

I was wondering if anyone can tell me if *[MongoDB][1]* or *[CouchDB][2]* are ready for a **production** environment.  

I&#39;m now looking at these storage solutions (I&#39;m favouring MongoDB at the moment), however these projects are quite young and so I foresee that I&#39;m going to have to work quite hard to convince my manager that we should adopt this new technology.

What I&#39;d like to know is:

 1. Who is using MongoDB or CouchDB today in a production environment?

 2. How are you using MongoDB/CouchDB?

 3. What problems (if any) did you come across when you adopted this new storage mechanism (and how did you overcome them)?

 4. How did you deal with any migration issues that you had to deal with?

 5. Do you have any good/bad experiences with either of these solutions that you&#39;d like to share?


  [1]: http://www.mongodb.org/display/DOCS/Home
  [2]: http://couchdb.apache.org/

MongoDB or CouchDB - fit for production?

I need to do transactions (begin, commit or rollback), locks (select for update).
How can I do it in a document model db?

Edit:

The case is this:

  - I want to run an auctions site.
  - And I think how to direct purchase as well.
  - In a direct purchase I have to decrement the quantity field in the item record, but only if the quantity is greater than zero. That is why I need locks and transactions.
  - I don&#39;t know how to address that without locks and/or transactions.


Can I solve this with CouchDB?




Can I do transactions and locks in CouchDB?

I am currently using the same C# DTOs to pull data out of CouchDB, via LoveSeat which I am going to return JSON via an ASP MVC controller.

I am using the NewtonSoft library to seralise my DTOs before sending them down through the controller. 

However, as CouchDB also uses NewtonSoft it is also respecting the property level NewtonSoft attributes such as 

    [JsonIgnore]
    [JsonProperty(&quot;foo&quot;)]

Is there anyway to tell the newtonsoft library to ignore these attributes explicitly? LoveSeat allows me to provide my own implementation of IObjectSerializer, which gives me full control over netwonsofts JsonSerializerSettings. So, can I ignore the attributes by using those settings ? 

I ask as the only alternative I can see at this point, is to dupe my DTOs. While not that&#39;s not terrible, it isn&#39;t great either. 

The only other way I can see is to bring in my own version of the  Newtonsoft.Json source into my project, with a different assembly name etc etc. But this way madness definitely lies and I will just dupe the DTOs before I go down this road.

Newtonsoft ignore attributes?

What modules are you using to connect to your CouchDB server, in your Node.js applications? And why would you recommend whatever module you are using?

CouchDB and Node.js - What module do you recommend?

I&#39;ve been trying to see if I can accomplish some requirements with a document based database, in this case CouchDB.  Two generic requirements:  

 - CRUD of entities with some fields which have unique index on it  
 - ecommerce web app like eBay ([better description here][1]).

And I&#39;m begining to think that a Document-based database isn&#39;t the best choice to address these requirements. Furthermore, I can&#39;t imagine a use for a Document based database (maybe my imagination is too limited).  

Can you explain to me if *I am asking pears from an elm* when I try to use a Document oriented database for these requirements?


  [1]: https://stackoverflow.com/questions/299723/can-i-do-transactions-and-locks-in-couchdb

Pros/cons of document-based databases vs. relational databases

I&#39;m looking at both projects and I can&#39;t really see the difference

from Cassandra Site:
--------------------

&gt; Cassandra is a highly scalable, eventually consistent, distributed, structured key-value store...Cassandra is eventually consistent. Like BigTable, Cassandra provides a ColumnFamily-based data model richer than typical key/value systems.

from CouchDB Site:
------------------

&gt; Apache CouchDB is a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API. 


That said, I see the specific differences between each project as: access methods, written languages, etc. but to put AN EXAMPLE, when you talk about [SOLR][1] or [Sphinx][2] you know both are indexers with big differences but at the end are indexers.

Can I say here that Cassandra and CouchDB are non-relational databases that in some cases one can replace the other?


  [1]: http://lucene.apache.org/solr/
  [2]: http://sphinxsearch.com/

What is the difference between Cassandra and CouchDB?

How can I create regular, non-admin users in CouchDB?

Creating regular users in CouchDB

We&#39;re developing a really big project and I was wondering if anyone can give me some advice about what DB backend should we pick.

Our system is compound by 1100 electronic devices that send a signal to a central server and then the server stores the signal info (the signal is about 35 bytes long). How ever these devices will be sending about 3 signals per minute each, so if we do de numbers, that&#39;ll be 4.752.000 new records/day on the database, and a total of 142.560.000 new records/month.

We need a DB Backend that is lighting fast and reliable. Of course we need to do some complex data mining on that DB. We&#39;re doing some research on the MongoDB/Cassandra/Redis/CouchDB, however the documentation websites are still on early stages.

Any help? Ideas?

Thanks a lot!

What should I choose: MongoDB/Cassandra/Redis/CouchDB?

Is there technical documentation describing how replication between two Couches works?

What is the basic overview of CouchDB replication? What are some noteworthy characteristics about it?

What is the CouchDB replication protocol? Is it like Git?

First off, I&#39;m no pro.

In my quest to become a better developer I am trying to understand what is needed and how to accomplish creating a sign-up/login for an Ionic-Framework app.

Most of the single-page-applications (SPAs) handle authentication on a node server that is also serving up the HTML for the client. In my case the phone itself will be serving up the HTML so I am guessing I may be going up against some CORs issues.

I understand that the Ionic-Framework uses states and based [angular-client-side-auth][1] repo I should be authenticating whenever I am changing states in my app.

I have an initial app setup but now I am kind of confused where to go from here.

The tools I have at my disposal:

 - Node.JS Server -Thanks DigitalOcean (Should I be using this as a proxy to my DB?)
 - CouchDB server (Full stack here we come)

**Questions of mine:**

 

 1. What is the standard approach for authenticating when using hybrid apps?
 2. Should I be using Node.JS as a proxy to the database?
 3. Should I skip node.js and authenticate directly with the CouchDB server? (I&#39;ve heard of this)
 4. Am I going about this all the wrong way?
 5. What are my potential road-blocks? 
 6. How does CORS work with hybrid applications?
 7. Anything I&#39;m missing?

Thanks for helping me become a better developer.

  [1]: https://github.com/fnakstad/angular-client-side-auth

Authentication in Ionic/Cordova App

I am looking at CouchDB, which has a number of appealing features over relational databases including:

 - intuitive REST/HTTP interface
 - easy replication
 - data stored as documents, rather than normalised tables

I appreciate that this is not a mature product so should be adopted with caution, but am wondering whether it is actually a viable replacement for an RDBMS (in spite of the intro page saying otherwise - http://couchdb.apache.org/docs/intro.html). 

 1. Under what circumstances would CouchDB be a better choice of database than an RDBMS (e.g. MySQL), e.g. in terms of scalability, design + development time, reliability and maintenance.
 2. Are there still cases where an RDBMS is still clearly the right choice?
 3. Is this an either-or choice, or is a hybrid solution more likely to emerge as best practice?



When to use CouchDB vs RDBMS

&gt; **Possible Duplicate:**  
&gt; [What is the etymology of &amp;#39;slug&amp;#39;?](https://stackoverflow.com/questions/4230846/what-is-the-etymology-of-slug)  

&lt;!-- End of automatically inserted text --&gt;

In CouchDB definitive guide the author used key &quot;slug&quot; in a document.

    {
       &quot;title&quot;: &quot;Hello World&quot;,
       &quot;slug&quot;: &quot;hello_world&quot;
    }

What does &quot;slug&quot; mean and why is it used?


What does &quot;slug&quot; mean

I&#39;ve followed the [CouchDB](http://incubator.apache.org/couchdb/index.html) project with interest over the last couple of years, and see it is now an Apache Incubator project. Prior to that, the CouchDB web site was full of *do not use for production code* type disclaimers, so I&#39;d done no more than keep an eye on it. I&#39;d be interested to know your experiences if you&#39;ve been using CouchDB either for a live project, or a technology pilot. 

All Couchdb Solutions on Gang of Coders

Total of 27 Couchdb Solutions