[MUSIC] So that's all I want to say about this grid. But let me give you a little bit of a character of a response to NoSQL by Mike Stonebraker in Communications of the ACM. And there was a couple of different blog posts here that talked about two different arguments in favor of NoSQL, and they responded to each one of those arguments. And so I'm mostly gonna focus on the second one. So those two pro NoSQL arguments are these. Research points out that there's two value propositions offered by the NoSQL community. One is performance, and the story as Mike says that I more or less agree with. Is that these people started out with a MySQL deployment of some kind and they had a hard time scaling it out in a distributed environment, and then they had two choices. Either they could invest in a large scale relational database and pay, of course, many license fees. Or they could do something different, use one of these NoSQL systems. All right. And then the flexibility argument is like, well look, my data doesn't conform to a rigid schema. So in the performance argument, I'm not gonna spend too much time on this because we talked about the trade offs associated with different choices in transactional guarantees in these various systems. And the other part of the argument that Mike makes has more to do with database internals that we didn't necessarily cover. So let me focus on the flexibility argument. So, an observation that he makes that I think I'd probably agree with is that, who are the customers of these NoSQL systems? And so it's a lot of startups, and a lot of web startups and it's not quite the such same penetration in the enterprise. Okay, at least not yet. So why is this? Well, one argument is that most of the applications in the enterprise are traditional OLTP and if you don't know OLTP means online transaction processing. And so these are sort of bank records, all right things where doing the transaction right really matters. Okay, further OLTP on structured organized data. And so ther's a few other applications around the edges, but they're perhaps considered less important. It's okay to take a high risk system because the application itself is of less interest to executives. And so really, no asset compliance, no transactions is equivalent to not much interest in the system. It's not okay to screw up mission-critical data, but for that app, but for some other application on the EDGE, maybe it's okay to experiment with a NoSQL system. Okay, then another, second point he makes is that, relying on these low level query interfaces is a real tough sell. And he calls up CODASYL, which is an early data manipulation language that predated the declarative languages that we've been talking about. But we've sort of been down that road, and it's tough, and it's why these higher-level languages were invented. And again we see it with Map Reduce which is admittedly analytics as opposed to pure NoSQL. But we see that the value of these higher level interfaces pays off, okay. And then the third point he makes is that you know, NoSQL means all bets are off, right. There's no sort of homogeneity between all these different deployments. And so in a typical enterprise you have, you know, maybe 10,000 databases. You already have enough of a trouble trying to integrate data from these databases because of the heginata within their schemas. But at least you know that you're always working with rows and columns and at least you have kind of a standard interface to manipulating them. And so having the number of design decisions that you have to make to encode your data in one of these NoSQL systems, what becomes the key, what becomes the value? Are the blog posts nested under the comments, or the comments nested under the blog posts? Do users keep their own wall or do the messages on their front page, or does the person who wrote the message keep access to it, or both? Right, all these different design decisions of nesting layers and so forth complicate integration and complicated standards, okay. So it's a tough sell, the other point that I guess I like to make that's related to this one here is that there's no real free lunch, right? Either the complexity's gonna be in the system that you use to model the data, or you're gonna sort of hand it over to the application. But in some sense they're always, these schemas, right, this application business model is gonna be encoded somewhere. So having it centralized in the data system as opposed to hidden more than once in various applications, it acts as the data system seems like a good idea, okay. [MUSIC]