Slashdot Mirror
Open Source vs. the Database Vendors
bhmit1 writes "BusinessWeek has another spread on open source this week. Among them is an article about open source vs. the database vendors which focused on how businesses are looking to save money with open source (rather than using the source to innovate). From the article: "The databases work fine, but as data volume grows, so do the checks to Oracle, IBM, or Microsoft. Many users aren't clamoring for more features, and some don't even use the bells and whistles they already paid for. They would happily trade some to get their hands on the source code and a better deal." Disclaimer: that quote came from Sony."
In my work experience, I have concluded that the vast majority of "big name" database users vastly underutilize the features that the big bucks pay for. Many companies that generally only need a step up from MS Access but get sucked into Oracle or DB2 thinking that's the logical next step.
In addition, many database users don't have a realistic understanding of what constitutes a lot of data. I've met quite a few people that think a 10k row database is huge, and anything in the 1 million record range is absolutely gargantuan! To me, anything less than 1 million records is downright tiny. Seriously, many of these users don't need an "enterprise" RDBMS for scalability reasons, which is what leads many customers to open their wallets. Something like Postgres or MySQL would be more than adequate for their needs.
That is not to say there are not users who need the enterprise features, but it amazes me the amount of money that is dumped into features that most small to medium size deployments don't even use.
It is very educational to see how Oracle for example is used in real world deployments. Open source aside, I have seen many where the user may have been better served by just using a properly setup MS Access or FileMaker database!
-Pete
Soccer Goal Plans
Do you know what hell is?
Hell is having a product you have to explain to the customer.
Customers don't understand databases, so they're not likely to understand the difference between MySQL and Oracle. And, ironically, that might mean MySQL is where they ought to be. This isn't to disparage MySQL at all, but I'm just saying you can't explain the difference between MySQL and Oracle, you shouldn't pay the difference.
You may or may not pay for your lack of knowledge later.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
A company such as SAP (SAP) could be pivotal. The German software giant is locked in an applications war with Oracle, but the bulk of companies running SAP applications run them on Oracle databases. So even when SAP wins an application deal, it's often making money for its archrival. That doesn't sit well with ultracompetitive SAP, which already has a burgeoning partnership with MySQL. Closer ties there could mean more SAP applications on MySQL databases. Elsewhere, Red Hat (RHAT) has endorsed both MySQL and Postgres, as did Sun Microsystems (SUNW) last November.
So Oracle has now become Microsoft, pretty much resting on its laurels and claiming that its users are more than happy with them, while all-the-while, their users are shopping for cheaper and better solutions. If SAP were to out-and-out declare they like MySQL better and shift most of their DB usage there, Oracle would have a very large amount of egg on their face.
Let's face it: when you become the dominant leader of your industry, you tend to forget what got you there and you take it for granted you will always be there. I've used Oracle, MySQL, and Sybase, and I find the latter two to be a lot easier to work with than Oracle. Oracle is trading solid dependability for tricks and gimmicks, and in the end, no one wants to pay that kind of money for things they don't need or won't use.
GetOuttaMySpace - The Anti-Social Network
I'd love to develop my apps with Postgres, then deploy to Oracle or DB2 with an automated tool. If Oracle or IBM distributed a free (beer) one, I'd include it in my project plans. And if there were an open source tool for comparing performance of my app on each of those databases in real tests, I'd be more likely to make the switch - provided the tests showed an advantage.
--
make install -not war
It's certainly the only reason businesses choose OSS, or proprietary software. Net present value of TCO over the planning horizon.
Until now, the free databases lacked accessibility for "drive by" business users. You don't have time to explore every option, even if it might lead to a better decision. Install Unix to check this thing out? Not today thank you.
MySQL as it now stands is probably the simplest real RDBMS for the casual shopper. It's just as easy as MS SQL server, and MS is the only vendor who understands the importance of the casual shopper. Postgres is not far behind.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
From the article: "They would happily trade some to get their hands on the source code and a better deal."
How many are there who would actually look at the source code of a database, work on it rather than develop new applications based on it?
Let me rephrase the excerpt from the article:
"Some users would happy forego certain features present in commercial databases if (1) it means reduced cost and (2) you access to the source code."
Why stick with expensive Oracle or DB2 if PostgreSQL does the job reliably enough and it's free? That's a no brainer.
I think you're asking, "why even look at the code if it's working?". Absolutely right. If it ain't broke, don't fix it.
But, if there's a feature missing that you require, then for certain businesses -- not all -- it may well make sense to add code yourself. A tech company may underutilised coders on the payroll: it may be cheaper to get them to code and support that feature than it is to sack them.
A large corporation (Sony, 3M, etc.) might need to deploy that feature in hundreds of places. Paying someone to code it gives them a lot of bang for the buck.
If database A works, then they are going to stick with database A until conditions change drastically. It hasn't happened now and doesn't seem like it will happen in the near future.
Successful businesses always look to reduce costs. If database A works, database B is $10,000 per year cheaper to license and support, the migration will cost $20,000 and you expect to continue using the system for over 2 years, then (cashflow allowing) it's a no-brainer to move. The only thing stopping you would be lack of business agility.
It is not IT's job. IT just gives everyone the pricing based upon how many 9's of availablility you want and the database/server licenses.
If the user balks at that, the database can be put on the far less expensive PostgreSQL/mySQL server.
The downside is that the database people need to become familiar with TWO different databases (or more depending upon the other apps).
The upside is that the company saves a LOT of money in licenses and such.
The user says "This is vital". IT staff start adding zeros to the price tag of the application. Seriously nobody in the IT dept is ever going to suggest something like mysql or postgresql for something like the corporate accounts or other financial transaction backends because people like IBM and Oracle guarantee that when the power goes out, the transaction completed, or it didn't happen at all.
you are very wrong. MANY companies depend on MySQL in the ways you mention and by spending the cash you saved into hardware I also can guarentee that the transaction completed or it didn't when the lights go out.
It's called decent hardware, decent Backup, decent UPS. my servers can run a FULL 45 minutes on UPS before they haveto start shutdown proceedures. coupled with Battery backup RAID cards and a raid 51 and I got huge stability in hardware for the cost of the DB.
You act like nobody but some 13 year olds with a website use MySQL. I suggest you take a look at the mysql website and educate yourself with their information.
Do not look at laser with remaining good eye.