3 ms·

I'm glad database technology with its deep (and provable) mathematical foundation like SQL is free from these distractions. I mean what if there was this huge p

I'm glad database technology with its deep (and provable) mathematical foundation like SQL is free from these distractions. I mean what if there was this huge push of Object-Relational Databases in the 1990s and 2000s, including XML-native databases? I mean what if there was this massive claim that normalization is just an old man's fetish, and a bunch of geniuses figured out you could store things in memory and flat files like the punch card days? And then they created this huge buzz on hash tables, and key value stores with some magic serialized JSON could be ankle deep in linked key/values stores and scalability and all such things were claimed but seldom proved. And then mathematics of normalization hit them in the face, so they have to invent a new buzz word for normalization while still pretending SQL is an old man's fetish. More acronyms I say!

loudmax 13y ago
You do realize that there are successful companies storing massive amounts of data in NoSQL applications, yes? I guess you don't have to call key value stores and such "databases" if it bothers you. If you're making the case that traditional relational databases are still relevant today, I don't think you'd find many who would disagree. Databases of the sort described by Cobb are as valuable today as they ever were. NoSQL land has lots of competing technologies to draw the magpies. MongoDB was hot before. Now it's not. So it goes. But if you're trying to make the case that SQL is the only way to store data, you lack exposure to the variety of data out there. There are situations in which using a traditional relational database simply doesn't make sense. Would you really want to run, say, an instant messaging application with millions of users on Oracle?
- derefr 13y ago
  Both of you are correct. Around 2000 or so, we started to see companies that 1. had Big Data; 2. spread it across data centers spanning different continents; and 3. needed to display and update it in real-time. These companies (Facebook being the modern example) basically needed to throw out normalization (i.e. to choose AP over CP) in order to get an acceptable UX for people interacting in different parts of the world. And these companies were prestigious. But these two facts combined meant that everyone was quick to adopt these "pragmatic solutions to Big Data problems" in order to try to signal some of the prestige involved with having "Big Data problems." But, since their Data actually wasn't Big enough for the real pragmatic solutions to be more helpful than harmful, the prestige-seekers sought to simplify the "pragmatic solutions" -- keeping all the pain involved with non-relational access, while shucking anything that could potentially operate at scale. Thus were "consumer" non-relational databases (e.g. Mongo) born.
- fphhotchips 13y ago
  To add another example: Graph databases. I've found that one thing that relational databases/SQL really don't handle very well are graph data structures. Sure they can store them, but retrieving and displaying the data in any meaningful way is quite difficult. Edit: not impossible, mind. Just difficult.
deleted 13y ago
[deleted]

loudmax 13y ago

You do realize that there are successful companies storing massive amounts of data in NoSQL applications, yes? I guess you don't have to call key value stores and such "databases" if it bothers you. If you're making the case that traditional relational databases are still relevant today, I don't think you'd find many who would disagree. Databases of the sort described by Cobb are as valuable today as they ever were. NoSQL land has lots of competing technologies to draw the magpies. MongoDB was hot before. Now it's not. So it goes. But if you're trying to make the case that SQL is the only way to store data, you lack exposure to the variety of data out there. There are situations in which using a traditional relational database simply doesn't make sense. Would you really want to run, say, an instant messaging application with millions of users on Oracle?

derefr 13y ago
Both of you are correct. Around 2000 or so, we started to see companies that 1. had Big Data; 2. spread it across data centers spanning different continents; and 3. needed to display and update it in real-time. These companies (Facebook being the modern example) basically needed to throw out normalization (i.e. to choose AP over CP) in order to get an acceptable UX for people interacting in different parts of the world. And these companies were prestigious. But these two facts combined meant that everyone was quick to adopt these "pragmatic solutions to Big Data problems" in order to try to signal some of the prestige involved with having "Big Data problems." But, since their Data actually wasn't Big enough for the real pragmatic solutions to be more helpful than harmful, the prestige-seekers sought to simplify the "pragmatic solutions" -- keeping all the pain involved with non-relational access, while shucking anything that could potentially operate at scale. Thus were "consumer" non-relational databases (e.g. Mongo) born.
fphhotchips 13y ago
To add another example: Graph databases. I've found that one thing that relational databases/SQL really don't handle very well are graph data structures. Sure they can store them, but retrieving and displaying the data in any meaningful way is quite difficult. Edit: not impossible, mind. Just difficult.

deleted 13y ago

[deleted]