3 ms·
These heroku guys are selling something. They're on a bandwagon, constantly bashing SQL databases. I'd say SQL Databases are great for 90% of information based
by pj 17y ago
These heroku guys are selling something. They're on a bandwagon, constantly bashing SQL databases. I'd say SQL Databases are great for 90% of information based systems.
The problem you are going to run into, I know a company they wanted a particular database, so they got a designer turned programmer who built a system for them in Perl using flat files. His architecture was to put one data field per line in a file and then put the one-to-many records, comments about the master record in the file starting at line x. Well, now they have fields for the master item all the way to line x minus 2 and they know they want like 5 more fields.
If the developer who built the system had started on an SQL database, then the solution to the problem of needing more fields would be really simple.
Now this problem is just one issue. Add to this the problem of needing to query the master records on particular fields. The programmer has to open up every single file and go to the particular line where the field exists and see what the value is. Of course as the file based database grows, it's really starting to impact performance.
The big problem here is that the original programmer didn't know SQL or how to manage a SQL database so he downloaded some Perl code (note, I absolutely LOVE perl, so don't be hating) that managed a dataset in perl and just went to town.
This is not the way to build a robust information based system.
SQL databases are a tool and files are a tool and CouchDB is a tool and a lot of people are going to read this biased stuff about noSQL and think, "hey, let's use couchdb, et al" and they only have 5 users on the system and, you know, maybe a million records and Access, MySQL, SQL Server Express, or any number of other free sql based systems would handle a problem like that just fine.
Instead, they're going to go write a ton of code to fit a key/value store to the problem and it's going to be a nightmare to support as the system grows and they need to implement security and manage more fields.
But the pro-noSQL people don't talk about all those issues that are going to arise later and focus solely on the scalability issue when in the vast majority of cases scalability is really the last thing you need to think about.
- sho 17y agoWhile I agree 100% with your point that people need to think carefully about their actual needs and not just follow the hype of the moment, comparing "NoSQL" databases to someone writing flat files in Perl is a bit harsh! Using SQL these days, with modern ORMs, is if anything quite a lot easier than manipulating flat files. And that's the problem! SQL is the new "flat file", the hammer every programmer knows, so you know what every problem starts to look like.
- pj 17y agoYes, that was a bit harsh, but the point I'm trying to make is that the noSQL proponents aren't really talking about PRO-couchDB, they just keep hammering on how "bad" SQL is, when it's really frickin' awesome.
- sho 17y agoIt's unfortunate the conversation seems to have taken that turn, yes. I don't like the term "NoSQL", which is why I put it in quotes. SQL is a fantastic tool, so is Couch et al .. I don't understand why people need to "declare" for one side or the other. Ah well, human nature I suppose.
- pj 17y agoyep, that declaration is crazy. They're all good tools. Use the right tool for the job. I think part of the issue really, unfortunately, is that SQL is tough. It's not taught in colleges very much. I learned it on the job. I never learned anything about SQL in college and it's not something you can just jump into, but a key/value pair is easy. Anyone who has taken a data structures class is going to understand it. It's basic programming. You gotta kinda wrap your mind around SQL though and if you don't have a support group helping you do that, you're probably going to struggle with it. So I can understand the desire to find a simpler alternative to solve information based systems, something between file based Perl and SQL.
- sho 17y agoThe funny thing is, I always thought SQL was very easy to understand, at least enough for basic use, which will carry you a long way. It's very clean and logical and conforms well to my intuitive concept of object relationships. Sure I've had frustrating moments trying to comprehend some hideous join or wondering why some query doesn't work but I never thought SQL itself was particularly hard to get started with. Map/reduce, though, that will do your head in! It's like changing from procedural to functional programming. To me, it's much harder and far less intuitive. So I can't imagine how anyone could think using M/R is somehow easier than learning SQL. Anyone who thinks that is in for a nasty surprise. It's like claiming Erlang is easier to learn than Ruby.
- DanielBMarkham 17y agoThese heroku guys are selling something. They're on a bandwagon, constantly bashing SQL databases. And it's getting a little old. No solution works for everything all the time. Can we just stipulate that?