5 ms·

I don't know if I like it or not. If you know SQL well and want to switch to a NoSQL database, what's easier learn? The "proprietary" API of the dababase (like

I don't know if I like it or not. If you know SQL well and want to switch to a NoSQL database, what's easier learn? The "proprietary" API of the dababase (like Redis, or MongoDB) or the limitations of unSQL? I can't speak of other NoSQL databases, but unSQL doesn't seem to expose most Redis' features, like lists & sets.

dpapathanasiou 15y ago
what's easier learn? The "proprietary" API of the dababase (like Redis, or MongoDB) or the limitations of unSQL? That's what bothers me about this, too. While I can understand the goal of making noSQL databases more accessible to people who already know SQL, as well as the need to unify the commands across all the different flavor of noSQL databases, there's something fundamentally flawed about accessing unstructured data via logic intended for structured data.
- deleted 15y ago
  [deleted]
- leef 15y ago
  The data is not unstructured, though. It is in JSON format which can be taken advantage of.
- chewbranca 15y ago
  The data is not necessarily unstructured, it just doesn't have a strictly inforced schema. So I'm very intrigued by this if they're adding it as a layer on top of CouchDB views. If they are, you could use your views to selectively filter on documents with a known structure, and then safely operate across a subset of your docs with unql. We'll see where they go with this though.
  - chewbranca 15y ago
    To clarify for the downvoters, I'm talking about this in the context of CouchDB, which I believe was a fair assumption to make seeing as Damien Katz is one of the principle people involved and it was announced today at CouchConf. In CouchDB, running a filter on top of view results is something you can only do in list functions or client side, so I am very curious to see how they incorporate this into CouchDB.
Jach 15y ago
"If people invested as much in learning to tune MySQL or Postgres as they did in working around MongoDB flaws they wouldn't need MongoDB." ~Benjamin Black
- alnayyir 15y ago
  This is false, the writer of THE book on MySQL tuning (Jeremy Zawodny) is also the guy that is/has converted CraigsList to MongoDB from MySQL. But let me interrupt your propaganda. We wouldn't want to address the reality that not all data and work sets can fit well in a relational database. Example: http://blog.zawodny.com/2010/05/22/mongodb-early-impressions/ http://blog.zawodny.com/2010/05/22/mongodb-early-impressions...
  - Jach 15y ago
    Calm down a bit, man. I've got a MongoDB mug sitting on my desk. I think you'd agree that even if the data structure fits into a key-value model more so than a relational one, that still doesn't mean you need NoSQL, and if you take a common definition of "big data" to mean "your data needs exceed the capabilities of a single machine", then a lot of people don't need all that scalability. (And if it did, you'd use Hadoop anyway. =P ) (There's also CAP Theorem considerations for added fun. http://en.wikipedia.org/wiki/CAP_theorem http://en.wikipedia.org/wiki/CAP_theorem ) There was a presentation up here a few months ago on how the guys at http://wordsquared.com/ http://wordsquared.com/ used MongoDB; they basically made the choice since they knew it already, instead of using postgres with their great geo libraries. And that's fine. What's stupid is when people who know one or the other pretty well spend a lot of time learning about the other for a use case that's most likely not really necessary anyway, or their current choice could handle with tweaks. Of course, once public CS starts moving forward into innovative big analytics rather than just managing big data storage (such as the theta-join paper I linked elsewhere on this page), things may start shifting in favor of one of the NoSQL systems and the above quote would be equally suitable when comparing the Hadoop ecosystem or Mongo with some fancy new relational DB.
    - alnayyir 15y ago
kunley 15y ago
I think good programmer should aim to know both SQL & NoSQL. The backend should be chosen because of the data characteristics, not because of someone's experience..

dpapathanasiou 15y ago

what's easier learn? The "proprietary" API of the dababase (like Redis, or MongoDB) or the limitations of unSQL? That's what bothers me about this, too. While I can understand the goal of making noSQL databases more accessible to people who already know SQL, as well as the need to unify the commands across all the different flavor of noSQL databases, there's something fundamentally flawed about accessing unstructured data via logic intended for structured data.

deleted 15y ago
[deleted]
leef 15y ago
The data is not unstructured, though. It is in JSON format which can be taken advantage of.
chewbranca 15y ago
The data is not necessarily unstructured, it just doesn't have a strictly inforced schema. So I'm very intrigued by this if they're adding it as a layer on top of CouchDB views. If they are, you could use your views to selectively filter on documents with a known structure, and then safely operate across a subset of your docs with unql. We'll see where they go with this though.
- chewbranca 15y ago
  To clarify for the downvoters, I'm talking about this in the context of CouchDB, which I believe was a fair assumption to make seeing as Damien Katz is one of the principle people involved and it was announced today at CouchConf. In CouchDB, running a filter on top of view results is something you can only do in list functions or client side, so I am very curious to see how they incorporate this into CouchDB.

Jach 15y ago

"If people invested as much in learning to tune MySQL or Postgres as they did in working around MongoDB flaws they wouldn't need MongoDB." ~Benjamin Black

alnayyir 15y ago
This is false, the writer of THE book on MySQL tuning (Jeremy Zawodny) is also the guy that is/has converted CraigsList to MongoDB from MySQL. But let me interrupt your propaganda. We wouldn't want to address the reality that not all data and work sets can fit well in a relational database. Example: http://blog.zawodny.com/2010/05/22/mongodb-early-impressions/ http://blog.zawodny.com/2010/05/22/mongodb-early-impressions...
- Jach 15y ago
  Calm down a bit, man. I've got a MongoDB mug sitting on my desk. I think you'd agree that even if the data structure fits into a key-value model more so than a relational one, that still doesn't mean you need NoSQL, and if you take a common definition of "big data" to mean "your data needs exceed the capabilities of a single machine", then a lot of people don't need all that scalability. (And if it did, you'd use Hadoop anyway. =P ) (There's also CAP Theorem considerations for added fun. http://en.wikipedia.org/wiki/CAP_theorem http://en.wikipedia.org/wiki/CAP_theorem ) There was a presentation up here a few months ago on how the guys at http://wordsquared.com/ http://wordsquared.com/ used MongoDB; they basically made the choice since they knew it already, instead of using postgres with their great geo libraries. And that's fine. What's stupid is when people who know one or the other pretty well spend a lot of time learning about the other for a use case that's most likely not really necessary anyway, or their current choice could handle with tweaks. Of course, once public CS starts moving forward into innovative big analytics rather than just managing big data storage (such as the theta-join paper I linked elsewhere on this page), things may start shifting in favor of one of the NoSQL systems and the above quote would be equally suitable when comparing the Hadoop ecosystem or Mongo with some fancy new relational DB.
  - alnayyir 15y ago

kunley 15y ago

I think good programmer should aim to know both SQL & NoSQL. The backend should be chosen because of the data characteristics, not because of someone's experience..