Open Source vs. the Database Vendors 183
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."
Obvious (Score:5, Insightful)
Duh. Isn't that the #1 draw for the majority of OSS users out there? Sure there are some that are in it for the politics and others who actually try to contribute, but let's face it, the majority of people use it because it's free (as in beer).
Re:Obvious (Score:5, Interesting)
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.
Re:Obvious (Score:5, Interesting)
Re:Obvious (Score:2)
But they still aren't there yet. For example, try to figure out how to buy the mobile version of DB2. Or exactly which Oracle license you need.
By contrast, under MySQL things couldn't be simpler for users. Developers just have to grasp the dual licensing scheme, which isn't asking much.
Re:Obvious (Score:2)
Who are they imitating? Certainly not the MySQL folks, and certainly not for drag-n-drop db creation and development. To my knowledge, there is nothing comparable in the opensource world to these two companies' development products. I truly would love to see something similar (particularly for Postgresql), but to date I've not found anything.
Re:Obvious (Score:2, Insightful)
I have tried Oracle, and I was not happy with the installation. Debian is not supported, so you have to fool the install script to go ahead anyway. I needed a hard disk update because I was running out of disk space (several GB necessary). The installation went fine, but it doesn't tell you what its doing.
So now I have several java application web servers, some of which s
Re:Obvious (Score:3, Interesting)
This is a really good argument for letting developers decide the technology rather than managers. Personally I would generally choose Postgres because I like the way it works and I have a good knowledge of it. MySQL would be up there on my list as well. I've used SQL Server (and just about all the other commercial offerings) and found it to be good but over complex for a lot of applications. Any developer that is writting detabase driven apps should be at least familiar with most commercial databases and Po
Re:Obvious (Score:2)
MySQL as it now stands is probably the simplest real RDBMS for the casual shopper.
Actually, easy installation and great out-of-the-box performance has always been a hallmark of SQL Anywhere [sybase.com]. Feel free to download the free developer edition [sybase.com] yourself and see. (Yes, there are Linux and Unix versions available, not just Windows.)
Eric
Redscowl Bluesingsky [cluelessabout.com]
Re:Obvious (Score:2, Insightful)
Re:Obvious (Score:2)
Simply untrue.
1. Businesses aren't about minimizing expected TCOs, maximizing expected profits, etc. Those are one factor, but things like cost-certainty, worst-case scenarios, etc are also very important.
E.g. if solution A has a 95% chance of costing $100,000 for the next 6 years, and solution B has a 100% chance of costing $106,000 for the next 6 years, but solution A has a 5
Re:Obvious (Score:3)
$0 is nice but I bought my first copy of Slackware [slackware.com] long before I could download it, I even had to copy it to (I think 22) floppies from cdrom so I could install it.
And even after I have downloaded them, I've paid for FreeBSD [freebsd.org], plan9 [bell-labs.com] and Inferno [vitanuova.com].
Free as in Freedom is more important than you give it credit for.
Just one business case is that one can mitigate risk by having multiple OS vendors to choose from. I know that if my chosen OS goes kaput or gets litigated out of existence then I won't go with it. A
Re:Obvious (Score:2)
depends (Score:5, Insightful)
Re:depends (Score:2)
I don't know about this - as a small-company vendor myself, one of the main reasons I use OSS solutions anywhere possible is that "it can't get taken away" by changes in the licensing scheme. My license won't "expire" and the product won't be "EOL'd" as is so often the case with proprietary so
Re:depends (Score:2)
Now at that job, the management was leary of OSS and I was always pushing it hard. Why? Well, they wanted the backing of a known name. Me, I got tired of just what you bring up, getting locked in. It really ann
Not only free beer (Score:2)
This, and also because OSS is a way to avoid lock-in marketing techniques used by non-beer software providers.
Enterprises, specially, are not intersted only because it's free (beer) for them to use an opensource software, but also because it'll still either be free or damn cheap to switch to something else that better suits their needs,
Re:Obvious (Score:2)
Re:Obvious (Score:2)
I certainly could not have afforded a commercial Unix when I installed my first Slackware.
Large Wallets + Small understanding = nothing new. (Score:5, Interesting)
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
Re:Large Wallets + Small understanding = nothing n (Score:2)
Re:Large Wallets + Small understanding = nothing n (Score:2)
Re:Large Wallets + Small understanding = nothing n (Score:3, Insightful)
Has anybody else encountered projects for database-driven websites where the script monkeys want to use the database like text file system accessed with SQL, and do all of the logic in script on the web server? I suspect that people understand procedural code most readily, and despise thinking in the set-theoretical terms of SQL. I used to be that way, until I started realizing
Re:Large Wallets + Small understanding = nothing n (Score:2)
Re:Large Wallets + Small understanding = nothing n (Score:2)
Re:Large Wallets + Small understanding = nothing n (Score:2)
This isn't just a Java problem.
Mapping the Database hierarchy directly to the java class files is not necessarily a bad thing. It becomes a bad thing when you try to load and access it. :-P Meaning that you have to be careful and consciencious about how you manipulate things and where your transaction/session boundries. The use of entity beans is the greatest offender of this, followed by hibernate abuses. At long as you do not manipulate, or perform a minimun amount of manipulation, (like inserting pr
Re:Large Wallets + Small understanding = nothing n (Score:2)
Yeah, but updates should still be propagated to all the other app servers, leading to the same basic problems as in the lower tier. I have to think that the only reason the middle tier is more scalable is that the data integrity standards
Re:Large Wallets + Small understanding = nothing n (Score:2)
Re:Large Wallets + Small understanding = nothing n (Score:2)
The database is almost always the limiting factor- you can chuck in more web servers easily, but to expand the DB gets very complicated very fast.
Even when you work with decent mainframes, as I do.
Re:Large Wallets + Small understanding = nothing n (Score:2)
It's the data... (Score:5, Insightful)
And if you've paid for Oracle/DB2 and you're training your staff on and using Oracle/DB2 anyway then it doesn't make a load of sense to introduce different RDBMS systems that your DBAs and administrators are completely unfamiliar with, especially when you've got that Oracle box sitting there underutilised.
Ultimately you're right, 95% of apps could be served perfectly well by mysql, postgresql, msaccess, filemaker etc. Corporate IT depts should really create two categories of RDBMS systems, vital and casual. The vital ones being the core business operations and casual being everything else.
I've been fighting to get this done. (Score:4, Interesting)
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.
Re:I've been fighting to get this done. (Score:2)
The downside is that the database people need to become familiar with TWO different databases (or more depending upon the other apps).
Very true. For a company with a large DBA group, it might make a lot of sense to have a couple of their DBAs specialize in an open source database, so that they can have the best of both worlds, as you've mentioned. However, a smaller shop would probably only have the staff to support one database. What they choose depends on how much they value the support they'd get fro
Re:It's the data... (Score:3, Interesting)
What kind of guarantees do they actually provide? For all of Oracle, IBM, and PostgreSQL the likelihood of a hardware error is far greater than the likelihood of a software error that leaves the database inconsistent.
So what, will Oracle pay you money if a software failure occurs? What about a hardware failure?
From a technical standpoint, PostgreSQL is probably more trustworthy wh
Re:It's the data... (Score:2)
Where did you get that fact? In addition, assume a hardware error occurs, will the DB software be able to guarentee that the date is in a consistant state afterwards? What happens if there is a software issue, who will help you with MySQL or PostgreSQL? With a big bank there are many legal ramifications to everything that is done, you need
Re:It's the data... (Score:2)
PostgreSQL guarantees that so long as the error doesn't have something to do with the hard disk. Many people leave "write caching" enabled on the disk, meaning that no database or filesystem can guarantee consistency after a power failure. Also, of course bad sectors or something could destroy data. This is the same guarantee you get from Oracle.
But take PostgreSQL, run at whatever load you want, pull the plug, and it
Re:It's the data... (Score:2)
Re:It's the data... (Score:2)
Re:It's the data... (Score:3, Informative)
Re:It's the data... (Score:2)
Thanks for the information.
Re:It's the data... (Score:3, Interesting)
you are very wrong. MANY companies depend on MySQL in the ways you mention and by spending the cash you saved in
Re:It's the data... (Score:2)
Re:It's the data... (Score:2)
Re:It's the data... (Score:2)
What if the building catches fire, how does MySQL's non existent live replication work? What about fallover databases? What about massive scalability? Its silly to talk about Oracle and MySQL comparatively the issues that Oracle has solved in the last 10 years are things that MySQL customers don't have to worry about yet.
5 years ago MySQL wasn't even ACID compliant. There is a range between a 13 year old with a
Re:It's the data... (Score:2)
As one of those big, corporate customers, I know you are right. I am familar with both, and things like Oracle's RAC just don't have an equivalent in the mySQL world.
But on topic, the question posed was "are all those features worth the money" (with the implication that many of those features are not used). Where I work, the cost of software for Oracle vs mySQL isn't even a factor given the relative
Re:It's the data... (Score:2)
Re:Large Wallets + Small understanding = nothing n (Score:2)
This said, I would probably go for somthing like Postgre or Firebird myself. But NOT Access, I've heard from our service department that the Access databases of a certain device tend to crash when they grow beyond 1 GByte.
Re:Large Wallets + Small understanding = nothing n (Score:3, Interesting)
I agree 100%. I have worked on plenty of development jobs where management wanted to use SQL Server (normally) or another big name database because they thought they had a lot of data. Typically we were storing a few hundred products and maybe 10000 orders. I voiced the opinion that that wasn't much data and an OSS database such as Postgres or MySQL would easily handle it. I've never recieved such dirty looks. I think the managers want the prestiege of using a "real" database.
Foxpro? You're on crack! (Score:3, Interesting)
You misspelled "hell no".
The problem with FoxPro is that people come to depend on it, and start building their internal applications around it without realizing that it doesn't scale.
I don't mean that it doesn't scale well, but that it simply doesn't scale at all. Since it's not a database, but a single-threaded client app that reads and writes files off a fileserver instead of making remote queries, doubling the number of users doubles the amount of network bandwidth you have
Not everyone cares about Coding... (Score:5, Insightful)
Re:Not everyone cares about Coding... (Score:2)
Absolutely. I'm a perfect example. Where I work we needed a new helpdesk system. Our original solution was built by one o
Re:Not everyone cares about Coding... (Score:2)
So if you have an personnel database and your app/database must handle job changes, and those job changes consist roughly of:
Are you sincerly claiming that a stored procedure is not appropriate in this case? Excepting a pathologically poor stored procedure implementation, your "do it in the app server" approach if anything puts the same lo
Re:Not everyone cares about Coding... (Score:2)
For updates, the app-server approach will put *more* load on the DB, because data has to be sent to the app server, and SQL coming back from it has to be parsed.
For reads, caching the data elsewhere can be a big gain. I've gotten 75% speedups in batch jobs by preloading data at the beginning of the process.
Re:Not everyone cares about Coding... (Score:4, Informative)
The Slashdot hive mind may not like the idea of being tied to a particular database or vendor but in the Real World businesses choose their databases carefully and stick with them for a long time, often forever. With this in mind you exploit every single option available when programming and stored procedures along with proper filesystem layout, column indexing and schema design are key to a high performance database.
Re:Not everyone cares about Coding... (Score:2)
There are two very different cases, which tends to lead to people talking past each other. Basically, database portability is important to software companies (who don't want to restrict themselves to selling to Oracle shops), but not to companies working on in-house systems.
Re:Not everyone cares about Coding... (Score:2)
Mod parent up. This is perhaps the most insightful comment in this entire sub-thread. FWIW, I think these days in-house systems (which would include hosted systems with a web front end) are a larger segment of the market. Maybe
Re:Not everyone cares about Coding... (Score:2)
maybe back in the days of token ring your argument made some sense.
With a quad 3.66Ghz xeon server and fiber to the switch there is ZERO performace difference between all stored proceedures and client side queries.
I know.. I recently proved this fact to the Sr DB admin who started in the early 80's here that his ideas may have been relevant before, but are becoming moot.
Storing a date as X days cince an epoch is stupid today and only causes hell for others late
Re:Not everyone cares about Coding... (Score:2)
I would be VERY interested in understanding your test case.
This came up a couple of years ago when I was working with someone who didn't understand stored procedures. They attempted to do the same work that one stored procedure was doing in their code.
It was hands-down faster to do in the stored procedure. Not even close. The stored procedure was doing 13 different SQL DML statements which had to be replicated in code. Thirteen round trips to the server (over the 100BaseTX ne
Re:Not everyone cares about Coding... (Score:2)
The stored procedure can take advantage of the fact that it can commonly find cached data in memory, which means that it's getting on the order of Gigahertz of bandwidth, as compared to 10Base100, which will provide (divided by 8 :-)) the equivalent of 12.5MHz, therefore providing superiority of about a factor of 80. That's nearly two decimal orders of magnitude (or, a b
Re:Not everyone cares about Coding... (Score:2)
1) Using stored procedures allows you to update your schema without changing the interface exposed to your applications. Think of it as (very rudimentary) OOP. The database is a black box, and the Stored Procedures are a defined interface to that black box that will not change regardless of what happens inside that black box.
2) Using stored procedures (IMO) actually makes it easier to change databases if you are doing anything remotely complex
Re:Not everyone cares about Coding... (Score:2)
Stored Procedures can be bad, but they also can be very good. I regard SPs as somewhat like inline assembler in C/C++ code -- it can give you *massive* performance boosts. Of course, there are times where the costs (lack of portability, requires more knowledge of relational theory, etc.) outweigh the benefits, but those are mostly for small databases. When you use 10M+ or even 1B+ row databases, doing table scans (which could take hours or even days) for a simpl
Re:Not everyone cares about Coding... (Score:2)
Do you realize what other features you give up when you give up stored procedures/functions?
-user-defined aggregates
-user-defined types
-functional indexes on user-defined functions
-set-returning functions
Sometimes you need these things for reasonable efficiency. Especially functional indexes! And user-defined types are an important part of the relational model.
Re:Not everyone cares about Coding... (Score:2)
Umm No. SQL code is quite simular in style. It is easier to move over say an Oricle Storded Procedure to MSSQL and Vice Versa then the convert a VB App to
Re:Not everyone cares about Coding... (Score:2)
Right. So you ideally want to submit one query to the database, that performs all of the changes using one network roundtrip, parsing one query, once.
That is what happens if you submit a stored procedure request.
If, instead, you have the application servers do all that work, the application servers will be firing off a whole flurry of queries back and forth. If there are 6 tables to update, there could easily be a series of a doze
Re:Not everyone cares about Coding... (Score:2)
How is that cheaper? Databases scale wonderfully you just buy hardware (heck most of the big ones use grid technology). Changes to applications can be nightmare of retesting which costs hundreds of times what lots of hardware does.
Re:Not everyone cares about Coding... (Score:3, Interesting)
There are a few classic examples of situations in which SPs aren't just not BAD, but they've very GOOD. One of the classics is anything that depends on aggregating tons of data, especially in some kind of a tight loop. Network bandwidth is not the iss
Can't hear you... la-la-la (Score:5, Interesting)
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.
Re:Can't hear you... la-la-la (Score:2, Insightful)
Re:Can't hear you... la-la-la (Score:3, Insightful)
Exactly. If you don't *need* Oracle, don't use it. On the other hand; If your database is the life blood of your business and downtime can cost your business it's life. You would be a fool not to use it.
Oracle is what it is and you pay for what it is. I use a mix of many different databases, but our most critical and complexed applications run Oracle. Why? Because the only way you will lose data in a Oracle
Open Source + the Database Vendors (Score:3, Interesting)
Re:Open Source + the Database Vendors (Score:5, Informative)
Re:Open Source + the Database Vendors (Score:2)
Why is it important to that the DB be OSS for you to develop your app if, as you said, you are going to migrate it to Oracle or DB2?
Both Oracle and DB2 provide migration tools to themselves from Sybase, MS SQL, Informix, MySQL, as well as each other.
If your real goal is to deploy to Oracle or DB2, it seems it would make more sense to start with a DB that both have easy migration paths from. Starting wi
Re:Open Source + the Database Vendors (Score:2, Informative)
Free (beer) DB2: http://www-306.ibm.com/software/data/db2/udb/db2ex press/ [ibm.com]
Free (beer) SQL Server: http://www.microsoft.com/sql/editions/express/defa ult.mspx [microsoft.com]
Now what?
Re:Open Source + the Database Vendors (Score:2)
Re:Open Source + the Database Vendors (Score:2)
That's a great idea. You should write a tool like that, and ask the Postgres maintainers to included with Postgres.
Re:Open Source + the Database Vendors (Score:2)
I think that the reason you got the responses that you did were simply because most people are of the opinion that you should develop for the target platform on the target platform. Not only is it easier, it saves steps, and it makes sense.
Re:Open Source + the Database Vendors (Score:3, Insightful)
Oracle about as complete as they come. In speed tests its pretty comparable to most other databases which are acid compliant doing the same things. There are good memory based databases which crush it but if you want to compare apples to apples I don't see any evidence for your claim.
If by effeciency you mean code size then I would agree with you the open source world has some very small databases which do a limited number of things
Re:Open Source + the Database Vendors (Score:2)
So, write one. Or, convince someone they'll make money by writing one. Since the tool you're describing is primarily targetted to Postgres users, I assume you'd want to talk to the Postgres guys about developing it.
Obviously, Oracle isn't going to write tools to make it easier for you to do Postgres development.
Re:Open Source + the Database Vendors (Score:2)
That's only true for programs that have already been written. You made it clear that you are going to target your development specifically to Postgres, and these tools would primarily exist to mitigate the risk of that decision.
Seriously, think about what you're asking. Choosing a software platform for a new project is basically about cost, ben
Re:Open Source + the Database Vendors (Score:2)
You have an existing, completed program you want to evaluate on Oracle?
Hands on source code (Score:5, Insightful)
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? 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.
Re:Hands on source code (Score:4, Interesting)
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.
Re:Hands on source code (Score:2)
Re:Hands on source code (Score:3, Insightful)
We used Oracle extensively at my first
We spent months trying to get an answer from
Well (Score:2, Insightful)
I'd be more comfortable running a system running a vendor dbms rather than an Open Source implementation - just because when shit hits the fan (which it invariably does), at least there's ultimately someone responsible for it.
Don't get me wrong; we run mySql for all small-midsize operations, but the bigger systems run Oracle purely because of this reason.
Re:Well (Score:3, Insightful)
But MySQL is a vendor DBMS if you want it to be. You can buy the product and support from MySQL.com [mysql.com].
However, even if we invent a hypothetical Open Source product where paid support isn't available, there are circumstances where I get really fed up of the "we can't use that, what if it
Re:Well (Score:2)
We're agreeing with each other
The key to this is to make an explicit and documented risk assessment, document acceptable downtimes and all that tedious project manager-y type stuff.
That way, if you specify an Open Source component, it breaks, there is downtime but you fix it, you can point at the documentation you produced.
"We documented that there was a small probability that an undiscov
Short Term Gain Is KING! (Score:5, Insightful)
This is a surprise? Maybe "back in the day" innovation was a significant part of the average business plan in the United States, but those days are long gone in today's business world where short-term financial gain is the only objective. Realistically, the only innovation going on today it that which is related to military use. Sad, really.
Re:Short Term Gain Is KING! (Score:2)
Think about how quickly multi-core processors are making it into the market. Is that because of short-term thinking? What about a company like IBM putting billions into Linux development, is that short-t
MySQL at $40 million per year. And that's fine. (Score:5, Informative)
Of course, this is a problem for Oracle. Building Larry Ellison's house cost far more than MySQL generates in profit. I drive by the place all the time. Under construction, it looked like a mall. Oracle stock dropped from $50 to $12 while the house project was underway.
XA / 2PC support still lacking... (Score:3, Interesting)
Both of the "big two" (MySQL & PostgreSQL) advertise XA support, but neither has complete support; as both fail to support suspend/resume. And while this might seem like a minor point, XA support is an absolute must if you want to do something like incorporate a database write and something like a JMS message into one transaction. Currently you can't do that with, for example, JBoss and PostgreSQL, as JBoss' transaction manager tries to do a suspend at some point in the process, resulting in an exception from the PostgreSQL JDBC driver. (As an aside: I haven't researched yet whether or not this is correct behavior by the TM, so this particular example might not be a problem with a different app server).
Clearly not everybody needs this level of functionality.. but for those who do, it's critical. By way of example - imagine an enterprise CRM system which uses JMS to federate data across systems by publishing events to a Topic when customer records are modified. You really need ACID compliance for both the database write and the message publish, or you get inconsistent data which is BAD, BAD, BAD. Yes, yes, I know there are ways you *could* get around this without using XA, but the point is that this is what XA is for and this is the direct, obvious, normal way to approach the problem. And by and large, the open-source databases just aren't there yet with the needed functionality.
That said, I believe they will get there in time. And in fairness, there may be a open-source database (possibly Ingres or Firebird) which does have full XA compliance, I haven't investigated them all in detial.
Support (Score:5, Insightful)
Granted some non-widely used software will only offer forums, chat, and lists as support options. But most major open source packages (including MySQL) does have professional level support available. Some open source companies (like MySQL and RedHat) offer commercial support themselves directly to the customer. Other packages have vibrant support communities that have sprung up around them and even companies that are quite successful offering commercial level support for several open source packages.
Saying that the reason people don't switch to open source software is because there is no support available is simply not true. It might have been true two or three years ago but not anymore. Take some time and investigate your options and you'll find there's a lot more available out there than you might think.
Re:Support (Score:2)
It wasn't true two or three years ago either.
It's a distortion of what people really thing, which is "I'm scared of deviating from the mainstream". People choose Oracle for the same reason they choos
Re:I like my 3 CD DB downloads from oracle (Score:5, Interesting)
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.
Re:I like my 3 CD DB downloads from oracle (Score:2)
Re:I like my 3 CD DB downloads from oracle (Score:2)
Expenses of that scale involve managers. At most companies the IT managers often do not have tons of development experience, and instead tend to have project-management experience and business-side experience. This is how they are chosen by business-side executives to head up IT.
These folks can't show weakness, and so they're going to tend to leave
Re:I like my 3 CD DB downloads from oracle (Score:3, Insightful)
They were resistant until I started with software costs. Linux distro - free. MySQL - free. MS Windows Server 2003 75 cal - $15,500, MS SQL 2005 75 user was close to $20,000.
Add my $7,000 development fee to that and they'd have paid $42,500 vs just the $7,000. Big difference as all they're paying for here is IP and I hand off all source and notes when the project is over. Yes, I own
Re:I like my 3 CD DB downloads from oracle (Score:3, Interesting)
Sure it is (Score:5, Insightful)
Whoever you paid for your commercial MySQL [mysql.com] or PostgreSQL [postgresql.org] support contract, of course.
There are many Oracle, SQL Server and DB2 specialists on the market.
So your contention is that a high rate of turnover in the support of those applications is good?
As an early adopter of software you take on the risk while others (including competitors) learn from your mistakes.
MySQL and PostgreSQL were publically released 11 and 17 years ago, respectively. If that's your idea of "early adopter", then may I also suggest other hip new technologies you might wish to investigate, such as TCP/IP, VGA graphics, and transistor-based memory?
Re:But who will my boss shout at? (Score:3, Insightful)
Re:But who will my boss shout at? (Score:2)