SQL

True. I bailed on it though and wrote up a function in my favorite environment (which handles .dbfs natively, and very nicely) instead.

ha ha. just been sent some optimised versions of the queries i'd written:

he optimised out an entire join against the 'artist' table. which was nice of him. except the query was meant to be returning a list of artist objects to fill up the Artist ejb things.

(he also removed a left join which meant we had to populate the previously left joined table in order to get the required rows returned - 413,000 mostly empty rows. per service (of which we have 4 and counting.)

Disheartening: http://www.sdtimes.com/printArticle/LatestNews-20070715-44.html

How weird.. Eveything I've ever seen in the past 10 years or so has suggested Oracle #1 and DB2 #2... Not that that's anything but disheartening too.

I'm wondering how the question was framed. Also, not even 700 people asked = this is a very very very small sample.

Thing is, my enterprise uses it, but the strategy is DB2 and Oracle; SQL Server is tolerated for packages, but not in-house applications. By that logic, we would have voted yes, to this study, when in fact, it's accounts for about 0.5% of usage as compared with DB2.

http://blog.labnotes.org/2007/09/02/couchdb-thinking-beyond-the-rdbms/

oh shit son

JSONned