

Ask HN: Is SQL the new COBOL? - ecounysis


======
geophile
You mean, with NoSQL being the new hotness?

No, SQL is not the new COBOL. COBOL was superceded by languages that do the
same things better, and then some. COBOL has a huge amount of inertia and is
never going away, but not because it's anyone's ideal language for any task.

SQL database systems are in a very different situation. They do many things
better than any alternative. NoSQL systems may scale better, for some
definition of "scale", and for some parts of some applications, but SQL
databases do lots of useful things that are hard to obtain using any other
technology.

NoSQL is like a tax shelter. It's a solution to a problem you wish you had,
but do not actually have. You aren't rich enough to need a tax shelter. And
unless the minimum viable product you created over the weekend is being used
by 100 million users, all day every day, you don't need NoSQL.

~~~
madhouse
I respectfully disagree: there's plenty of room for NoSQL, even if your users
are next to none.

For example, at times, it is just more convenient to store data in a schema-
less database (while still being able to query said data relatively easily).
One such thing are my logs: I parse and tag them before storing them, and the
relational model does not lend itself to that kind of storage.

Document stores, however, work beautifully. I can store entries like this:

{ program: { name: 'sshd', pid: 1234 }, date: { year: 2010, month: 1, day: 5,
... }, useracct: { mehtod: 'pubkey', source: '::1', port: 45678, service:
'ssh2', username: 'user', type: 'login' }, message: 'Accepted publickey for
user from ::1 port 45678 ssh2' }

Obviously, some of my log messages won't have half of the properties from the
example above, or have other kinds of fields. Storing that in SQL, while
maintaining easy queryabilty would be a huge pain in the backside, to say the
least.

With a document store, it's a piece of cake.

~~~
geophile
By "NoSQL" I'm referring distributed key/value stores. I know that's not quite
right, there are other kinds.

Also, I'm not saying that NoSQL doesn't have any purpose. It definitely does,
and long before NoSQL was hot, there were standalone b-trees like BerkeleyDB,
Faircom and many others. It may have been unfair for me to drag NoSQL into
this, but the question sure sounded like it was suggesting that the sun was
setting on SQL due to something, and NoSQL was a reasonable guess for what
that something was.

~~~
madhouse
Yep, that was my interpretation of the question too. But I wouldn't have put
down the document or key/value stores so harshly, since they do have their
uses, even outside of high-scalability scenarios.

As for BerkeleyDB and the rest: I'm not too familiar with them, but my
impression before was that querying them wasn't as elegant as it is with some
of the recent key/value or document stores.

Probably that's the reason these new things receive such a hype: they do have
something for them, even if the hype makes those bigger than they really are.

------
regularfry
Only if Tutorial D became _much_ more viable while I wasn't looking.

------
stevenwei
No, Java is the new COBOL.

~~~
yummyfajitas
Because clearly, there are no exciting new projects being built in java.
Except Hadoop. And Cassandra. And Neo4j.

