NoSQL v. SQL is the worst holy war ever.
deserettechnology.com
NoSQL v. SQL is the worst holy war ever.
1–10 of 59 posts
Re: NoSQL v. SQL is the worst holy war ever.
#2The whole idea with "NoSQL" is that you pick the best tool for the job. Most people that push RDBMS solutions try to shoehorn an RDBMS for every possible scenario. For modeling the majority of business data, an RDBMS is fine. There are many problems such as graphs, logs, lossy real-time data, etc that CAN be modeled in an RDBMS but shouldn't be.
Re: NoSQL v. SQL is the worst holy war ever.
#3I'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.
Re: NoSQL v. SQL is the worst holy war ever.
#4What it boils down to is choose the right tool for the job and sometimes that means using two tools that do similar things. I for one won't be giving up SQL any time soon but also look forward to replacing some of our poorly performing sections with NoSQL (we sort of already do thanks to memcache).
Re: NoSQL v. SQL is the worst holy war ever.
#5NoSQL 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 SQL is traditionally bad at, but which don't necessarily have much in common with each other.
Re: NoSQL v. SQL is the worst holy war ever.
#6The first comment on that post is quite hilarious.
Re: NoSQL v. SQL is the worst holy war ever.
#7The whole idea with "NoSQL" is that you pick the best tool for the job. Most people that push RDBMS solutions try to shoehorn an RDBMS for every possible scenario. For modeling the majority of business data, an RDBMS is fine. There are many problems such as graphs, logs, lossy real-time data, etc that CAN be modeled in an RDBMS but shouldn't be.
I largely agree with this, but in my mind using an RDBMS for a sub-optimal task is not always shoehorning—it can be a powerful hedge. In an early stage startup you don't know what the final business model is going to be, or how your data will need to scale. Spending time researching and setting up optimized data stores for things that change drastically or never end up being important is a tremendous waste of time.
Re: NoSQL v. SQL is the worst holy war ever.
#8I don't know. I think any holy war in which people aren't killed is pretty good as far as holy wars go.
Re: NoSQL v. SQL is the worst holy war ever.
#9The first comment on that post is quite hilarious.
[deleted]
Re: NoSQL v. SQL is the worst holy war ever.
#10The whole idea with "NoSQL" is that you pick the best tool for the job. Most people that push RDBMS solutions try to shoehorn an RDBMS for every possible scenario. For modeling the majority of business data, an RDBMS is fine. There are many problems such as graphs, logs, lossy real-time data, etc that CAN be modeled in an RDBMS but shouldn't be.
>Most people that push RDBMS solutions try to shoehorn an RDBMS for every possible scenario.
I don't think that's true for well-informed developers in a space where NoSQL is acceptable.
It might be true generally only in the sense that most developers don't know or care about NoSQL and don't like the idea of learning something new. That's to be expected; most of these guys will never leave .NET/Java and the blessed toolkits associated with each. They are corporate programmers and they don't really count.
A well-informed person might make some good social arguments against NoSQL adoption, like the lack of experienced available developers, or the relative immaturity of the respective codebase, or other issues that surround emerging platforms. These arguments will sometimes hold merit.
Otherwise, I don't know why one would be averse to the implementation of a "NoSQL" datastore for information like logs. I know that I've always having logs in the relational db.
I haven't met many experienced, decent developers who shun NoSQL when there is a good technical and environmental atmosphere for its implementation. I don't think it's a widespread thing.