Slashdot Mirror
Oracle Lines Up Unbreakable MySQL
munchola writes "MySQL CEO, Marten Mickos, has revealed to CBRonline that Oracle has threatened to provide support for MySQL and is already distributing the open source database. "They have hinted to us that they will," said Mickos, indicating that the database giant is planning to repeat its October 2006 Unbreakable Linux plan, which saw it undercut Red Hat with enterprise Linux support. Despite the competitive threat, Mickos is unmoved. "I hope they do that," he said, noting that it would be seen as an endorsement of the open source database.""
I find it hard to believe that a company with the amount of overhead that Oracle has will be able to provide mySQL support for the same rates that mySQL can; the primary benefit for Oracle is that they'll be able to offer bundled support with people who already have Oracle support and want the convenience of dealing with one company for all their support needs.
Definitely a win-win situation for mySQL, because they get press and legitimacy without losing too much business. The "unbreakable linux" deal probably hurt RedHat a hell of a lot more than this will hurt mySQL.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Sounds great! Maybe GM will "threaten" to buy fuel for my car, or Amazon will "threaten" to return my library books for me so I don't have to.
Why would anyone pay ( through the nose ) for Oracle's database when Oracle itself claims that MySQL is unbreakable ?
> If you came up with a ratio of $spent/$productivity, Oracle would probably throw a divide by zero error.
Whereas MySQL would silently insert a default value.
Done with slashdot, done with nerds, getting a life.
This will so come back to bite them in the ass!
Customer: XYZ doesnt work. Help me!
Oracle: MySQLs XYZ is crap - you better buy a real DBMS. As a support customer we can offer you Oracle 10g Enterprise at a reasonable prize!
Serious question: What exactly is the advantage of Oracle over SQL Server? I asked that to an Oracle DBA once, and he just got red in the face and stammered about having more options to configure things the way he wanted. I asked what exactly he configured, and basically got a lecture on Microsoft being evil. I then asked if he thought Larry Ellison was a saint, and the conversation just continued to devolve.
Serious question: why is Oracle considered so much better that SQL Server?
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
Exaggerate much?
Most people who are using oracle wouldn't be better of using MS Access, the products serve very different purposes. Some people using oracle would be better off using mysql or MS SQL Server (or postgresql or some other database) and some people using those products would be better off using oracle.
The rest of us can push MySQL saying "this is what Oracle recommends, just free".
(*) I just pulled that number from clear air.
Same reasons. The more publicity, the better. If Oracle believes in it enough to offer support, everyone else can feel a little bit easier about using it.
Oh man, how low can you go? Providing support? How DARE they!
Really though, I think people will see it as an endorsement (and more so, people might think that Oracle is losing faith in its flagship product). It's one thing to provide support for Linux, but MySQL is directly competing with Oracle (to a degree). I really don't know what message they're trying to send here, but if it's that people should buy Oracle, I really don't see how this will help.
Anyway, competition is good. If Oracle thinks it can provide better service than MySQL for, well, MySQL, let them! It'll only foster better service on both sides.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
postgresql is a more oracle-like (eg, plpgsql) and BSD licensed. Of course, postgres could cannibalize oracle sales; mysql is like sqlite, but with less features.
Do you even lift?
These aren't the 'roids you're looking for.
... but what good does this do for Oracle?
Given that MySQL and Oracle are on complete opposite ends of the scale with regard to their uses, what benefit does Oracle have in killing what is essentially a non-competitor?
Knowledgeable IT people presumably already know when to use Oracle and when to use something smaller like MS-Access. IT morons who think that single-user databases with less than a thousand records need to be in Oracle have already drank the kool-aid and will never change to another product. Oracle's only threat would appear to be the next generation of IT morons who realize that Oracle is not always the best solution to simple problems. But since they don't know any better, presumably they will still go with Oracle.
> "Oracle has threatened to provide support for MySQL and is already distributing the open source database."
The statement seems a bit like holding the gun to your own head and say, "I'll shoot!"
They're not aimed at the same markets. I haven't followed this too closely, but I assume the reason Oracle is interested in MySQL at all is that they're somewhat complimentary products. MySQL is great if you want a lightweight, fast database that doesn't need to be terribly robust.
I doubt MySQL is ever going to have the sort of PL/SQL support Oracle does, and you're not likely to see things like enterprise-class clustering, data partitioning, replication, and so forth. If you added all that to MySQL, it'd wind up just like Oracle - big, complex, and expensive. They occupy opposite ends of the spectrum.
And for what it's worth, I've got an Oracle database on a modest single-processor AMD server with a single hard drive handling about 20 inserts per second with R-tree spatial indexing and it keeps up just fine, with a bit of tuning. Given a real server with multiple drives I'd be able to optimize things much better, but it's just a testbed.
Comparing MySQL to Oracle is a little like comparing a high-performance motorcycle to an M1A2 tank. They'll both get you from point A to point B, but with different levels of cost and safety.
I've taken two Oracle classes (could have gotten certified, but I really didn't care that much). Basically, unless you're running into the tens of thousands of users, there's not much difference. Now, as a DBA, there are some things I would prefer to do in Oracle rather than SQL Server (though I'd much rather do them in an open source DB like MySQL or PostgreSQL), but I don't think it's worth the (massively) added cost unless you really are running it in an enterprise situation.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
As for Oracle support, it was the main thing we looked forward to at first (this was the mid-90's); but it, too, got worse over time. I would not trust Oracle to properly support MySQL, especially since they have no motivation to push it, and they are not the developers (and in fact are in competition with them).
Dog is my co-pilot.
Oracle has one kind of customer, MySQL has another kind of customer.
Just a guess, but I'll go out on a limb and state that any hopes MySQL had in wooing really pricey billable hour customers is evaporating. Even if I'm wrong, the mood at MySQL has probably been a little less happy when they figured out Oracle was going after the top of the consulting/support dollars.
There's still *so* much they have to offer for businesses willing to pay. They just need to keep at it and understand that Oracle won't be the first company to do this to them. Microsoft will surely follow with some kind of crazy scheme. They have to at some point as their arrangement with Novell suggests they need to at least appear as if they have something like OSS to offer.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
What exactly is the advantage of Oracle over SQL Server?
I'm rather fond of their Analytic Functions, which allow for convenient queries against other table rows. For example, given a table of time-stamped log entries you can write a query to "Show me the time intervals between successive log entries."
I'm hoping these will show up in Postgresql soon.
In a band? Use WheresTheGig for free.
Interesting reading, for sure. I know I have spent a lot of time writing "complex" SQL queries to accomplish the same thing. Interesting having a built in functions that will help accomplish the same thing.
Question: Performance-wise, is this the equivalent of using SQL subqueries? Or is there some type of database optimization that gives it a performance advantage?
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
And that heaven for that! Look, most of us want a database system we can use for our own limited but still important purposes. We don't need a lot of enterprise-level crud bogging us down. I'd never think of using MySQL on the large scale, but then that's what I have Oracle for. Oracle is over-muscled for a lot of simple stuff; MySQL is better for a medium-weight application.
And as an aside, the reason that Oracle is doing this is to get their name in the small-to-middle size market. Oracle's been dominating larger firms for years now, but that means there's little room for growth. If they can try to reach smaller markets and spread their name around, when some of these smaller companies outgrow their MySQL set-ups, Oracle will be ready to step in with their enterprise apps.
GetOuttaMySpace - The Anti-Social Network
Comparing MySQL to Oracle is a little like comparing a high-performance motorcycle to an M1A2 tank. They'll both get you from point A to point B, but with different levels of cost and safety.
More like comparing a scooter to M1A2 tank. You can use a innodb powered gas scooter, but it runs slower.
This has less to do with support or endorsement than with having a foot in the door and generating leads for their flagship products.
> Look, most of us want a database system we can use for our
> own limited but still important purposes. We don't need a
> lot of enterprise-level crud bogging us down.
So true. I'm running a small database (only 20 million records), and PostgreSQL is more than sufficient. We use it in production, too, and it's quite solid.
Maybe someday when we get up to 100 TB or so we'll think about something else, but by then PostgreSQL will probably be capable of handling that load as well...
The Army reading list
sucks donkey nuts. The only reason we have it is because they won't let us have the source code. Not a problem with MySQL! ;-)
"Da ist ein Technölüst in mein Unterpanten!"
I am sure this is just an effort on Oracle's part to capture as much of the low end database market as they can, then offer a seemless, supported upgrade to Oracle's DBMS for those who reach the limits of mysql or who start needing requirements that mysql can't support. This lets them continue to bombard customers with reasons to upgrade, while still getting support contract money from them. If the mysql community benefits from this, I am sure its just an accidental byproduct of a marketing and sales effort and nothing more.
"The first time I got drunk, I got married. The second time I bought a chimpanzee, after that I stayed sober" Arian Seid
I doubt they'd support PostgreSQL. MySQL is basically a non-competitor. While PostgreSQL still isn't, it's much closer. Postgres is fully ACID compliant, is very strict about it's data, has mature support for just about everything (still lacks in clustering and replication, though...), is very fast, scales well, etc.
When you hit the limitations with MySQL, need a feature it doesn't support, etc, Oracle can point you to a sales rep. There are far less limitations with PostgreSQL. It wouldn't make as much business sense to encourage it's use.
"The Federal Reserve is a fraudulent system."--Lew Rockwell
End The FED. -
I just think that all of these big name companies are tired of getting asked about their thoughts on the open source community, so they are all teaming up, partnering with, or simply trying to support open source technologies... Microsoft and Novell, and now Oracle with RedHat and MySQL... I think its just to say "we can play nice with the other guys..."
Whether or not it is good or bad for the community, only time will really tell us that.
Relocating to San Francisco / Palo Alto... Hire me?
. . . when they can't even support their own products?
Signed,
Another Oracle "Fusion Middleware" (or whatever they're calling that abortion of an application server this week) User.
What?
I doubt very much that most DBAs that have a support contract with Oracle and move to MySQL will say "OK, now we don't need that contract anymore". They will keep it as insurance for who knows if MySQL will work as expected? They feel they may need to move back to Oracle in the future. After all, if they had felt at ease with MySQL to begin with, they wouldn't need Oracle to tell them how good it is.
I doubt it. Unlike MySQL, PostgreSQL is much more of a direct competitor to Oracle. In fact, I've converted PG databases to Oracle with ease. (Why did I do this? The client wanted Oracle, so I ported our PG product to it.) The translation of some rather intensive PL/pgSQL to PL/SQL was almost trivial, with a translator script I wrote in a day. The resemblance is so close that if I didn't know better (and maybe I don't), I would almost say PG "borrowed" some of its syntax from Oracle. Going back would be a little harder if some of the more obscure Oracle PL/SQL features were used, but probably not rocket science for most applications. There are other interesting resemblances - you can see very meticulous, almost obsessive Oracle emulation in the behavior of date/time stuff (search the PG source code for "Oracle" - beautifully commented stuff is in there).
With MySQL on the other hand, even without getting into an ACID problems discussion (some of which have been improved in recent releases), has a very poor feature overlap with Oracle, not a minor one being not having anything like PL/SQL.
I guess the thing that bothers me personally about this is that it is publicity for MySQL, subconsciously encouraging more people to adopt it over the (IMHO) much better PostgreSQL. I think that it will poison your mind to learn DB theory from MySQL. :) But
that is just my personal view and I encourage alternate viewpoints.
From the company that censors people pointing out how shoddy their in-house software is?
Yeah, so they'll offer the same mess of convoluted support that they do for their Oracle database. Big Deal.
I can provide Oracle support on a two-headed coin: Side A - you must have a typo somewhere; Side B - you'll need to find a work-around.
And, of course there'll be another user forum of everyone asking for the same help that you are (with very few useful answers).
"The large print giveth, and the small print taketh away" -- "Step Right Up", Tom Waits
Two things are very important for Oracle:
- For its platform to be the only one with real, honest-to-goodness atomic commits.
- For its platform to be the only one that's unbreakable ("can't break it; can't break in").
MySQL has not, and will not be a threat to Oracle on the first point, (Postgres, the only other threat on the first point, was nullified with Oracle's acquisition of the only backend to it with atomic commits), and the second point bears very close scrutiny. What does "unbreakable" mean? For one thing, it means 100% uptime. For another, it means that you the admin, can't easily break it either. Anything can be rolled back, or you can just stop using the (unbroken) database.Now when we hear "unbreakable MySQL" we have to ask ourselves: what does Oracle mean by unbreakable, and is it an offer to give MySQL all of the features that traditionally correspond with Oracle's image ("can't break it, can't break in")? No, they do not.
By "unbreakable MySQL" they mean one thing and one thing only: MySQL frozen solid.
Oracle's idea of unbreakable MySQL is a three-pronged approach:
- Transactions. A single transaction should be like a TCP/IP handshake. High overhead, high error tolerance and correction, high processing needs. MySQL now is like UDP. Oracle is like your EIDE bus. The transactions Oracle wants MySQL to use are the exact ones you couldn't imagine going on inside your computer, on any fast bus. When you realize there are database engines that handle a hundred million concurrent connections you'll realize how significant this is.
- Fault tolerance. Oracle's idea of fault tolerance for MySQL is RAID-1. Neither more, nor less. (Look at the specs.)
- Journaling. Oracle's idea of journaled MySQL is distributed MySQL, with each node being further out of sync than the last. This is hard to believe, but it's true.
That's about it. Beware the wolf who wants to guard your sheep, people!. . . to the Nine Circles of Oracle Support Hell.
What?
>"Serious question: What exactly is the advantage of Oracle over SQL Server? I asked that to >an Oracle DBA once, and he just got red in the face and stammered about having more options >to configure things the way he wanted. I asked what exactly he configured, and basically >got a lecture on Microsoft being evil. I then asked if he thought Larry Ellison was a >saint, and the conversation just continued to devolve.
>Serious question: why is Oracle considered so much better that SQL Server?"
If you ever run a LARGE datbase at the enterprise level, you will see the difference very quickly. When you are dealing with thousands or tens of thousands of users are millions of records, Oracle will kill SQL Server on performance and response time.
Also as already noted Oracle doesn't limit you to using a Windows server the way SQL Server does.
Having used various versions of Oracle, MySQL, SQL Server, and (God help me) even on occasion Access for the database behind various applications in different jobs, the only 2 I would recommend are Oracle and MySQL depending on the size of the database and the budget of the business buying the product. For small businesses that I have worked in before MySQL is great; it's free, and works well unless you are talking about large data sets or large numbers of users at the same time. For enterprise level systems like those used in government or extremely large organizations give me Oracle any day, but then you are dealing with budgets large enough that the cost of Oracle is easily dealt with.
C_Kode Software is releasing a new version of the MySQL Database. Very Unbreakable MySQL (V.U.M.) MySQL. This will be based of anything that we like and will prove to be better because I said it was. It will be very fast. We like to call it Vroom VUM! Does your app VUM? If not, shell out $50 a year to me and I will allow you to tell anyone your app VUMs.
Not quite true. I supported a large customer (a national, no nationwide, building society in the UK), that has several million customers in the DB, and a couple of thousand users directly logged onto it, and several thousand remote users. (this is SQL Server BTW), and its fine, fast and responsive.
:)
Now, the things we had to do to make this work are basically: use stored procedures.
Now I work with a large breakdown company that uses Oracle, and we've seen barely a difference. Oracle is just as performant, and just as scalable. Oracle support wasn't too helpful with a recent 100% CPU issue ("install all patches" they said, then they broke something else and their answer was "upgrade to 10g").
One big difference that you'll notice when working with both is locking. Oracle basically does row-level locking, SQLServer tries to optimise locks and escaltes them to lock pages then tables as you lock more and more rows. If you write your app without taking this into account, you could have problems with SQLServer.
One thing with Oracle - use an application server to limit connections, don't try to write a client-server app on it, each connection hogs too much memory and holds query cache latches for too long.
But of course, these 'issues' aren't problems if you're not just slapping any old code together to run against the DBs. As with everything, they all need some care and attention with how you're working with them.
I have also used Informix and DB/2 on an AS/400. For really, really big DBs - give me DB2 anytime. that really is unbreakable, and IBM will give you a 'free' AS/400 specially optimised to run it on
Obviously, you have not used PostgreSQL. PostgreSQL is Oracle-lite. MySQL cannot be compared to Oracle unless you are smoking something or your requirements would not require Oracle *at all*, *ever*.
Postgres, the only other threat on the first point, was nullified with Oracle's acquisition of the only backend to it with atomic commits
What Postgres backend did Oracle acquire?
Jan
It takes a real man to ride a scooter
The same reasons being most likely that by "supporting" MySQL or PostgreSQL they are effectively suffocating the companies who continue to develop of those databases and probably poaching a few sales too. Eventually those other companies might go down the tubes or at least suffer financially and Oracle can turn around and claim "see you can't trust open source, buy Oracle".
I wonder why MS doesn't try the same thing - push out Microsoft Linux, complete with a free Vista / Windows runtime included, support the thing until Red Hat or Novell go bust and then shitcan it. Naturally the proprietary layer sitting over Linux would not be open sourced.
Rorschach1,
:-) In either case, we get very good gas mileage by comparison!
Indeed we view MySQL competing in different markets from the legacy closed source databases. We have focused on new applications, often web-based systems, ecommerce, reporting, analysis and so on, rather than traditional ERP applications. There are many features that DB2 and Oracle have of which they are very proud. And we are also proud *not* to have all of the complexity of those features. Our focus is not on features, but on reliability, ease of use and performance.
Charles Phillips of Oracle remarked at a conference I was speaking at that Oracle and MySQL are both in the transportation business, but Oracle is the 747 and MySQL is the Toyota. I think that is a very apt analogy. But if you prefer the M1A2 tank, so be it.
-Marten Mickos, MySQL AB
very good point. I'd mod this up if i knew how..
I think SQL Server 2005 is better from an administrators perspective. To be able to script anything from the GUI, makes it easier to perform tasks without spending too much time on figuring out how to write everything from scratch. Allthough you have excellent tools like Toad for Oracle, the GUI in the current version of SQL Server saves me a lot of time. I've tested Oracle on my most used application (100+ concurrent users. I know, it's not big), and SQL Server performs just as good as Oracle here.
MySQL is great if you want a lightweight, fast database that doesn't need to be terribly robust.
That isn't quite right. Let me fix that for you...
MySQL is great if you want a lightweight, fast database with lousy data integrity that doesn't need to be terribly robust.
There. Much, much better.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Oracle performs better in enterprise environments, hands down. Oracle Clustering is more intelligently implemented than SQL Clustering. PL/SQL scripts are easier to debug than those in MS SQL.
OTOH, SQL Server is extremely simple to install and administer for low volume environments. DTS Provides a nice simple transport mechanism. Enterprise manager, while kludgy, is relatively intuitive.
For fine tuning, Oracle provides finer control - but that's not to say that SQL doesn't provide a lot of control over DB Tuning features.
Then there are the little things that crop up over experienced usage - like the first time you try to take a MS SQL backup from one machine to another and end up perplexed for an hour. Or when you're 6 gig backup file won't copy from one machine to another without 3rd party software (really a windows issue, not SQL Specific). Or when you discover that you can't replicate certain tables or columns, can't copy blobs using sql scripts, etc. Things like that.
A lot of applications treat the database as a storage engine and leave platform specific performance enhancements by the wayside in favor of database-agnostity. Because of this, MySQL is much closer to being a legitimate competitor than you would think. People talk about "ACID Compliance", but really most applications don't need ACID Compliance and just because you can't do something one particular way doesn't mean it can't be done.
The translation of some rather intensive PL/pgSQL to PL/SQL was almost trivial, with a translator script I wrote in a day.
any chance you'd release that script as Free Software?
I don't have enough MS SQL 2005 experience, but MS SQL 2000 didn't scale very well. The implementation of "shared locks" and "lock escalation" in MSSQL meant that many readers + one big writer = near total database deadlock. The readers would be locked-out every time the writer touched a page they were reading. Oracle, PostGreSQL, and SQL 2005 support a system where readers never interfere with writers.
I know that there are big database features in Oracle that are way over my head and I can't go into. Some Google searches will give you some opinions. This comparison looks very well written.
PG does take a lot from oracle. Some of their features like large objects are spitting images of blobs in oracle and like you pointed out, similarities in the date/time stuff.
Haha Brilliant. What would PgSQL do?
"Sure there's porn and piracy on the Web but there's probably a downside too."
primarily that (a) it's a mature product that scales up in actual real-world examples (b) It doesn't require windows and will run on stable platforms like Solaris.
You won't understand that, because Windows fanatics rarely do understand why people don't want to use Windows for everything.
Nonetheless, it's true.
The thread here seems to question (a) the value of Oracle and (b) why this would be good for Oracle's customers. Here are my 0.0002 cents:
My current client is a large insurance company. (More than $7 billion dollars of policies a year underwritten by a staff of more than 1,200 people.)
We have lots of Oracle, SQL/Server, and MS/Access applications all over the place. The Oracle data is generally available to everyone. We have more than 50 analysts who use a combination of Hyperion (formerly Brio) and SAS to model the data.
Oracle's additional configuration options enable our Oracle servers to support phenomenally more people than comparable gear running Access or SQL/Server. In addition, we have really good SAN devices that are backed up every night.
However, the limited number of Oracle DBA's mean that users must wait (sometimes forever) to get their application written in, or ported to, Oracle.
Where the SQL/Plus Oracle code is controlled, documented, and fully SOX compliant, the same is not always true for the Access and SQL/Server code.
As a result, the individual departments are forced to use Access and SQL/Server. Their applications do not talk to each other. The data in those applications are "hidden" from people in other departments.
SOoooo...... users develop "personal" and "departmental" applications in Access and SQL/Server which we in IT find and port to Oracle when we can.
MySQL apps are generally easier to port to Oracle than SQL/Server or Access. (Never mind the application layer. That is a different discussion for a different time.) I would love to provide MySQL to departments across the board on servers that are supportable by corporate IT. Then users could build their apps on-the fly, expect support from my team on an ongoing basis, and faster conversions to Oracle in the long run.
Wouldn't that be sweet.
Live Long and Prosper - Thanks Leonard. You are missed.
Microsoft SQL Server (which is Sybase in diguise) has an in-memory lock structure; if your transaction acquires too many row locks, your locks are escalated (to page locks or table locks). While these rows are locked, readers are blocked.
Because of this, your are encouraged to keep your SQL Server transactions as short as possible. By default, isql DML commits after every statement, and you must use a BEGIN TRANSACTION/COMMIT if this is not what you want.
Oracle does not use a memory structure for row locks, and Oracle never escalates a lock (although lock types can be converted). Oracle records a pre-DML image of the row in a "rollback" or "undo" area, and any SELECTS against uncommitted DML will silently pull from the old version.
This has a few important implications... you can have long-running transactions and still query the tables safely; transaction volumes are limited not by memory but by disk space; unlike isql, sqlplus requires a "commit" for DML by default; and the "rollback" mechanism has been improved with "undo" segments to allow you to time-travel the database (i.e. show me the contents of this table 3 hours ago).
Synopsis: if you need simultaneous, non-blocking access to the database, steer away from SQL Server (and probably DB2 as well, if I've read correctly).
It never occurred to me, but what an inspired, evil way of killing off open source competitors like MySQL. By offering enterprise-level support for MySQL, it will kill the revenue streams that MySQL would normally get, and over time would starve them of money needed to grow. For a small company like MySQL to flourish, they need to increase the amount of money they get from support and services and the enterprise market is usually their best bet. If Oracle blocks them from this, it really throttles MySQL's growth as a company. Genius!
I wonder if Microsoft could potentially do the same thing. If they offered to give support/services for a brand of Linux, like Debian for example, and give low cost/high quality support for it and just swallow the loss like they swallow the loss for X-box, could this be used to kill Red Hat off in a few years?
why is Oracle considered so much better that SQL Server?
'cause you can't run SQL Server on a unix (linux/solaris) system (and even if you could, I wouldn't trust it---for a long while). And installing Windows on a 32 processor box with 128gigs of ram, and 30T of disk space, would just be a waste of resources.
On Windows, SQL Server is likely more robust (and faster) than Oracle. But then you limit your options by sticking to MS products in general. I have no love for Oracle either, but for a commercial DB for a -large- installation, they do a pretty damn impressive job.
In any case, for small stuff (which covers 99% of databases out there), MySQL or PostgreSQL is -way- nicer than either oracle or sql server.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
To be honest, if said person only knew one DBMS and not the other, they're not qualified to answer those questions anyway.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Postgres is fully ACID compliant
As is MySQL.
has mature support for just about everything
It lacks anlaytic functions.
Who are these Windows fanatics, outside of Microsoft? I notice a lot of Linux fanatics, and a lot of Mac fanatics, and a cute little group of BSD fanatics, but I only ever see marketing material from Microsoft, no real zealotry. I think you're setting up paper enemies to have a quick win.
Slashdot - where whining about luck is the new way to make the world you want.
Heh, you're new, right?
:)
Just hang around here for a while and (if you can bear it) participate in the discussions.
Soon enough you'll see the little drop-down boxes under every post and the "moderate" button right at the bottom of the page. (It took me *ages* to figure out how to submit my moderation when I first got points). In the meantime, you can find out about it HERE.
Hey, someone's gotta take care of the newbies
Nobody else has this sig.
I think you also have to check the box in your preferences that says "I am willing to participate in slashdot's moderation system" or something along those lines...
"Postgres, the only other threat on the first point, was nullified with Oracle's acquisition of the only backend to it with atomic commits"
No, it was the innodb for MySQL that Oracle acquired, this has nothing to do with PostGresQL. Unlike MySQL PostgresQL has always had attomic commits.
The ability to handle large loads isn't the only feature people are looking for when they choose Oracle.
I've had very little experience with PostgreSQL but I have heard lots of good things, but the fact is when a large company chooses Oracle over it it's not a comparison of the databases that's the reason, it's names, support contracts, insurance, guarantees, someone to sue.
> it's not a comparison of the databases that's the
> reason, it's names, support contracts, insurance,
> guarantees, someone to sue.
Yup, I bet you're right. Gives folks a warm fuzzy... even though the chances of actually winning a lawsuit against Oracle over some sort of database problem are approximately nil.
The Army reading list
Ah, I don't think Oracle wants to provide MySQL support for any of the following reasons:
- because there is a lot of money to be made
- because they think it is a better product than oracle
- because they want to "endorse" mysql
No, why would Larry Ellison want to provide support for mysql?
Really, just one reason: to further injure MySQL AB.
Look, he already bought InnoDB and Sleepycat out from under MySQL which robs them of important persistence layers (oh sure, but MySQL AB can spend a couple of years and millions of dollars to develop their own backends just proves the point). And now he's going straight for their income stream.
Oracle clearly sees MySQL as a revenue threat that they want to eliminate. This doesn't mean it is a great product - just a revenue threat. And this strategy doesn't apply to postgresql (and EnterpriseDB, etc) - but that's ok for now. Postgresql is probably 2+ years away from being the revenue threat that MySQL AB is today.
nice comparison found at wisdomforce . SQL Servers does catch up pretty well comparing to what they had in SQL Server 2000
Oracle and PostgreSQL uses MVCC to reduce the problem of locking.c c.htmlt gresql_mvcc.html
MVCC makes the system a lot more scaleable with a lot of writing going on.
http://searchwarp.com/swa9860.htm
http://www.developer.com/open/article.php/877181
http://www.postgresql.org/docs/8.2/interactive/mv
http://www.onlamp.com/pub/a/onlamp/2001/05/25/pos
Microsoft SQL Server 2005 also have some support for MVCC, but I haven't read up on that one. Microsoft SQL Server before 2005 did not have it.
You can easily notice the advantage of MVCC when compering MySQL and PostgreSQL. MySQL is fast until it gets a lot of writes and then it get slow until it dies. PostgreSQL have a more stable curve and can handle a lot more load because MVCC make the writes do not lock the reads.
This was a major advantage for Oracle and it probably still is because MS SQL Server 2005 is still a new product. MySQL is also catching up, but slower.
As is MySQL [mysql.com].
Haha. No, asshat.
There were several quick-and-dirty, throwaway scripts that were tailored for this conversion project. Essentially, we first converted by hand a sample stored procedure that had most of the features used, and got it to work. The script processed the other stored procedures according to the things that had to be changed. Finally, the results were manually adjusted (mainly to fix things Oracle complained about).
I just searched for these scripts and unfortunately can't find them. (: (This was in 2002.) It really was not suited for general purpose use, though.
But here is a short excerpt from the original and translated code to give you a flavor and even shows some tricky areas.
(Sorry, the "lameness filter" will not allow me to post the code excerpts - "too many junk characters". Does anyone know how to bypass this? There are about 150 lines of sample code that I want to post. I even tried the "CODE" formatting method and it still doesn't work.)
Informative? How ironic :-(
Microsoft SQL Server (which is Sybase in diguise)
How many times do we have to repeat it? This was true for old versions, there's not much left in from Sybase nowadays in SQL Server. Please get yourself informed instead of perpetuating wrong informations: http://blogs.msdn.com/euanga/archive/2006/01/19/51 4479.aspx
has an in-memory lock structure;
I have no clue why you point out that the lock structures are in-memory, which is btw good from a performance standpoint, but it doesn't imply anything in how the locking model works.
if your transaction acquires too many row locks, your locks are escalated (to page locks or table locks). While these rows are locked, readers are blocked.
First of all I must point out that readers are, of course, blocked only if the locks they are trying to get are not compatible with other locks being held on the same resource. The simplest case is when a writer has an esclusive lock which is incompatible with a shared lock trying to be granted to a reader. What is important, though, is that this is a perfectly valid model which is very useful in many scenarios. Furthermore it has been extensively documented at the theoretical level for dozens of years including the locking hierarchy escalation model to consume less resources.
Please se also my other comments at another post about this: http://developers.slashdot.org/comments.pl?sid=219 402&cid=17807944
Because of this, your are encouraged to keep your SQL Server transactions as short as possible.
It's not because of this, it's because if your scenario needs such a transactional isolation, it means you have to block and it follows that you need to hold locks for short periods if you want more concurrency.
By default, isql DML commits after every statement, and you must use a BEGIN TRANSACTION/COMMIT if this is not what you want.
Yes, and I'll argue that it's a good idea for several reasons.
First of all, let me clear this out, it is a good reason in a system that implements only locking (no row versioning) because people may leave uncommitted transaction blocking other transactions and the regular maintenance of write-ahead logs.
Secondly, even using a row versioning mechanism you can have problems leaving uncommitted transactions. More precisesly logical problems. What if you update some important metrics and forgot to commit? Maybe someone else makes some decisions based on the previously committed values instead on the new ones. This may or may not have a dramatic impact in your process.
Thirdly, it is required in transactional theory to mark all multi-statement transactions with a begin work and either a commit or rollback work. The way some database systems works is just by opening a transaction behind the scenes which is absolutely not intuitive. Expecially for people learning and when faced with immediate checking transactions (eg. primary key violation, what happens? has the transaction rolled back or only the last command?).
Oracle does not use a memory structure for row locks, and Oracle never escalates a lock (although lock types can be converted). Oracle records a pre-DML image of the row in a "rollback" or "undo" area, and any SELECTS against uncommitted DML will silently pull from the old version.
Again, it doesn't matter whether it's a memory structure or not, nor if it's implemented using logs. It's just a row versioning model, another well known theory for decades. Perfect in many situations, like reporting, but incorrect in many other (think at the classic banking account scenario).
This has a few i
MySQL starts getting useful for general use, but the marketing department and the engineers at MySQL AB has been lying for many years. You have been working hard to sell your idea that the world do not need data integrity. Many of us need some time to for you to be able to build up some level of trust after this.
I usually recommend PostgreSQL, Firebird, EnterpriseDB, Sybase, DB2, Oracle, Greenplum, Ingres, SQLite and others, but not MySQL. Why? The people and the company behind are not trustable. You tell the customers directly that they should not care about their data integrity and that proven academic standards have no use.
The development of the last few years has been better. MySQL 5.x is a positive step in the right direction. It is a long journey for MySQL AB, but I hope you keep focus and build up trust.
I will recommend SQLite for the typical smaller MySQL projects until then.
Unless you use savepoints, postgresql will rollback the entire transaction if there is an error anywhere.
From 2005:
d =13823400
http://ask.slashdot.org/comments.pl?sid=165697&ci
"Linux has commodotised the OS. MySQL and perhaps PostGRES are commodotising the Database.
All the money is upstream. Larry's customers are asking him why should they use Oracle, when MySQL et al does what they want. Larry want to sell them his other mojo, and that is where the money is. Why support the database when a bunch of other people will do it for you."
Winning against a vendor or even getting things fixed is not the point in most companies.
Think of it as you spending your company's/organization's money to help keep your job.
In most companies that's a viable strategy. When stuff happens, instead of the bosses replacing you (and also potentially risking their own butts), they just sue/replace the consultant or vendor.
This is your boss, you're fired for trying to post up source from our application. Only kidding.
Um, yes. MySQL's InnoDB and Berkeley DB engines are ACID compliant.
perl -e 'foreach(values %SIG){$_="IGNORE";}while(){}'
I have emailed a complete "before" and "after" stored procedure example to the grandparent that illustrates pretty much all cases involved in the translation. I am the owner of that code and declare that it is released to public domain, if the grandparent wishes to distribute it. While it is hard to back up this statement since I want to remain anonymous, all I can vouch for is my reputation on slashdot, which will have to be taken at face value.
The database engines may be ACID compliant, but I still have not managed to make mysql itself support ACID.
Example:
create table t(id int not null unique) engine="innodb";
begin;
insert into t values (23);
insert into t values (23);
commit;
select * from t;
Now this SHOULD return an empty set, but it return
+----+
| id |
+----+
| 23 |
+----+
1 row in set (0.01 sec)
(This might in itself be a stupid example, but this(That mysql will commit, even if the transaction contains error) is a real problem, when doing developing using java/php))
But maybe there is a
"I really want acid, not just rollback" flag that I just have not found.
Said the 986401 to the 989034. lol
Haha, fair point - but I don't see you doing it!
Nobody else has this sig.
This behavior is perfectly valid. Oracle does the same thing. This is a feature: you, the user, can choose to ROLLBACK or continue on error. Would you want a typo to abort a transaction during interactive use?
And he's absolutely correct.
The problem is that it also happens under non-interactive use such as from php/java and there it's a real problem..
I don't think starting with MySQL "will poison your mind". However, I think starting with Access, Excel, or FileMaker will.
You apparently are a DBA, however a "many hats" developer, such as myself, often works on things much smaller and less complicated than what you do every day. I think a good developer should know how a relational database works, and understand normalization. As I have gone along, I have made sure that I understood the benefits and costs of different data types, engines, and indices. As far as I know, these things are fairly standard across database software, so I don't think I have been "poisoned" yet.
If my applications grew to the point where I had to start optimizing, and I continued to use MySQL, then maybe, I would be "poisoned" but the day things get that complicated is the day that I hire a DBA. I guess what I am saying is that you can make a mess with any tool. However if you use good design practices, you can go a long way before the differences in database software are noticeable, and if you have done things right, switching may not be that much of a problem.
Long live the Speaker Bracelet
Rolo D. Monkey
The problem is that it also happens under non-interactive use such as from php/java and there it's a real problem..
Is there some reason you can't check the return value / catch the exception and decide how to handle the failure?
And he's absolutely correct.
My point there was that in some scenarios you don't have the choice to be more efficient (concurrency vs isolation, again) you just need a model where writing transactions get blocked by reading transactions. I'm not saying that this is most frequent scenario, but generalizing as the first poster did is pretty useless imo.
But the main point is that, imo, the intent of the post was really just to put in bad light any implementation of isolation levels that are not Oracle alike. I can read it between the lines but, just in case, the following statement:
sums it up pretty well.Expecially considering that SQL Server now has row versioning and optimistic implementations of isolation levels.
Maybe a good, and informative post, would have been one pointing out pros and cons of the different implementations in terms of both isolation and concurrency (plenty of them and a lot of practitioners that get lost).
Sorry, I can't help it but I see just product bashing in the original post.