Call me old-fashioned, but I do not grok NoSQL databases.
The "No" in "NoSQL" is supposed to stand for "Not
only", supposedly. But I think people think of it as "NO SQL" like "look! No SQL in my codebase! Hah hah hah hah I got away from SQL! Yay!" Like... SQL is a bad thing?
OK, I know, SQL is terribly dorky. And there's the infamous object-relational impedance mismatch. Object Relational Mapping (ORM) frameworks try to overcome that, but they are tricky to get right.
But... when the ORM runs into difficulty, it's because there's a really real issue to grapple with. Here are some really real issues:
* How do you deal, in the most general way, with foreign key references? Let's say you have a course catalog database with tables named Course and Professor. Let's keep this simple and say that each Course has one Professor. Thus a Many-to-One relationship from Course to Professor, which, in a relational database, we deal with by having a professorID column in the Course table. OK. When we fetch a list of Courses into our application, do we just select from the Professor table? Then we just have the professorID for each Course, not the names of the Professors. If we're showing a listing, on which we want to show the professor names, a SELECT from Course could get followed up by 1,000 queries on the Professor table as each professorID is resolved. Or, do we do a join? That's the smart way to use the relational database. But how does the ORM know that in one context, when we get a bunch of Professor objects, we will be looking at Professor objects and should do a join, but in another context not?
* How do we cope with changes to the database schema? Maybe records created before some date are different, in terms of what data they contain.
When folks announce that they have developed some tremendous magical new tool that does away with all the headaches of SQL and ORM, often they've just swept the issues under the rug. They show off some demo that they've CRUD some data with nothing that looks like SQL involved like wheee!!! But the demo is so small it just doesn't run into any foreign key or versioning issues. Or the issues are so small they can be ignored.
Example, here's some sample code from my professor, who is teaching us the minimal basic getting started in MongoDB and the mongoose module:
var mongoose = require('mongoose')
var Schema = mongoose.Schema;
var courseSchema = new Schema({
courseNumber: String,
courseName: String,
courseDevelopers: [
{firstName:String, lastName: String}
]
});
// skipping buncha connection etc. code here...
course = new Course({
courseNumber: 'cs601',
courseName: 'Web Application Development',
courseDevelopers: [
{ firstName:'Eric', lastName:'Bishop'}
]
});
course.save();
Already I am screaming. As someone trained to think in terms of normalizing relational databases, I see a glaring hideous problem here. In case it's not obvious yet, let's go on:
course = new Course({
courseNumber: 'cs602',
courseName: 'Server Side Web Development',
courseDevelopers: [
{ firstName: 'Eric', lastName:'Bishop'},
{ firstName:'Suresh', lastName:'Kalathur'}
]
});
course.save();
AAAAAAAAaaaaaa!!! Seriously, you are going to have someone enter the name 'Eric Bishop' twice, for the two different Courses? No no no no. Not to mention the fact that that might not make for the most efficient data-entry UI; what if there's a spelling or hyphanization or whether one uses the midddle name discrepancy? Then we can't do a query relably for "what are all the classes taught by Eric Bishop?" What if there's more information we should have on each Professor? Seriously, do we have to explain the benefits of database normalization all over again?
Looking at the MongoDB documentation. Surely there's a way to attach existing ProfessorSchema documents from the Professor collection. But does that create a linkage in the database, or does it duplicate data? If 'Eric' 'Bishop' is updated to be 'Erin' 'Bishop' now in the Professor collection, is that reflected in the course listing when Course documents are fetched? In other words did they re-invent the join?
Well... sort of. There's the $lookup feature. Not sure how scalable that is for the full range of uses of the join concept.
Here's an article that stronly suggests to me that the NoSQL fad is a cooler of Kool-Aid:
http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
