Search code examples
sql-servermongodbrdbmsrelationaldb4o

Moving webshop storage to NoSQL solution

If you had a webshop solution based on SQL Server relational DB what would be the reasons, if any, to move to NoSQL storage ? Does it even make sense to migrate datastores that rely on relations heavily to NoSQL? If starting from scratch, would you choose NoSQL solution over relational one for a webshop project, which will, after a while, again end up with a bunch of tables like Articles, Classifications, TaxRates, Pricelists etc. and a magnitude of relations between them?

What's the support like in .NET (4.0) for MongoDB or MongoDB's support for .NET 4.0? Can I count on rich code generation tools similar to EF wizard, L2SQL wizard etc. for MongoDB?

Because as what I have read so far, NoSQL's are mostly suited for document storage, simpler object models.

Your answer to this question will help me make the right infrastructure design decisions.

UPDATE: If I was developing my solution around ASP.NET MVC and rely heavily on Model classes, would it be the easiest way to go to choose DB4o to simply serialize and deserialize my objects to and from datastore?

Solution

  • Well quite a open-ended question.

    Migration to a NoSQL-datastore for an existing software

    Well often there's a lot of experience and knowledge for the existing relational technologies. When you're application runs fine, its probably not worth the effort. However when you have unsolvable issues with the current solution, then it's an option.

    Does it even make sense to migrate datastores that rely on relations heavily to NoSQL?

    Well you have to consider that the three technologies (Document-DB, RDBMS, Object Database) are very different from each other.

    • In the relational world you normalize data and join them at runtime together. This works fine, as long as the data-sizes are not to big. Here often the issues starts: When you have lot of normalized data you need to do a lot of joins, which costs a lot of performance. And of course mapping between your objects and your tables can be quite tricky.
    • In a object-database the each object is stored individually and the 'relations' are stored in forms of pointers. So when a object A has a reference to object B, the object-database stores this reference. So to retrieve the 'relation', no join operations are necessary. Therefore 'relations' are cheap. In conclusion object-databases are really good at handling relations.
    • In a document-database like MongoDB a complete object-graph is stored as a document. The document-database works with a the document-level. So here there are no real 'relations'. You normally just store/load documents. So when you can model you scenarios so that most of your operations only work on a single document, it's very performant and easy.

    Here's a good blog-post which compares the design-difference of MongoDB (document database) and db4o (object-database)

    In the end you model should fit to your database. For example, don't try to use a model for a relation database and store it 1:1 in a document database. See also Ayende's blog about modeling for a object-database.

    What's the support like in .NET (4.0) for MongoDB or MongoDB's support for .NET 4.0?

    Gates VP has already answered this for MongoDB. The .NET 4.0-version of db4o is in development. Meanwhile the 3.5 version also works fine on the 4.0 framework.

    Can I count on rich code generation tools similar to EF wizard, L2SQL wizard etc. for MongoDB?

    For both, MongoDB and db4o you don't need to generate code. Your classes are the schema. You just store you objects and the database takes care of the rest. See also Gates VP answer

    Because as what I have read so far, NoSQL's are mostly suited for document storage, simpler object models.

    Well the range is quite big. From really simple key-value-stores, to more advanced document-databases, colum-oriented-databases, graph-databases and object-databases.

    Of course the document-database work excellent when you have store document-like data (for example a blog-software). While graph- and object-databases are good at handling extreme complex data structures.