Slashdot Mirror


Are Expensive RDBM Systems Worth The Money?

Death of Rats asks: "What are the actual advantages of high-end Relational Database Management Systems (such as Oracle) over the free or low-priced solutions? Is it worth paying the 10 to 30 thousand dollars (or more) for Oracle, when you can do (as far as I know) everything it can by using ASP with Access/MSSQL for Windows, PHP/MySQL for Linux, JSP with JDBC connections for most platforms, or any number of other free or cheap systems? Is there a considerable speed increase, or is there enough more functionality to warrant the outrageous costs? Are some of the technologies more suited to different tasks? Any time I have needed to use databases, the open-source solutions have done fine, so I am skeptical."

There is no one-solution-fits-all answer to this question, as it really depends on the requirements of the task at hand -- which will in turn determine what one needs from an RDBMS. I'm sure there are tasks out there which better suit the high-octane RDBMS systems, but what tasks do readers feel still need that kind of power? Has the distance between Enterprise RDBMS servers and the free alternatives shortened at all?

15 of 472 comments (clear)

  1. Remember by LoCoPuff · · Score: 4
    You aren't just paying for x features, although that is part of it. You are paying for service and the name/reputation of the company behind it.

    Just like that old phrase says, noone ever got fired for buying Microsoft. The same goes for Oracle.

    There is also the faction that will say that MSSQL cannot scale up to what Oracle can. I tend to agree with this line of thinking, but to each his own. In the end, most companies that have the money will end up purchasing something like oracle, just because they know they have a billion dollar company that has proven itself again and again and again.

    Just my .02USD

  2. Data is easy; robustness, backup etc. are tough by Get+Behind+the+Mule · · Score: 4

    When I first started working with Oracle (I'm a certified DBA now), I often had the same skepticism. I had worked with MySQL before, and couldn't understand what all the hype and the expense was for. What's the big deal about storing data in tables and querying them with SQL statements? No doubt there's a bit of sophisticated computer science that goes into that, but surely there's a limit to how complex it all can get. Why the hell does Oracle have to be so damn complicated (I hated trying to understand the docs, which always leave out the forest for all the trees), not to mention expensive?

    After a while, I understood that as far as representing tables and data and SQL statements is concerned, this really is true. About this part, the questioner is right: An open source solution will represent your data just fine, no reason to pay out the nose if that's all you need. And MySQL is still almost always faster than the expensive commercial RDBMS's. But tables and SQL statements are only one small part of a database application, and may not be the most important part.

    What you're getting for all that complexity and cost is all of the extra services that come with the data management, and these things really are worth it in many projects: Constraints that enforce data integrity, safe transactions according to the ACID principles, robust backup and recovery regimes that really can survive the worst catastrophe, distributed computing and clustering (for high availability and distributed load), and a lot of parameters to tune. All of this stuff seems like add-ons, if all you think about are tables and SQL statements. But for many applications, the data model is not what matters most; these things are by far the most important qualities of your RDBMS.

    Oracle RDBMS's still could stand to be less expensive and complex; but I see the justification now much better than I used to.

  3. If you have to ask... by jalefkowit · · Score: 4

    ... you've already answered your own question. When you need Oracle or DB2, believe me, you will KNOW it, or you're a moron and beyond hope anyway. At my current position I'm managing a Web team responsible for a site that lets users build complex queries that then sling around 16GB databases. We're using MS SQL Server and even with that we look covetously upon Oracle's reliability and scalability. There is no way on God's green earth I'd try to do this in MySQL. I love MySQL, but it's just not ready for prime time for these kinds of applications. Which is why I say you'll know when you need it; if there is any question in your mind, you probably either don't need it or aren't experienced enough to know what you need in the first place, so be careful that you don't put your Free Software Advocate hat on over your Responsible IT Professional hat :-)

    -- Jason A. Lefkowitz

  4. Re:Remember [Inertia] by Stephen+Samuel · · Score: 4
    One of the things that people will pay for is the fact that so much development is already done on Oracle. I worked for a company that wanted to do some work with Real Networks. They had their back-end done on Oracle. Do you think that we're going to pay them $150K to redevelop their stuff on MySql, or put out $20K for a web copy of Oracle???

    Then there's the case of the company who's DB is worth $1M/hour when it's down. Who are you going to sue if MySql goes down for a day? Disclaimers aside, Oracle actually has some money you can go after.

    Where the development has already occurred on an OS DB, there's lots of reason to keep it there (as long as it doesn't break because of an inherent design problem/bug). Similarly with a big $$ system. In either case, the cost of the database is usually small compared to the cost of redevelopment and/or breakage.
    --

    --
    Free Software: Like love, it grows best when given away.
  5. PHP/MySQL for Linux = Bad Example by uncledrax · · Score: 4

    Although I love and use MySQL (with PHP and Nix), it is DEFINATELY NOT a full features RDBMS similar to Oracle. (last I saw, it didnt support Views, sub-selects, and a buncha other stuff). Interestingly enough, we are starting to use Oracle 8i here are work, and it offers some neat things like running Java Inside the DB (which makes data-processing faster, but puts the load on the DB Server). Also Oracle instance replication is neat.. you can just have a buncha boxes running Oracle with something similar to Hot-Swapable Databases (think Load Balancing, which I know the MySQL ppl where playing with at one time).. I'm no Oracle Expert, but it is definately More robust then MySQL / Access / MiniSQL, etc, but I would only consider it for Enterprise level apps.. -- Insert whitty line here

    --
    ----- The internet has given everyone the ability to have their voice heard equally as loud.. even if they shouldn't be
  6. Commercial RDBMS, yes; Oracle, no by /dev/zero · · Score: 4

    IMHO, Oracle is not the price/performance leader in the commercial RDBMS market, nor is it the easiest with which to develop or to administer.

    Sybase has long combined relative ease of use, development, and administration with pretty good performance. Lately, though, it seems Sybase would rather be in a different market -- not sure what market, though.

    For projects which require a commercial RDBMS, I now choose DB2 UDB v7.1. And, yes, I tend to run it on Linux. It falls between Sybase and Oracle in the ease of use, development, and administration department. Performance-wise, for the kind of work I do, it's at least as good. Price-wise, it's a better deal.

    Culturally, I rank Oracle alongside Microsoft. No, thanks!

    PostgreSQL is under active and aggressive development, which is bringing major new features, such as outer joins, to their product. Version 7.1 should be out by mid-March. For small and medium projects with limited budgets, it's almost ideal. (I'd like to see stored procedures which can return results sets.)

    There are many smaller companies and organizations who can benefit from web-based applications, but who have limited budgets. All of the commercial RDBMS products have fairly hefty licensing for Internet connectivity. That can price many of these organizations right off of the web (or force them to violate the license agreement, exposing them to costly litigation). PostgreSQL (and MySQL, I'm sure), are a viable solution for these businesses.

    When I get some time, I'm going to try implementing one of my DB2 projects in PostgreSQL 7.1, just to see how it does. I already know I have to re-write the stored procedures as queries, so there will be a labor impact. It will be an interesting experiment.

    Gordon.

    --

    He that breaks a thing to find out what it is has left the path of wisdom.
    -- J.R.R. Tolkien
  7. here's a link to an online book you NEED to read by StandardDeviant · · Score: 4

    it's quite informative (at least read the first chapter): SQL for Web Nerds by Philip Greenspun of Philip and Alex's Guide to Web Publishing fame.

    Seriously, go read it. It's an afternoon well spent, in that hopefully after reading it you'll understand why comparing MySQL to Oracle is comedic. You have to understand your tools before you pick which one to use (MySQL is for your MP3 id3 tags, Oracle is for your hospital's data storage or for your credit card company's data storage.)


    --
    News for geeks in Austin: www.geekaustin.org
  8. Re:Web sites != large amounts of critical data by Anonymous Coward · · Score: 5

    North Carolina is entrusting their medicare system to some dude writing one page porn sites, are they?

  9. Scalability and application support by jabbo · · Score: 5

    What do you pay for? Well, mostly you're paying to see your pillow more often, or at least that's what the vendor is trying to sell you -- peace of mind.

    I have (lately -- SQL 7, not just SQL 6.5) seen MS SQL databases that buy the farm every night and get rebooted, and this is referred to as "more stable than before". I've watched MySQL crumble under heavy concurrent read/write loads on large tables. I still haven't figured out an easy way to carve up PostgreSQL backend storage so it scales more like Oracle. And I've thus far managed to make every (yes, EVERY) database I've ever used core dump. I'm working on DB2 at the moment; apparently it runs across x86 Linux clusters, which of course is something I'd like to crash. I got Oracle 8i to crash (finally!) earlier this summer. That was unusually difficult; Sybase and Informix were relatively easier. So, when you go the commercial route, you're paying for features, branding, and a lot of stuff you already get from the free RDBMS packages. Plus, more people tend to know about the bugs (every last RDBMS I have seen has at least some bugs).

    BUT when you get right down to it, even Postgresql (my favorite free database) simply does not have the application support or PROVEN OLTP scalability of something like Oracle. Today someone batted around the idea that "DB2 is okay up to around 10 or 15TB, but I talked to some banks and oil companies, and they say that beyond that, it just falls apart". It may be the case that Oracle scales a little better than DB2, but up until recently, the top 10 (size-wise) OLTP databases on earth were running NCR Teradata, IBM DB2, and I think there may have been one Oracle customer in there. UPS's database, the largest active OLTP database, was only around 12TB last time I looked.

    12TB of live data is a HUGE amount. EMC's top-of-the-line Symmetrix, a piece of equipment costing a cool $3.2M, just barely fits 12TB if you're running everything mirrored. God forbid you blow out the cache on that monster. And of course there's the question of backups...

    Basically, if you're tied into a vendor's specs (eg. "We only support MS-SQL here at Affymetrix" or "ArsDigita only supports Oracle as our ACS backend") then you don't have to choose, just get out the wallet and bend over. No lube for you!

    Otherwise, in my neither limited nor hugely abundant experience, MySQL and Postgres work pretty damn well for read-only data marts and low- to mid-volume read-write backends.

    Beyond that -- if MySQL can't handle your OLAP needs, and Postgresql can't handle your OLTP needs -- then maybe you have to look at Oracle or DB2 or whatever. But by then I strongly suspect you'll know why they charge so %$@#ing much :-).
    The differences are fairly marginal, but if you need them, you need them, and that's the end of it.

    --
    Remember that what's inside of you doesn't matter because nobody can see it.
  10. Two things by the+red+pen · · Score: 5
    1. Scalability. Open-source databases, in general, haven't endured the real-world conditions that Oracle, DB2 and MS-SQL have. If I compile Postgres for an RS-6000 it should kick ass; but will it? How much will it cost me to find out that it can't hack it? When we're talking about that kind of performance, we're talking about mission critical apps. As far as MS-SQL goes, the scalability issues are that it only runs on Intel hardware (where are you going to go today if that's not fast enough?) and it eats resources at a much higher rate than competing solutions.

    2. Compatability.Hopefully, you are not in this situation, but a lot of application only "work" with one database or another. Even APIs such as JDBC that offer cross-platform portability can't port your stored proceedures. If you are starting from scratch, you can avoid or mitigate such portability issues, but if you need to integrate with some other COTS, you will probably end up with a narrow list of DB's it "works" with. Chances are, MySQL won't be on the list.
  11. You get Oracle for your 10-30K by rho · · Score: 5

    Like it or not, Oracle is worth every penny, assuming you can afford it. If you, or your client, cannot afford the (admittedly) big bucks for an Oracle licencse, there are plenty of free (and Free) solutions available.

    What do you get with a 10-30K (or, in my experience, a 50-80K) license? You get Oracle's years of development and expertise in managaging some of the biggest and baddest installations. Think 500-1000 gigabyte DBs in constant use for 15 years.

    You get a whole bucketful of trained and talented DBAs (who are worth every damn penny of there high 5- and 6-figure incomes) who grok Oracle syntax.

    You get Oracle Corporation's culture (at least, I hope it's still the culture). At Oracle, the technologists create cool stuff and pay the marketing department to find or create a market for said cool stuff, rather than marketing dictating what technologies are created. Thus, when you visit Oracle, you find 3 or 4 products that do nearly similar things, or overlapping technologies. (I think this is a good thing -- others may disagree)

    Finally, you get name recognition. Don't laugh this off -- it's worth a lot of money to some people. If I say "Let's do it in Oracle", people respond, "Yeah, that would be best." If I say "Let's do it in PostgreSQL", I hear "Huh?".

    It boils down to: If the money is there, spend the money on Oracle, and advertise that fact. If the money isn't there, use PostgreSQL, and just say you have a RDBMS back-end.

    (Oh, MySQL isn't a RDBMS in my humble opinion. It's a fine solution for certain problems, but don't confuse a SQL interface to a filesystem with a true ACID-compliant RDBMS. Future versions of MySQL promise to alter this perception, which may change the dynamics.)

    --
    Potato chips are a by-yourself food.
  12. Three Main Reasons by PureFiction · · Score: 5

    There are a number of reasons why you would pick any particular RDBMS, but I have seen three which come up most often and are of the most importance.

    Support

    This is a big one. And an enterprise scale RDBMS needs a lot of support. Ever wonder why some Oracle DBA's make more than skilled developers? Administration of a large database is not trivial, and these databases often run the core of a corporation. Mission critical to the extreme is common for these systems (Hence the reason Oracle can charge millions for a large Oracle Applications ERP installation)

    Performace

    These big databases are built to handle huge data sets. Oracle supports all kinds of direct interfaces to read/write directly from a SCSI/Fibre channel RAID setup. A number of the Oracle extensions, or custom application also have to be extremely fast given the amount of data they are working. PL/SQL and embeded SQL, OCI, etc, are all tools to allow maximum performace with large heaps of tables and rows.

    Add-ons

    And by this I mean extra pieces of functionality or applications that are only provided with a specific RDBMS. Oracle Applications, which is a popular ERP package, requires an Oracle database. Likewise, PL/SQL is very popular, but only available for Oracle. Add in all the other niceities that Oracle ships with 8i, and you can see why the entire package is pretty impressive.

    So, in the majority of situation a smaller opensource RDBMS like postgreSQL or mSQL will probably work just fine.

    If you are n enterprise customer which needs extreme scalability and performace, You would be hard pressed to go with anything other than Oracle or IBM.

  13. ACID properties by isomeme · · Score: 5
    The real distinguishing characteristic of a high-quality database is rigid compliance to the "ACID properites" -- Atomicity, Consistency, Isolation, and Durability. Put very briefly, "atomicity" means that transactions either completely succeed or completely fail, with no partial changes possible; "consistency" means that rules concerning how data relates can be enforced by the db engine; "isolation" means that the db state visible to one transaction in process won't be changed by other parallel transactions; and "durability" means that changes won't disappear once they are completed successfully.

    This all sounds simple enough, but producing a db that actually implements the ACID properties reliably is very, very hard. So hard that people tend to charge tens of thousands of dollars for the result.

    Of course, in many circumstances you don't actually need a fully ACID-compliant db. In general, if your transactions don't involve strangers' money, and if data can be cross-checked and reacquired from external sources in the event of a problem, you can get by with a cheaper, non-ACID db server. But using a non-ACID db where you really need ACID-level reliability is asking for big-time trouble.

    --

    --
    When all you have is a hammer, everything looks like a skull.
  14. Depends on what you want to do by Elias+Israel · · Score: 5
    High-end DBMS products provide lots of features that can make coding your web site a bit more cumbersome, but maintaining it much easier.

    In particular, built-in enforcement of data constraints, triggers on data modification, and stored procedures are HUGE wins for many web sites. Using these correctly can move tremendous amounts of complication out of your PHP or ASP code and into the database where they can be more easily tracked and managed.

    The lack of transactions in MySQL is often commented upon, and its very important. A complex set of related changes can fail in the middle for many reasons, leaving your data in an unknown or even a completely corrupted state.

    Is it worth all of that to pay Oracle's fees? For a commercial web site, where dollars are at stake for every bit of downtime or lost data, then the answer is absolutely yes.

    If, on the other hand, you're working on something that uses the database as structured storage rather than a full-fledged DBMS, and especially if you don't mind babysitting it from time to time, the cheap or free options are probably OK.

  15. Web sites != large amounts of critical data by NineNine · · Score: 5

    Anyone who has ever been a DB developer (such as myself) or a DBA knows tha thte vast majority of enterprise-class databases (Oracle, DB2) are NOT used for web sites. Web sites are cute, but rarely are they mission critical, and rarely do they hold vast amounts of information. Think large systems. Cam you imagine, say, Visa or Matercard running MySQL to handle thousands of transactions a second? Or how about truly large databases? I recently set up North Carolina's Mediare system on Oracle. That started out as a 3 TB database, and will grow steadily for the forseeable future. Has MySQL ever been tested against something of that size? Even the largest web sites do NOT generally compare to other entreprise-class projects, in either size, ort he critcality of data.