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?