> Only ad-hoc queries that you didn't plan for will be slow

Not true. If that were so denormalization wouldn't be a standard technique to speed up queries that join many tables and have to be really fast. The fact is SQL databases force you to reconstruct your document from many tables in a query and that is costly, even with indexes.

It's simply much faster to not break the data up in the first place to fit it into a tables and rows data structure if speed is your primary concern. Storing a complex document, as is, will result in much faster retrieval.

RDBM's are a tool, a damn fine tool, but like any tool, they're aren't the answer to every solution and far too many people pull out the RDBMS as the answer to every problem.

Except you just showed that normalization has performance tradeoffs, not that relational databases aren't a good solution. They offer you the flexibility to normalize or denormalize as the conditions demand.

Of course they aren't the answer to every problem, and I think unstructured or semi-structured data (such as HTML pages or text data with entity tags) is a good case for storing things in a more document oriented system.

Normalization was just an example, the point was that joins are expensive. Even denormalized, you can't do much without joins for any complex data structure.

Relational databases are always are good solution; however, they are not always the best solution for the problem at hand. The real problem is that once someone has their head wired to an RDBMS, it's often impossible to get them to even consider another solution. It becomes their golden hammer.

The articles main point, that "SQL Databases Are An Overapplied Solution", is absolutely correct.

"the point was that joins are expensive."

That is a blatant myth. Joins are not slow.

They are when compared to no joins. Rebuilding a data structure is more expensive than not taking it apart in the first place.

Yes, but normalization is done to lean on the RDBMS's constraints to ensure the data is internally consistent, not for performance-related reasons. Similarly, keeping backups may waste storage space, but when you need them, you really need them, and it's too late to change your mind.

Exactly my point, all those nice things RDBM's give you come at the cost of performance trade-offs. Relational databases are never the fastest option, they are the safe conservative option.

The bill of goods that RDBM's sell is that data integrity trumps all else. The reality is that is doesn't. Data can be cleaned and integrity maintained by background processes if the performance you get is more important to you than absolute up to the second data integrity. There are lots of cases where available data is far more important than up to the second accurate data.

Eventual consistency is more than good enough for many many things common web applications do. In many cases it's perfectly fine that the web app is looking at 4 or 5 hour old data, it just doesn't matter, what matters is that it can look at it in milliseconds without having to rebuild it on every query.

While I ultimately agree with you, I think that the safe conservative option should be the default. By the time peoples' systems are large enough for the performance difference to actually matter (if ever), they will have had plenty of time to get sufficiently informed about the trade-offs involved. The people who are upset because they get crappy performance from MySQL when they don't even know about indexing tables are not qualified to decide whether risking data corruption is worth a performance boost.

In other words, it's premature optimization.

And I think the simplest solution requiring the least amount of code and effort should be the default. It's not just about performance, it's about implementation effort. The safe conservative option is quite often a lot of extra work.

Most people aren't building banks, for most apps data corruption is not the big concern RDBMS fans make it out to be.

They are in MySQL, which everyone here seems to be using despite everyone knowing it is the least performant database system out there.

I use MySQL and SQL Server everyday and there isn't a really huge difference in performance. And I'm working with large (100 line) queries over large sets of data trying to return real-time results. I've got more joins, subselects, and unions going on than the average user will ever use and I still return results instantly.

Now older versions of MySQL, like 3.23, are still in use (unfortunately) and pretty crappy but it was released over 8 years ago. Most of these performance myths about MySQL are outdated.

Last time I checked, and feel to correct me if I am wrong, MySQL used Row lookups when doing JOINs. There was no support for more efficient join algorithms like hash-join or merge-join, something which kills performance if you intend to run JOINs on a result/working-set bigger than just a few rows.

Are there any improvements in this area, or is it still just the same old, same old?

> The database does not need round-the-clock availability (middle-of-the-night maintenance windows are no problem).

Yeah, this is idiotic. This kind of thinking is why it sometimes took three days to register for classes in college, and why I couldn't check my account balance in the evening after I got home from work/class, why I sometimes couldn't search the library catalog... etc., etc.

I can think of perhaps one of our clients who would be fine with their database being down for hours at a time at night. Maybe.