[kmuzykov]

Recently I've researched all NoSQL databases(grpaph oriented to be precise). We're building a project which I think fits best in NoSQL solution. And I did not find any suitable solution. Either it doesn't a have client api(we're using .NET) other then REST or plain TCP/IP (and of course I don't have time to create my own API) Either this is just some project more like a school homework.

Do you seriously believe that you can rely your business solution which will run across dozen of PCs on someones experiment?

[simonw]

I actually think this says something interesting about .NET v.s. open source platforms. The new batch of NoSQL products are being developed almost exclusively in the open source world - they're written to run on *nix (Windows support, if it exists at all, is generally an after thought) and the client libraries that ship with them target the open source languages first. In this particular case, it feels like closed-source platforms are second class citizens.

I'll hazard a guess that one reason for this is that NoSQL systems are mainly designed for scalability, and free operating systems are significantly cheaper to scale than platforms with a license fee per node.

[kmuzykov]

Then this new holy war boils down to an good old *nix vs windows holy war, or open-source vs closed applications.

[simonw]

Absolutely - to my shame, I only appreciated the irony of re-hashing an older holy war on this thread after I'd posted the comment!

[gte910h]

No it doesn't. There just hasn't been a windows developer who cared enough to write the interface you want. That could be you if you care.

[bphogan]

I don't understand the problem with the client apis. If you're working with .net, you should have access to an xmlhttprequest library. Building and reading xml to talk to a REST api shouldn't require a specific API library. Unless of course you're just looking to avoid that step altogether and would rather just point, click, drag, and drop and get on with it.

[kmuzykov]

REST is too heavy for my needs. It generates a lot of traffic.

[kmuzykov]

Another problem is deployment, if I adopt some RDBMS system to my needs, then I already have a bunch of web hostings supporting this type of DB or I can use installer to deploy the DB, run a few scripts and everything is ready to run.

[bphogan]

Deployment isn't the issue with these - deployment can be automated just as easily as an RDBMS. Sometimes easier. It's trivial to throw up several instances of MongoDB for example. As for hosting solutions that support this stuff, well, I prefer VPSs that I control to shared hosting with Mysql for anything that's serious.

But you and I appear to have very different needs.

[kmuzykov]

I prefer VPSs too, but if you aim wider auditory you should at least try to support web hosting. With RDBMS it is easy. And with NoSQL it is almost impossible. Maybe this is just a matter of time, when NoSQL will be as much widely used as MS SQL for example, then maybe you will be able to use MongoDB in a web hosting.

[metachor]

But if one of the purported values of many NoSQL technologies is their benefit to scalability, and you are using this tech in your application because the app needs to scale, then does it make sense to deploy this ultra-scalable app on shared web hosting (regardless of whether they support NoSQL tech)?

[warfangle]

Deployment with, e.g., Neo4J involves simply telling the Neo4J library which path to use for its binary data files at initialization time. It finds a DB if it's there and uses it, otherwise it creates it. Applicable line of code from their wiki:

  GraphDatabaseService graphDb = new EmbeddedGraphDatabase( "var/graphdb" );

Of course, Neo4J is an embedded solution. It's quite different than using a separate server application.