"If you don't like it, it must be because you haven't taken the time to understand it" is cognitive poison. What evidence will convince you that someone has understood well enough to judge that something doesn't make sense?
I've spent many years using schemas, and I know well how they work and what they achieve. I'm saying they're a lousy tradeoff.
I'm attacking what you actually said in the article. You're attacking what your own statement of what you think I believe.
Engineering choices are always tradeoffs. If they're founded on ignorance, they're bad choices--always. Your article is trying too hard to be cute and funny and comes across as ignorant. I assert that promoting uninformed decision-making is both intellectually dishonest and constitutes a much truer form of "cognitive poisoning."
You may well understand what they are and have a well thought out nuanced opinion, but the quote shows none of that. It sounds like an out of hand dismissal of the whole concept of schema which would be pretty ignorant.
"They don't exist, if you don't construct SQL queries by concatenating strings and variables."
My point is, people still do this. You never hear about REST-injection or memcached-injection attacks, even though those are possible in principle, because those protocols don't encourage this mistake the way using SQL as a database API does.
We keep things we might need to search in regular columns (typically with indexes). The JSON object is just a way to add extra data to rows, which we can fetch and deal with on the app side. That works fine for a lot of things, and we're hoping it will give us some flexibility around when we need to do schema migrations in some cases.
Very true. I'm tempted to argue that SQL's English-like syntax was a mistake, but only because I think it makes people think you don't really need to learn it. It's frustrating to see people trash something when they don't even properly understand it - a lot of the database-related blog posts I've seen make the front page of HN would be shot down if they were similarly misinformed about a language like Javascript.
I'm not by any means saying that the NoSQL movement as a whole is a fad - there's good motivations behind some of these products - but a lot of people who are just ignorant also seem to have hopped onto the bandwagon.
That was an issue I had with the post: how can "non-relational" be a good thing about CouchDB? If you have relational data, then there's an entire theory (relational algebra) behind ways to interact with it that have clearly defined semantics. I can see that one may decide they don't need that, but I don't see how it's absence can be a good thing. Being non-relational frees CouchDB to provide different kinds of capabilities, but it's those capabilities that are a good thing, not the lack of being relational itself.
Rather, I think the author has confused "relational" with a lot of other properties of relational databased management systems - such as transactions and data integrity guarantees.
You're right that I was lumping transactions and data integrity guarantees in with "relational". I was thinking about normalization, and protecting data integrity in ways that lead to joins and transactions.
You made me think about something. A CoffeeScript like approach to build a saner language that would sit atop SQL would be something definitely worth having. Maybe this could be the start of the "OnSQL" movement. Just my thoughts.
My primary point was just that SQL is old, and I think the reason it is the way it is has more to do with history and compatibility than what we'd want it to look like if we started from scratch today.
SQL is still around because it was successful. And there are reasons to value compatibility, and to avoid changing things for no reason. But my personal experience using a database without using SQL was pleasant, and I'm anxious to see the world move on to something new and improved.
There are a lot of things I like about the query interfaces of PetaPoco, ActiveRecord, etc. For simple CRUD operations, they're much prettier and more concise than than embedded SQL - Person.find(123) is a lot nicer than "person = db('select * from person where id=123')"
But beyond very simple cases I feel like non-SQL query interfaces very quickly become terrible, clumsy, leaky abstractions.
I usually try to have the best of both worlds - I create a SQL view/function/sproc containing my big gross gnarly joins, and then query it in a pretty way via the ORM.
I still don't see the similarity. Just about any modern language is full of English keywords - for, while, unless, function, etc.
Unlike COBOL (which I admit to not being very familiar with) SQL uses standard mathematical symbols as operators whenever possible... + instead of "ADD" etc.
A number of us know MySQL fairly well, and in particular I've seen how it's used by some of the biggest internet companies. We have some postgres experience on our team as well, but it's a little more of an unknown. So experience trumped feature set in this case.
One thing I would say about postgres is that it has a lot of features. As a new user, it's hard to know which ones to use in which ways, and what the downsides might be.
"One thing I would say about postgres is that it has a lot of features. As a new user, it's hard to know which ones to use in which ways, and what the downsides might be."
Do you have some suggestions how that can be improved? Are there features that you would classify as "bloat" or that seem confusing or poorly documented?
Postgres is a very general system and has a large variety of users as a result. That means that the features tend to be very well-thought out and don't carry a lot of surprises, but it also means that it's hard to guide users toward specific usage patterns. Even among web users, a feature like LISTEN/NOTIFY might be an instrumental part of the caching infrastructure for some users, but seem like bloat to others.
I'm one of the authors of a Python framework called monocle for doing async programming in this style. It works with twisted and tornado. http://github.com/saucelabs/monocle
I'm not sure I understand your concern here. How does monocle make decomposing logic into functions difficult?
The "yield" keyword is an indicator of where control is returned back up to the event loop and other things can happen. We like that in monocle, because we view it as dangerous; in thread-and-lock terms, it's sort of like "unlock everything".
Eventlet (http://eventlet.net/) is an example of a similar framework that decided not to require "yield" at these points.
Let me start by saying that I actually think Monocle is nice work given the language mechanisms that Python provides and this is intended as constructive criticism.
What I meant by "makes it hard" is that it creates two different calling conventions for functions and you need to know how a function is implemented to determine which one to use. Also, if the implementation of a function changes you may need to find and change all the call sites of the function. These are not insurmountable problems by any means, but they are extra potential sources of error in a program.
I'm not familiar with Eventlet, but FWIW the Cocoon framework (http://cocoon.apache.org/) had a quite nice take on this model back in the day.
Well, monocle is headed in its own direction. We're abstracting the generator-style concurrency stuff out from the underlying I/O framework, so monocle works with both Twisted and Tornado, and we're prepared to interoperate with other frameworks in the future. On top of that base, we're developing a framework for working in this style; there are some early ideas in monocle.experimental. We're also building simplified base networking APIs in a way that only makes sense if you're committed to this style of concurrency.
I think the question is really whether you're more compelled by generator-style concurrency, or Twisted itself. If you want to work deeply with Twisted, inlineCallbacks lets you use generator-style where you want, and is maintained along with Twisted. If you want to use generator-style concurrency to its full advantage in simplifying complex evented servers, that's where monocle is going.
