- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Sun takeover latest - Oracle still painfully silent…
|
|
|
Comments (23)
3 earlier comments in the full thread.
Thanks DarrenR114, you've just convinced me, that MySQL is a great DB tool.
Leave it to an Aussie to let personal feelings about a person be the deciding factor on how good a piece of technology is.
That lame approach will lead to the same sort of poor decisions as from those people who decide that the Oracle DB is cr@p because they don't like Larry Ellison.
I'm willing to bet that you didn't even look at the links, did you, tracyanne? I'm betting that you're taking what I said a bit personally because you've never worked with anything but MySQL (meaning you've never worked with any real database.)
That lame approach will lead to the same sort of poor decisions as from those people who decide that the Oracle DB is cr@p because they don't like Larry Ellison.
I'm willing to bet that you didn't even look at the links, did you, tracyanne? I'm betting that you're taking what I said a bit personally because you've never worked with anything but MySQL (meaning you've never worked with any real database.)
Actually, considering the source is always a wise move.
As an add-on to TC's comment:
If Charles Manson tells you that two plus two is four, does it make him any more trustworthy?
No, it should make you wonder what ulterior motive he has for telling you that.
If Charles Manson tells you that two plus two is four, does it make him any more trustworthy?
No, it should make you wonder what ulterior motive he has for telling you that.
I've used both postgres and mysql over the years. Each has it's own charm, and neither is perfect but this idea that mysql is total garbage doesn't jibe with my experience.
Mysql is easy to get started with, and easy to work with. I've used mysql on lamp sites and at home for years and never had any problem with it. There's a mysql database that we've had in production at a fortune 100 company since 2005. It's over 300 GB, it's in heavy use 24/7, and as a mailguard data store it's directly in the path of incoming mail. It's been reliable.
In the interest of full disclosure, I will tell you there was an issue with the db once, 2-3 years ago, after the db had been neglected for 18 months, due to a personnel gap. Mail throughput was sluggish, but it was basically working. I was called upon to look into it, and found that the mysql db was damaged. I discovered that the root cause was an overtemp condition on the server some weeks previously, which had shut everything down uncleanly, resulting in filesystem and db damage.
We had to let the system limp along for the rest of the week since internet email was mission critical. During the Saturday night maint window, we did a db dump, which took a few hours, dropped the db, recreated it and did an import using the innodb force recovery option, taking another few hours. The db has been fine ever since.
So, the only issue we've ever had with mysql in 5 years of heavy use was caused by killing the power on a running database. I dunno, it's hard for me not to think of mysql as pretty darn reliable, ya know?
Mysql is easy to get started with, and easy to work with. I've used mysql on lamp sites and at home for years and never had any problem with it. There's a mysql database that we've had in production at a fortune 100 company since 2005. It's over 300 GB, it's in heavy use 24/7, and as a mailguard data store it's directly in the path of incoming mail. It's been reliable.
In the interest of full disclosure, I will tell you there was an issue with the db once, 2-3 years ago, after the db had been neglected for 18 months, due to a personnel gap. Mail throughput was sluggish, but it was basically working. I was called upon to look into it, and found that the mysql db was damaged. I discovered that the root cause was an overtemp condition on the server some weeks previously, which had shut everything down uncleanly, resulting in filesystem and db damage.
We had to let the system limp along for the rest of the week since internet email was mission critical. During the Saturday night maint window, we did a db dump, which took a few hours, dropped the db, recreated it and did an import using the innodb force recovery option, taking another few hours. The db has been fine ever since.
So, the only issue we've ever had with mysql in 5 years of heavy use was caused by killing the power on a running database. I dunno, it's hard for me not to think of mysql as pretty darn reliable, ya know?
Quoting:I'm willing to bet that you didn't even look at the links, did you, tracyanne? I'm betting that you're taking what I said a bit personally because you've never worked with anything but MySQL (meaning you've never worked with any real database.)
Perhaps you should read your links, Darren. None of the three links you posted shows MySQL is cr@pware. The 1st and 3rd link are just generic articles dealing with moving from MySQL to PostgreSQL. The second link doesn't make MySQL look bad at all. As for your 4th link, well, it's a bunch of MySQL bashers in some random forum.
Quoting:One of the things mentioned in one of those links is the fact that you won't find one article or case study that talks about migrating from PostgreSQL to MySQL - that's because those who depend on data reliability and availability don't stick with MySQL for very long, if at all.
Don't use Google much? http://www.scribd.com/doc/2569473/Migrating-from-PostgreSQL-... http://www.lightbox.ca/pg2mysql.php http://dbconvert.com/convert-mysql-to-postgresql-pro.php http://rt.bestpractical.com/view/PgToMySQL
And so on and so forth...
I'm getting a bit tired of your constant MySQL bashing,
Quoting:Leave it to an Aussie to let personal feelings about a person be the deciding factor
Nothing to do with personal feelings, I don't even know you except as an on line personality I've probably disagreed with on occassion, and agreed with on others.
I read the articles at the links provided, and decide you had drawn a bow way too long. In most cases the articles refuted your assertions. They both look like pretty decent DBMS, and preferable to the proprietary one I use most of the time.
> They both look like pretty decent DBMS...
The general consensus I've heard is that they both good, but that for mission critical data, PostgreSQL is better. I don't honestly know enough about databases to have an informed opinion myself, and it's entirely possible that my information is now outdated.
The general consensus I've heard is that they both good, but that for mission critical data, PostgreSQL is better. I don't honestly know enough about databases to have an informed opinion myself, and it's entirely possible that my information is now outdated.
@jdixon: It's outdated. The reason that PostgreSQL was recommended for mission critical data is that it was ACID compliant and MySQL was not. Nowadays, MySQL has several storage engines that are fully ACID compliant.
Like Darren's second link explains pretty well, there isn't all that much difference between the two anymore. It's mostly little details. These details can matter a lot, but it very much depends on was kind of application you're building or running. Most of the sweeping statements just don't apply anymore.
The only one I can think of that still applies is that for most simple websites MySQL with the MYISAM storage engine will be faster. It's quite fast in a low-write, high-read environment with non-critical data because it's not ACID compliant. PostgreSQL does not have a comparable engine.
Like Darren's second link explains pretty well, there isn't all that much difference between the two anymore. It's mostly little details. These details can matter a lot, but it very much depends on was kind of application you're building or running. Most of the sweeping statements just don't apply anymore.
The only one I can think of that still applies is that for most simple websites MySQL with the MYISAM storage engine will be faster. It's quite fast in a low-write, high-read environment with non-critical data because it's not ACID compliant. PostgreSQL does not have a comparable engine.
> Nowadays, MySQL has several storage engines that are fully ACID compliant.
OK, so if you use the right storage engine, MySQL is as heavy duty as PostgreSQL. Got it. I know just enough about databases to know that I don't know anywhere near enough to make competent decisions. :)
OK, so if you use the right storage engine, MySQL is as heavy duty as PostgreSQL. Got it. I know just enough about databases to know that I don't know anywhere near enough to make competent decisions. :)
Quoting:OK, so if you use the right storage engine, MySQL is as heavy duty as PostgreSQL.
Yup. But with those storage engines you loose the speed benefit of MySQL. Those ACID compliant engines run about as fast as the new PostgreSQL does. Like I said, it's not that much of a difference anymore :-)
Quoting:Like I said, it's not that much of a difference anymore :-)
One huge difference is query planner and EXPLAIN. MySQL heavily sucks in this department...
"But with those storage engines you loose the speed benefit of MySQL"
Not really - in my experience innodb is even faster than isam under load. Row-level locking absolutely smokes table-level locking performance-wise.
"Those ACID compliant engines run about as fast as the new PostgreSQL does"
That's mainly because postgres performance has improved dramatically from 5 years ago :/
Not really - in my experience innodb is even faster than isam under load. Row-level locking absolutely smokes table-level locking performance-wise.
"Those ACID compliant engines run about as fast as the new PostgreSQL does"
That's mainly because postgres performance has improved dramatically from 5 years ago :/
I just reread Darren's comments to me, specifically the last bit.
and laughed out loud.
Darren I use MS SQL Server 95% of the time. MySQL occasionally and Postgres once or twice. You really have not been paying attention.
Quoting:I'm betting that you're taking what I said a bit personally because you've never worked with anything but MySQL (meaning you've never worked with any real database.)
and laughed out loud.
Darren I use MS SQL Server 95% of the time. MySQL occasionally and Postgres once or twice. You really have not been paying attention.
So, out of curiousity, how does MS SQL server compare to all of this?
How does MS SQL Server compare? I'd like to say it's crap, but it's not. it will handle anything up to quite large databases. Microsoft's TSQL is close enough to the SQL I learned when working on WANGs in my mainframe days that the transition was pretty seamless. But in the end it's horses for courses really. I don't have any complaints other than the fact that it's expensive (License) for the useful version, or free for the Crippled version, which means I'd rather use MySQL or PostGreSQL.
Quoting:One huge difference is query planner and EXPLAIN. MySQL heavily sucks in this department...
What's the problem with EXPLAIN under MySQL? I've never had trouble with it.
Quoting:How does MS SQL Server compare? I'd like to say it's crap, but it's not.
You're fortunate. At my previous job, the MS-SQL servers (2000 and 2005) had to be rebooted regularly or everything would come down in flames. They had real stability issues.
@Sander In 15 years of developing against MS SQL Server I've not ever had an experience like that, they've always been stable and functioned well, with one exception two databases on two different occasions where the log space blew out, and ground the server to a standstill, due to a configuration. I'd say that in my experience they work best on up to large medium scale databases, but 99% of what I've done is well within those limitations. The largest system I've worked on that involve MS SQL Server was a Database for AMP (Australian Mutual Provident), but it was eventually abandoned, not because it was MS SQL Server, but because the Project leader wasted too much time trying to build the Business logic in TSQL, which is not , in my opinion, the best place for it.
Quoting:What's the problem with EXPLAIN under MySQL? I've never had trouble with it.
The problem is is that's a relic of an era when MySQL was only good for (an only could handle) one-table selects and, if you were careful, a simple inner join or two. For anything more complicated it gives you a terribly flat and not very detailed view of what's happening. Compared to PostgreSQL's EXPLAIN it's plain unreadable (at one point I got so tired of this that I designed my query in PostgreSQL and then looked how it worked in MySQL). And the query planner is dumb, too...
And since somebody mentioned MS SQL Server, I have to say that it seems to be the only pretty good thing Microsoft ever released, mostly because it's actually Sybase. And I loved its query analyzer back when I was working with it 10 years ago (yes, query analyzers are my pet peeve ;) )
> how does MS SQL server compare to all of this?
Well, as is usually the case with the better Microsoft products, it's my understanding that Microsoft didn't really write MS SQL, so it's actually pretty good. Of course, it runs on Windows, so...
> They had real stability issues.
See above. Anything running on Windows tends to have stability issues, no matter how good it may be.
The Wikipedia article on MS SQL has more information: http://en.wikipedia.org/wiki/Microsoft_SQL_Server
Well, as is usually the case with the better Microsoft products, it's my understanding that Microsoft didn't really write MS SQL, so it's actually pretty good. Of course, it runs on Windows, so...
> They had real stability issues.
See above. Anything running on Windows tends to have stability issues, no matter how good it may be.
The Wikipedia article on MS SQL has more information: http://en.wikipedia.org/wiki/Microsoft_SQL_Server
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post