Chris Kuethe wrote: > > On 06 Apr 2006 18:12:59 -0700, Randal L. Schwartz > <merlyn@stonehenge.com> wrote: > > Given the cost of programmer time (and the cost of lost data) vs the > > cost of a slightly faster processor, is it ever really worth it even > > if MySQL is *twice* as fast? > > Yes. > > Example 1: I feel like digging through some data that will be relevant > for a short time, and a mysql database is the quickest/easiest way for > to slurp stuff out and get answers. I sat in on a netflow tutorial > last year at cansecwest. We were given a hundred megs of flows and > told to find the problems. A minute later, I had a reasonable table > put together, populated with data and was getting answers back. > > Example 2: I have other mysql databases where I store syslog for later > analysis. Sure, I have all the original logs on disk, but it's faster > to knock something together with mysql knowing that I can reconstitute > the database easily from the original data. My problem lies with > syslog not always getting the data back to my log server, not with > mysql sometimes losing it. > > CK > > -- > GDB has a 'break' feature; why doesn't it have 'fix' too?
I like those examples. Further, the more MySQL follows the "Standards" the worse it will work for your purposes, I'm thinking. In an ideal world, nobody makes any mistakes and everything is perfect. If you made a field too short for some of the data which comes along there are two different approaches as to how to handle the situation. First is to identify the problem and roll back so that nothing even got started. This is what "real" RDMSs apparently do. Second is to keep going and minimize the damage as best you can. This is what systems that face the "real world" are forced to do. If you use the first way and I can control a moving target of what you must eat, I can keep you going forever. There was a crack in this about MySQL being an SQL-looking front end to a file system. Actually very perceptive. You can use the filesytem to move stuff around and get away with it very nicesly. As to losing data, I suspect you'd lose a lot more from PostgreSQL than MySQL on a failing hard drive.
