Slashdot Mirror
How Real Is The Open Source Database Fever?
J. Misael G. points out a NewsForge article on recent moves by some database vendors to loudly release (some of) their products as open source, asking the vital question "How much open source beer are these newcomers bringing to the database bash, or are they simply coming in and asking where the cups are?" (Slashdot and NewsForge are both part of OSTG.)
Mr. Shimp, get a clue... we're simply not going to buy your pitch without looking at other decent (free!) alternatives.
Sigs cause cancer.
I think a lot of it is PR. If you take a look at a lot of the advertisements that include the words open source, they use it like a buzzword. It gives me a kinda woozy feeling that I don't like.
I'm not as interested in their Open Source beer. I want more of their Open Source speech - not just all the marketing hype we can eat, but shareable code, code, code. I want Postgres transactions in MySQL APIs. I want Oracle's scheduler in Tomcat's JVM. I want to pay them for tech support, so I can get my FrankenBase to work, making me rich, and everyone else wise. Free the source, Larry!
--
make install -not war
The fact that even small companies are paying hundreds of thousands of dollars annually for a SQL database solution just serves to underscrore the disconnect between business managers and information technology divisions. Business managers actually believe they need to spend these large sums to ensure data security and integriy. More so than in any other area of IT purchasing, money spent on DB is totally out of synch with the real underlying cost-benefit equation. These prices were justified back in the days when hardware was primitive and expensive, making state of the art software algorithms worth an order of magnitude more valuable than they are today. With today's hardware, virtually any credible SQL Engine code-base would run the largest corporation. The prices are purely a product of marketing and a huge gap in understanding. wwww.SoftwareObjectz.com
http://www.softwareobjectz.com
Now you weigh the degree to which you accept the veracity of the story accordingly, maybe confirming the accuracy through a non-conflicted source before making a bad stock investment or product purchase.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
(If the project is important/popular enough, like mysql for instance)
This makes it really easy for open-source databases to step-in since there is no lock-in. Later on if you figure out you need a big honking Oracle/DB2/whatever you can easily change your mind.
Like Java makes the OS and HW a commodity these tools makes the database a commodity and by definition commodities ends up being really cheap. And it's kind of hard to find cheaper than free ;-)
My favorite play is to develop on Hypersonic/McKoi and deploy on PostgreSQL. No sweat.
TCAP-Abort
fairly certain that the commission earned by selling $100,000 worth of software beats selling a $100,000 house by a wide margin. But, you're right Oracle clients spend a whole lot more than that on average. I've seen ODBC drivers for Oracle alone go for >$30,000
Generic OR systems tend to not take advantage of the underlying DB's capabilities, and in any application where spending the money on a real DB makes sense, throwing all of that away by using auto-genereted OR is a shame.
ODBC was cool, but i think reality has shown that in many cases, changing DB backends just doesn't happen that often. The example you cite, develop in one place and deploy elsewhere, doesn't really seem to have much real world justification, since development SKU's of most DB's are free (i.e. if I'm going to deploy on MSSQL i'll use MSDE or the developer license of full MSSQL that comes free with the appropriate MSDN or VS skus)
OR is also a neat idea, and im working on a product that has done a fair bit in the OR space, but i look at the SQL code we're cranking out and it's a shame compared to what i'd do by hand.
It's a tradeoff I suppose between runtime performance, DBA managability, and DBMS feature use on one hand, vs design encapsulation, design aesthetics, and buzzwordiness on the other side.
Java has tried to make a lot of things commodities, but alot of what's going on in java is layering/abstraction for layering and abstractions sake.
My opinions are my own, and do not necessarily represent those of my employer.
Warning: I am an Oracle DBA. I have been working as an Oracle DBA / developer for 10 years.
I absolutely believe that the open-source database choices out there today (MySQL, PostgreSQL, Sleepycat) are more than adequate for 90% of all development being done, especially the small- and medium-scale stuff. I'm glad that we've moved away from flat-file systems for small-time web work. It has forced developers to understand their data structures, which is a huge step forward for everyone. Developers today have a far greater understanding of their data, and databases in general, than they did 10 years ago. They understand relational models better, they understand abstraction better. That said: there are two things everyone should understand about the way Oracle thinks about databases (and its customers):
1) Oracle exists solely to serve the top end of the market. They're not really interested in anything else.
2) If you can afford it, it pays to start with Oracle first. For small installations, it's not as expensive as you think, especially if you forego the support. Why do this? Because if you find out later that you needed a serious database solution and need to make a back-end change from something like MySQL, you are in for a world of pain.
This is Oracle's bread and butter. I don't expect to be hurting for work for a VERY long time.
"guru + MySql > idiot + Oracle any day of the week, for 99 out of 100 common cases"
If you were talking about almost any other pairing of apps, you would be correct. However, I can pretty confidently say that there's no way you could even come up with 100 data management scenarios where both Oracle and MySQL would be appropriate. I'd be impressed if you could even come up with 10.
Can you use Oracle for nickle and dime stuff like small business customer management or a bug tarcking system? Yes, but why in God's green earth would anyone ever want to go through that expense and learning curve?
Can you use MySql to manage the 2.5 million line items that support military operations in the Western Pacific (used to be a supply officer) and balance them off of the 65,000 maintenance items with respect to the 10,000 open orders related to them on any given day? And then can you make it flexible for reporting and integration with other systems? Come talk to me when MySQL's ODBC interface is actually ODBC COMPLIANT.
In the mean time, no ammount of skill on the part of an orange producer will make an apple into a better tasting orange than one that any idot could pick off a tree and hand to you.
I've dirtied my hands writing poetry, for the sake of seduction; that is, for the sake of a useful cause. --Dostoevsky
very public open sourced death
Not very likely. And not a very good idea either. Until you show me something in the open-source world that can do 1000+ transactions per second, with complete atomicity, and ability to pull the plug on that system and then seamlessly roll it back to the exact moment in time that it was at when it died... Well, you're not replacing Oracle with anything less in the enterprise space.
By the way -- the "painful" part of converting from an OSS database to Oracle isn't the data conversion, export import, etc. That part is dead easy. The hard part comes when you start customizing your solution to take advantage of some of the huge performance-gaining features that Oracle provides. You have to start figuing out what parts of your application-layer code can be moved to your database, and making those changes at the second and third tier accordingly. You can create massively fast, very complex database systems with Oracle, but it's a very specialized area.
I'd be all for complete transparency of database from any application, but when you do that you encourage, no, you force, the least common denominator solution.
i write software for a business of web-based telephony that has half a million users. they make payments online, make calls (that generate call records), handle customer support and they have to make periodic settlements with the call minutes provider.
Ok. It can be done, but it is more dangerous than it is with something like PostgreSQL.
when we began building the software, we all though that oracle was what we required. i spent two days on oracle site trying to figure out which oracle i need to buy. finally, i gave up and started working with MySQL that was available on our RedHat server (thinking that we will switch to Oracle when we get it).
Reread what I wrote. Oracle has some features which some large enterprises will require and are not reasonably available on open source databases. However, these are not commonly required, so it is more of a niche market. (large 24x7 databases).
The main reason for MySQL is that we find it pretty easy to optimise queries and get support. source code availablity is a big plus. It helps the gurus better understand the internals.
All the more reason to use PostgreSQL. And besides you don't have the licensing issues you have with GPL's client libs in MySQL.
Don't confuse cheap databases with free databases.
Not at all. I said Firebird and PostgreSQL are great databases. They are both Free. I just have issues with the fact that MySQL tries so hard to fail as little as possible that it quite often sets one up for serious data integrity issues later. This is fine for content management. It is NOT OK for anything where the numbers must be accurate.
Also MySQL is a "cheap database" in another important respect. MySQL basically functions as a simple SQL-like non-volitile (for the most part) cache for your app. This is fine, but here are a few things that MySQL cannot do well:
1) Manage and automatically maintain your data (triggers)
2) Allow on-the-fly presentation of data independent of its stored form (Views)
3) True arbitrary-precision arithmatic (Numerics are converted into floats for the purpose of math operations, which is not good if you use them to store, say, money, so you MUST store money in INT fields in MySQL).
MySQL is pretty much a tough guy.
Not to start a flame war but are you actually even looking for a relational database management system? In this case, MySQL has enough problems and deficiencies that it is just not good enough for anything important. I guess if all you want is a SQL interface for some basic objects and you don't care about truncation, then it is not a problem.
LedgerSMB: Open source Accounting/ERP