Linked by Eugenia Loli-Queru on Thu 17th Jun 2004 21:11 UTC
Original OSNews Interviews Today we features a mini-Q&A with Alex Roedling, MySQL's Senior Product Manager, about all things MySQL, the competition, technology, licensing and more.
Permalink for comment
To read all comments associated with this story, please click here.
@derek II
by Anonymous on Sat 19th Jun 2004 08:37 UTC

"That's like saying that it's OK if your filesystem were to randomly truncate files or mix two files together. Becuase, hey, it works and it's fast and who cares if you lose a few bits here and there?"

Betcour made the best counterpoint, but even if it *were* just random data loss, it would be in the same category as something like ReiserFS. There are a few horror stories out there, and some people stay away from it because they don't consider it mature enough yet. That's fine. But when tens of thousands of people have used it for years without experiencing a single glitch, don't expect them to go streaking home to 'fix' their files servers just because they hear one of those stories. There are acceptable levels of failure even at the FS level. It's very close to zero, but it's still there.

People also tend to talk as if "business data" is all highly valuable and irreplacable. Sure, there's a decent amount of that, but there's also a bunch that is enitirely replacable because it was imported to begin with. Databases are often used just to munge data, not as the sole repository. Second, many businesses have daily backups. I'm not saying it's okay to write leaky programs because people should make backups: I'm saying that sometimes people may not give a rip about the possiblity of a program leaking because they know it's replacable without a lot of work. As long as it's sufficiently unlikely, it doesn't even make it onto their 'cons' list.

Frankly, one of the reasons I don't mind the lack of features in MySQL is that I find SQL harder to write than code - and so do a lot of intelligent coders that I know. More elegant perhaps, and even faster at run-time, but if it's going to take 3 times as long to write, contain more bugs, and be more difficult to maintain, I'd rather put it in code. Not to mention that putting a bit of logic in code means never having to come back to make a 'minor' tweak and realize "Damn, this SQL statement can't possibly be arranged to add that feature." In which case you are either writing a *lot* more SQL or rewriting the entire bit of logic in code - which means you've now done it both ways. Maybe I'm just a bad SQL guy, but I suspect there are a lot of us. Just one more reason why MySQL is perfectly accessible to a huge crowd.