Do you seriously believe that you can rely your business solution which will run across dozen of PCs on someones experiment?
NoSQL v. SQL is the worst holy war ever.
11–20 of 59 posts
Re: NoSQL v. SQL is the worst holy war ever.
#12Recently 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…
Re: NoSQL v. SQL is the worst holy war ever.
#13Recently 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…
Re: NoSQL v. SQL is the worst holy war ever.
#14Recently 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…
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.
But you and I appear to have very different needs.
Re: NoSQL v. SQL is the worst holy war ever.
#15NoSQL is designed to address a certain problem space and RDBMS is designed to address another. I don't see it that way at all. It's more like RDBMS is the all-purpose data store that attempts to distill the maximum number conceivable data storage, integrity constraints and lookup requirements into a set of powerful primitives. And NoSQL is a large group of technologies that are each optimized for specific cases which…
It's like my experience with SVN vs Git. I didn't know how useful and more efficient my workflow would be if I used branches, so I never saw why Git was useful. Sure I could branch in SVN, but it was way more work. I got involved in a project where I had to use git, and I learned how branching works, and now I use it all the time because I understand where it's applicable.
I don't think you have to choose MySQL over MongoDB. I think you could be very happy using both, each for its purpose. You don't always know why you need something until you need it. It's always good to keep an eye on what others are doing.
Re: NoSQL v. SQL is the worst holy war ever.
#16I'm going to declare something else the worst holy war ever. Then we can have an even worse holy war than ever was before, making ourselves both wrong.
There. Problem solved. Unless you wanna kill a few hundred thousand people and go to war for a few hundred years.
(If I'd said "The holocaust", I could've Godwinned this thread, but that wasn't really a holy war.)
Re: NoSQL v. SQL is the worst holy war ever.
#17Earlier quoted context omitted.
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.
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.
Re: NoSQL v. SQL is the worst holy war ever.
#18Recently 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…
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.
Re: NoSQL v. SQL is the worst holy war ever.
#19Recently 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…
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.
Re: NoSQL v. SQL is the worst holy war ever.
#20Recently 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…
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-so…