StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>There are three possible options, each with pros and cons.</p> <h3>Reuse the RDBMS</h3> <p>You're already storing the entities in a relational database. You can store the undefined attributes in an extra table, that has a <code>Key</code> and <code>Value</code> column, and an <code>EntityId</code> column that references the entity to which the attributes belong. Basically, you'll be using part of your database as a key-value store.</p> <p>Advantages:</p> <ul> <li>All your data is stored in a single database, meaning: <ul> <li>you can retrieve an entity and all of its attributes in a single query,</li> <li>your application is less complicated, as it only has to interact with a single database.</li> </ul></li> <li>You get all the ACID advantages of a relational database.</li> </ul> <p>Disadvantages:</p> <ul> <li>Relational databases aren't built to be key-value stores, so you may have performance issues. However, I expect the performance hit to be minimal, unless you plan to store a very, very large amount of attributes.</li> </ul> <h3>Use a key-value store</h3> <p>Key-value stores, such as <a href="http://code.google.com/p/redis/" rel="nofollow noreferrer">Redis</a> and <a href="http://wiki.basho.com/display/RIAK/Riak" rel="nofollow noreferrer">Riak</a>, or the more advanced <a href="http://cassandra.apache.org/" rel="nofollow noreferrer">Apache Cassandra</a>, are optimized for storing key-value pairs (no surprise there...). You can use a key-value store next to your RDBMS, dedicated to storing the attributes, while keeping the entities in your RDBMS.</p> <p>Advantages:</p> <ul> <li>Better performance than you'll get from a RDBMS, especially with large amounts of data.</li> <li>Easier to scale out, as they are not constrained by ACID properties.</li> </ul> <p>Disadvantages:</p> <ul> <li>No guaranteed ACID properties but so-called <a href="http://en.wikipedia.org/wiki/Eventual_consistency" rel="nofollow noreferrer">eventual consistency</a>, meaning that the stored data may not always be consistent across servers. However, you'll only have to deal with this if you're scaling out. Also, most key-value stores allow you to tune its strictness regarding consistency, to help overcome this problem.</li> <li>Your application will run on two separate databases, increasing the complexity of your application.</li> </ul> <h3>Use a document database</h3> <p>You could use a document database to store just the attributes. But you can also take the plunge and store everything in a document database, including your entities.</p> <p>Advantages:</p> <ul> <li>All your data is stored in a single database, meaning: <ul> <li>you can retrieve an entity and all of its attributes in a single operation, as you would store an entire entity, including its attributes, in a single document.</li> <li>your application is less complicated, as it only has to interact with a single database.</li> </ul></li> <li>Easier to scale out, as they are not constrained by ACID properties.</li> <li>Document databases aren't restricted to just key-values, so if you ever need to store a more complex attribute, you're already good to go.</li> </ul> <p>Disadvantages:</p> <ul> <li>No ACID guarantees, just like key-value stores. Most document databases can be tuned to overcome consistency problems though.</li> <li>No understanding of relations between entities as in an RDBMS. A relational model is normalized, whereas documents are denormalized, to overcome having many relations. This may or may not be a big disadvantage, depending on your exact domain model.</li> </ul> <h3>Mature document database technologies</h3> <p><a href="http://couchdb.apache.org/" rel="nofollow noreferrer">Apache CouchDB</a> has <a href="http://wiki.apache.org/couchdb/CouchDB_in_the_wild" rel="nofollow noreferrer">quite a list of applications</a> using it and receives <a href="https://stackoverflow.com/questions/895762/mongodb-or-couchdb-fit-for-production">positive feedback</a> from the Stack Overflow community. It has a few <a href="http://wiki.apache.org/couchdb/Getting_started_with_C%23" rel="nofollow noreferrer">drivers for .NET</a>, but I can't tell you how mature these drivers are.</p> <p>MongoDB has quite an impressive <a href="http://www.mongodb.org/display/DOCS/Production+Deployments" rel="nofollow noreferrer">list of production employments</a>. There are three major <a href="http://www.mongodb.org/display/DOCS/C+Sharp+Language+Center" rel="nofollow noreferrer">drivers for .NET</a> available, which all seem to be of <a href="https://stackoverflow.com/questions/2735246/what-is-the-most-mature-mongodb-driver-for-c">good quality</a>.</p> <p>RavenDB has excellent support for .NET as it was designed for the .NET platform. However, I haven't been able to find examples of large production environments running on RavenDB. Still, I think it's definitely worth exploring.</p> <p>I don't have much hands-on experience with any of them in production environments, so I don't know exactly how easy they are to backup/restore. But given the fact that these NoSQL systems aren't as rigid as RDBMS systems, I guess they should be easier to backup/restore without downtime than an RDBMS.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload