Re: It depends, but usually MySQL is the choice
"You are confusing data corruption with high availability, they are not the same thing."
Yes, I know. I included the superior HA features in Oracle/DB2 because of your spider example (i.e. you want to use MSSQL over MySQL for workloads where you can't recapture the data). This assumes that MSSQL is superior in HA as the DB going down would be the reason for recapture. If you have a workload where you cannot recapture data (live OLTP for banking transactions or the like), you would want to use a DB with a proper HA architecture like Oracle or DB2. Also, HA and data quality go hand in hand. The most common reason for a data corruption or a contiguity issue in the DB is that the DB goes off-line. Data quality isn't an issue in the normal course of operations. It is when something goes wrong that data quality becomes an issue. HA/data quality are inherently linked.
"My point was that you don't want to do things on the cheap, I was not suggesting that they did run any particular database."
Yes, and my point is that MSSQL and MySQL are both doing things on the cheap. Neither are enterprise grade at the RBS level.... MSSQL forces you to run on the MS NT platform, the opposite of mission critical. MSSQL cannot do contiguous paging, still uses standard 8 KB blocks, few data transfer options, is missing a whole range of indexes, could go on. I am sure RBS has never considered either MSSQL or MySQL for the workloads you are talking about, so the advantage for MSSQL over MySQL is a false comparison. Neither have that level of enterprise functionality. Using "RBS applications" enterprise grade functionality as a counterpoint to MySQLs scale, flexibility and cost advantages is false.
"This is hardly a drop-in storage engine of the type of innodb or myisam, is it? It's an entire database back end."
More of a drop in than the non-existent MSSQL options.
"*Point being*, that you didn't know that MSSQL provided most of what you are talking about and you're trying to cover that up."
No, the I acknowledged that all of the features were not specific to read performance and that I was throwing out possible advantages the engines could provide for different types of workloads. MSSQL does provide many of them, but you can tailor your engine to your workload which is not available in MSSQL.
"You also said that: "SQL replicates everything and sucks a bunch of storage and system performance" which was just plain bollocks, which you've not acknowledged."
Acknowledged, I was mistaken. MSSQL can do transactional log ships. I know about the types of binary logging.
"I never said that the underlying table structure had no effect, in fact I'd be very surprised if they didn't, but you didn't seem to understand what the query optimiser was and how important it was -- orders of magnitude instead of small constant factors or multiples to the point where the underlying storage mechanism can become almost irrelevant. The query optimiser is never to my knowledge used with reference to the underlying table structure, only logical rewriting of the query. I believe this is the standard terminology."
Actually, you wrote "outstandingly stupid comment. The back end does not matter, only the result set (or whatever) output." The table structure (back end) does matter, obviously. Yes, query optimizers matter as well, and are by no means only available on MSSQL. Different engines are an advantage for MySQL which MSSQL does not have, so, like I wrote originally, score one for MySQL.