Some of the queries are very complex. Couple that with the fact that the ORM sits on top of this and it makes it even slower. The ORM makes it easier for me, the developer, but not easier for the database. Meanwhile, that a similar degree of ORM-abstraction can be had out of the box with NoSQL solutions.

You know every complaint I have seen about SQL performance involved a lamp stack. The vast majority involved a forum that used mySql and php on a shared host. Just saying.

Like I said, the slice I’m running on isn’t very fast. However, my tests using NoSql solutions to serve up the same data have been hundreds of times faster on the same hardware. Just saying.

If all you’ve ever used is Oracle or MSSQL, I suggest giving the NoSQL options a shot. They’re not suitable for everything, and they make no claims that they are, but for much of the common database tasks that bottleneck these days, they’re amazingly good. Couple that with the fact that they fix all the problems that Kerberos was originally complaining about; a querying tool that talks directly to the database, rather than via a fragile intermediate text-based handshake.

Several seconds????? Even more confirmation that we are having entirely different experiences with SQL.

You know every complaint I have seen about SQL performance involved a lamp stack. The vast majority involved a forum that used mySql and php on a shared host. Just saying.

That’s the real problem not SQL.

SQL is for interrogating databases not for inserting and updating data, doing CRUD (create, read, update, delete) operations using pure SQL or worse SQL duct taped into another language is the worst idea possible.

Switch to Ruby, or Python, or Linq or whatever and your pain will go away while still retaining the possibility to query your data however you want outside the application (which is often critical).

If you can think of a better collective noun than RDBMS for what I mean, then for Christ’s sake let me know.

I’m not *talking* about a Management System Base On Unusual Relational Data. I don’t *care* that there are alternatives that don’t feature human-readable query languages.

I’m talking about Informix, Sybase, Oracle, SQL Server, blah blah blah.

I’m talking about a big lumpy system that has a thin client that is designed to talk via SQL or embedded SQL or some other abortionate almost-but-not-quite human-readable language equivalent to a MASSIVE GREAT MONOLITHIC ENGINE where everything important actually happens, but the programmer doesn’t have a clue what or when or why or how and can’t in the general case figure it out.

All I’m trying to do is to support Kerberos’ original point and expand on it a bit. Is that too much to ask?

Not every RDBMS uses a human-readable query language, but anything with “SQL” in the title is going to have that interface.

I take your points, but you’re drifting away from the core argument, I feel.

SQL is there because it’s there because it’s there. Fine, but not the best defence.

Your point about “SQL related algorithms” is well taken, but I did actually point out that these are there because SQL is “baked in.” As a programmer, I’d rather have access to them in a layered manner with APIs — not some stupid human-readable IBM garbage from the 70s. Even if you add Linq and ORMs and everything else, you’re still barred from programmatic access precisely because of the way an RDBMS is designed — simplistic client-server with only SQL as an interface between the two.

Don’t get me wrong. I like using SQL Server, and I can put up with Oracle, and even when I use MySQL and SQLite and the rest, I’ll program via SQL because that’s the easy way to do it.

But it has an opportunity cost, too.

Typically even unoptimized selects are going to be fairly fast. Writes are slow, but joins can often be slower by an exponential magnitude. It all depends on how complex the schema is really.

While its true that many simpler websites will never really max out an SQL Server, even my TM Repository site, running on mySQL, takes several seconds to perform some of the more complex queries. Granted, it’s running on the cheapest slice that slicehost offers, but the same scenarios on the same slice in Mongo or Couch run hundreds of times faster because of the way the data is structured, negating the need for joins.

In case anyone in the .NET world is interested, MongoDB has a C# driver. Couch has a few wrappers/drivers but I’m less familiar with them.

I can’t speak for MySql but I know that for SQL Server it’s extremely rare for a website to need more than a single dedicated DB server. At that level you’re talking major traffic and scaling won’t be an issue if you designed your website properly. Even if you didn’t at that level you can probably afford to have someone handle the scaling for you.

I have to wonder if you guys are spending too much time with SQL at the command line level. Disco tech overload perhaps? I think some of these nosql alternatives are interesting but in the .net world everyone is fine with SQL Server.

Relational databases have their place, for sure, but they don’t scale/shard as easily, and as transparently, as the newer NoSQL solutions do. Not to mention using an actual debuggable turing-complete programming language to do map/reduce functions is far saner than the SQL language.