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?
You pay for PERFORMANCE, STABILITY, FEATURES...
MySQL, Msql, Sybase, MS Access and other similar
low end DBMS's can handle no more than 1M records
and 50 hits/second. Also you must shutdown your
database for hours each day to backup your data
so you can recover from the inevitable crashes.
Oracle and MS SQL Server can do a little better
and handle 100-300 hits per second, 100M records,
and run 24/7 with online backups.
If you want to handle really large databases you
need to use a system that was designed from the
start to handle huge databases, billions of records
and thousands of concurrent transactions.
The fastest database by a factor of 10 is a little
known system called Model204. A single system with
a single Model204 can handle:
30000 logged in users
5000 concurrent transactions
5000 transactions/second
2500 active databases/system
10000TB of data
4 Billion records/database
350 Million Hits/day
ORACLE database tables can be accessed by SQL commands which are embedded in standard programming language programs.
Definitely not unique. PostgreSQL, for example, has hooks in Tcl, Perl, Python, C, C++.
They aren't talking about programming hooks. They are talking about Pro* (Pro*C/C++, Pro*COBOL, Pro*Fortran) which allows you to directly embed SQL into an application without hooks. You basically run a precompiler over your code which validates the SQL itself, allows runtime diagnostics at the client level, clean type conversion, etc. Personally I prefer OCI, but that's just me.
Features which I believe Oracle has most of the open source competition beat in is clustering (run oracle on x machines and have it load balance), parallelization of queries across CPUs in your cluster (very nice for long running queries), resource management (you can allocate x bytes for y task if you want), the ability to index based on function (index upper(col) for instance) and runtime configuration & status (the v$ tables are scary they are so complete).
Now, Oracle has several drawbacks. sqlplus has no readline support (quite annoying). Certain types of simple queries are not optimized (select count(*) sucks). The OCI libraries are big and there is no small client-only installation (we built our own tiny library-only install).
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
First off, MS Access is not a true multi-user database as anybody who has tried to use it as such as probably discovered. It also has mega-trouble scaling about 1 GB. I'm not familiar with free software databases so I can't comment.
But what are the key selling points of Oracle?
1. Highly scalable architecture. Terabytes of disk, hundreds of transactions per second. Oracle can do it.
2. Clustering. Oracle Parallel Server provides true failover capability.
3. Replication. Another data distribution/failover/backup approach.
4. Tools.
5. Large # of apps designed to run with Oracle.
6. "Value added" add-ons such as Oracle Forms, the geospatial option, etc.
7. All out Java integration
8. Interfaces to most other databases, support for remote queries and dblinks.
9. Ability to back up database while it is run.
10. Very portable.
11. General lack of bogosities compared to the competition.
12. Market share --> confidence in them being there for the future.
13. Support.
The knocks on Oracle have always been its high price - try buying Oracle for even a basic Sun E-450. It can run upwards of $300,000 - and the relatively DBA intensive nature of it.
For anyone who plans to develop highly scalable systems, I highly recommend studying the Oracle architecture. It is a textbook on how to do large scale computing. And for those used to the traditional Unix client/server computing paradigm, it can be quite an eye-opener.
I know that money isn't everything, but...
Oracle admins cost a bundle for a *reason*. They are well trained, know their software inside and out and if you watched one work on an Oracle system, it's amazing (like watching a greybeard work on a VMS machine).
And to plug oracle even more, you're not at the mercy of the OS -- Get me a copy of MSSQL for Unix and we'll talk, but if the NT server goes down, and you can't take it anymore, you have all sorts of other OS's to slap oracle on. This is true for most other RDBMS's as well.
However, it should really be noted that 90% of 'relational databases' are so unrelated it's really sick. We have actual relations at our work, and it all runs on MySQL, which is a pile of crap, IMHO.
No subselects, transactions, real locking. About the only thing that mysql does well is serialization and select statements, both of which I could do with flat file databases and a perl script, and probably get decent -enough- performance to be usable in an environment that uses mysql.
To put it simply, if you know what you're doing and have any experience with this stuff, go oracle or perhaps PostgreSQL, as the 7.x series is probably the best free database that you can get your hands on right now.
Stay FAR AWAY from Informix. I yet to see a slower RDBMS... Granted, it's stable... And if you work on lucent switches, you're probably going to have to deal with it anyways.
If you just need to store crap to belch out later on a webpage, sure, use mysql.
I broke Oracle8i on Solaris 7 (patched) and Veritas LVM 3.0.x this past summer on a Netra t1405. I can dig up the script that provoked it, maybe, if I'm lucky. I still trust Oracle pretty well, though. It may have been a Solaris issue, but that would surprise me. I've only heard of one other coredump with Oracle 8.x.x on a primary development platform (Solaris and maybe HP-UX?).
I didn't actually break Informix; one of my friends working as a DBA for Cornell broke that in production, was corroborated, and that's good enough for me. That was on AIX. (Are they still in business? Their webpage is up but that's not really a perfect indicator of solvency.)
Sybase was on Linux. I'll admit, I cheated a bit there. I'd be happy to try and break DB2 UDB on something like an S/390 G6 but I don't have one of those lying around...
Remember that what's inside of you doesn't matter because nobody can see it.
The EMC was a red herring, after a fashion. It's more for the purpose of "see this pile of money? that pays for the DISKS to run a real OLTP DB.".
I mean, this is Slashdot, not a technical forum.
I'd rather spec a Sun StorEdge/T3 array (for Oracle) or IBM's competitor to it (for DB2 UDB, presumably running on AIX) for performance, since EMCs are legendary for being butt slow once you blow through the cache. There was an article on adaptive caching RAID arrays in Oracle Internals awhile ago; someone built a hardware solution...
The Cheetahs now come in an X15 (15000 RPM) model, if you're rolling your own storage (ittybitty Oracle setups, PostgreSQL, or MySQL).
They're pretty nice IMHO, I have a few of them in RAID 1+0 here. Snappy. It's also nice to rack them in a 4U so you have room to put two Adaptec UW-160 cards in there and keep each side of your mirrors on a separate channel. 72GB mirrored at 15000 RPM... yeah, it beats up the EMC "solution" for that scale of a project. Obviously I'd start reaching for Sun Storedge JBODs after that.
But yeah, you're right, that was a spurious point.
Remember that what's inside of you doesn't matter because nobody can see it.
Oracle is definitely more scalable, etc, but I'd like to attack it from the standpoint of a developer:
:) Sure, the above query can be done in mysql, but it would take me more time to write, and possibly mean splitting it up in to two queries. I can't use mysql now that I've gone to oracle.
There are some big performance features (statement caching, stored procedures, materialized views, etc) that definitely help with large web sites, and there are others that help me get my work done, like subqueries. I haven't used MySQL in about 6 months, and up until then there was no such thing as a subquery, which can be handy at times. Take the following query:
SELECT
a.message_id,
a.message_text,
b.message_count
FROM
messages a,
(select message_id, count(*) from message_hits group by message_id) b
WHERE
a.message_id = b.message_id (+)
Oh, and that reminds me- outer joins too.
I also have been tinkering with PostgreSQL since it was Postgres95, and I couldn't agree more. If you haven't checked out PostgreSQL for a while you owe it to yourself to download the newest 7.1 betas and try it out. PostgreSQL has gotten a lot faster. In fact, unless your application is extremely select heavy PostgreSQL will almost certainly give MySQL a run for it's money.
It also has a great many of the nifty features that make the commercial databases so expensive, and the mailing lists are amazingly helpful. It certainly doesn't hurt to give it a try.
Oracle is an SQL database....
For every problem, there is at least one solution that is simple, neat, and wrong.
HAHAHAHAHAHAHAHAHAHA
Based on ten-year-old Sybase is more like it.
Sybase and Microsoft parted ways at SQL Server 4. There has been a lot of programming water under the bridge since then.
Reliability and scalability.
It is pointless to even compare something like Access or MySQL to something like Oracle or DB2. If you are even asking this question, it means that the above two words are foreign to you.
___
___
If you think big enough, you'll never have to do it.
If you read the fine print you'll notice
a) they get 30 days to tune your server
b) after those 30 days, you have to pay for the time they took to tune your server. At Oracle consulting rates, that's a _lot_ of money
So, they're actually trying to jip you.
Engineering and the Ultimate
Interestingly, SAP is releasing their DB backend under the GPL.
Engineering and the Ultimate
Also (at least to me) is replication. AFAIK, there is no compare on PostgreSQL. Dunno about Interbase/Sybase.
Although, I discover that my needs (web backends) are met without using Oracle's bells-and-whistles -- which is why I'll never be a real DBA, just an amateur forever. While I suppose ANY application can be optimized by utilizing Oracle arcana, time-to-market keeps me from dabbling.
But, replication is seriously cool, even for simple web stuff. I like being able to know that my dev DB actually reflects current state (or vice versa, tho that scenario turns my guts to water.. :)
Potato chips are a by-yourself food.
This is not unique to Oracle, but I suppose the argument could be made that Oracle is the leader in this.
This covers mostly the completeness of an Oracle solution.
True.
Not as unique in these days of ODBC. The quality of the middleware tends to be higher with Oracle solutions, however.
Definitely not unique. PostgreSQL, for example, has hooks in Tcl, Perl, Python, C, C++.
I'm not an expert here. I have no experience with I18N solutions in Oracle, but knowing what I do about Oracle as a technology and as a company, I can confidently say that Oracle has best-of-breed solutions in this area.
But, PostgreSQL, with it's world-wide development model, is probably not as far behind as you might think.
No experience here, either. I know that Oracle's embedded Java is highly regarded, but haven't had much of a reason to delve into it (plus, my Java programming is pretty poor)
This has the ring of untruth -- an application that talks to Oracle on Windows most certainly isn't portable to Unix or MacOS. Perhaps the SQL calls and triggers are portable? That doesn't make sense, either, as SQL is supposed to be portable, and triggers are internal to Oracle.
I don't credit Oracle with this anymore than I credit Internet Explorer for rendering <I> tags as italics. Oracle follows E.F. Codd's RDB spec, and as such it allows for multiple users (which, really, is as much a part of it being Unix based as anything else).
This is not unique to Oracle, but is executed well within the environment.
This is a function of an ACID compliant RDBMS, specifically, the "D" of ACID, Durability. Your data should not be vulnerable to some yahoo tripping over the power cord. However, in practice, this is more dependant on the skill and talent of the DBA than the heroics of the RDBMS (i.e. spec-ing mirrored arrays, good backup policy, sane rollback partitions, and proper disk management (rollbacks on separate disk from data, etc.))
Potato chips are a by-yourself food.
I agree that each database product doesn't directly compete. MySQL != Oracle. It all highly depends on what you want to do.
/. where loss of data isn't a concern, but speed is.
MySQL is great for sites like
Postgress is great for those who want a low cost solution for a small RDBMS.
M$ Access is cute for visually seeing the relations, but pretty much a joke for anything serious.
SQL Server / Sybase these two are essentially the same, they were the same product a few versions ago. M$ added some neat features to it, and Sybase seems to be struggling to add useful and needed features. (Like hot backups (where you can take a snapshot of the database devices), load balancing, easier management of replication, major scalability and failover.) Sybase is working on it, but Oracle and DB2 are way ahead these two products by quite a bit. SQL Server is also hampered by only running on intel hardware. Sybase at least runs on quite a few different platforms.
Oracle the kingpin of the RDBMS areana. Pretty much has all of the features, and a huge licensing fee.
DB2 everything that I've read has rated DB2 quite high, it seems to be the database that people use but no one seems to know about.
Pretty much it's all that you're wanting to do with the database, and how much $ you have to determine which database you use. But keep in mind if you write everything you can in ANSI SQL, it should be fairly portable between database vendors. Unfortunatley I've seen cases where writing something with Transact-SQL (Sybase / M$) or PL/SQL (Oracle) is needed. But supposedly both are going to have (or already have) native java support so you can just create a query in java rather than SQL. I don't know much about that other than it's supposed to exist or comming soon, and I'm not a java programmer, so I can't say for certain.
"If you insist on using Windoze you're on your own."
I think there are really three broad categories of issues.
First of all, how important is your data? High end RDBMS systems offer a lot of administrative features that make backing up your data easier and less intrusive. To take an extreme example, Access is notorious for losing data. Everything is stored in a giant blob file, and when that gets corrupt, you can loose everything.
Second of all, how much load do you need to support? Oracle has been running very heavily loaded DB servers for a long time; it's the safe choice. SQL Server is getting better, and MS claims that it will scale indefinitely, but it's probably trickier to run under high loads than Oracle on Solaris.
Finally, what kinds of programming are you going to need to do? Will you have feeds of data moving in and out of the system? Lots of triggers? Integrity checks? How much procedural language programming are you going to have to do, and how closely will you need to integrate the DB into existing systems?
You shouldn't use Access for anything serious. It's a bad system that can't handle loads, and that tends to corrupt and lose data. Think of Access as a 2nd rate front end, and stay away from its back end at all costs.
MySQL is fast, and it's great for simple web applications, but it doesn't support big chunks of important SQL functionality and it doesn't have professional admin tools that you need to protect your data.
MS-SQL is kind of expensive for web applications, unless you're comparing it to Oracle. And I think the development tools are weak when compared to Oracle. But it's easy to admin, it's rock solid, and it has a really respectable features set across the board. MS seems to be intent on closing the features gap with Oracle. Some big companies use SQL Server to store financial data -- it's a reliable platform.
Admining Oracle was hard for me to learn. Setting Oracle up on Linux was painful as well, for me at least. I don't know it well, and I've only played with it, never done anything serious with it, so I'm not a good Oracle reference. But it strikes me as big and complicated and able to do absolutely everything that you'll need. You probably won't outgrow it.
If you're going to run a message board on a web site, then use MySQL and PHP. But if you have data you have to protect, and you need to keep an offsite server that's constantly synced with your main server for safety, you really have to go with something like MS-SQL or Oracle.
Heheh, that's right... you probably won't be able to sue them or anything, but you can sure take out a lot of frustration on some poor minimum-wage phone-monkey's eardrum. That's worth at least 30 grand right there.
I do not find in orthodox Christianity one redeeming feature.
You must be talking about the Oracle Applications suite (which is at version 11i now), not the Oracle RDBMS and tools, which are at version 8i.
The article was asking about the RDBMS, not the Apps.
Oracle runs on many platforms. What platform does Oracle run best on?
A: A 35mm slide projector.
(I guess you would have to sit through an Oracle marketing presentation to understand.)
If tits were wings it'd be flying around.
Just like that old phrase says, noone ever got fired for buying Microsoft. The same goes for Oracle.
Please don't rewrite the history.
The correct phrase is "Nobody ever got fired for buying IBM."
FedEx has successful systems using HP/UX and even AIX, but you're right in that if you give the DBAs their druthers, they'll say "Solaris".
And so will all us SAs.
-
For small to medium sized installations of a couple of hundred users Interbase 6 makes a perfectly fine server. It has all the checklist items (transactions, triggers, stored procs, solid SQL support), is a robust, debugged application, and is now completely free. It stores each database with all the users, groups, stored procs etc in a single file, which makes backup and transfer a snap. Newsgroup support is also good, and will probably only get better with time. The management GUI is no Enterprise Manager, but that's a small price to pay for what you get. In certain market segments Interbase could eat MSSQL for lunch if it were marketed half-way decently.
-
Are more than phone drones
- Trust your evaluation of the problem is really exposure of a bug and don't call it user error
- Have ready access to developers and source code and can provide patches/fixes in a quick time period
If any of the above elements are missing -- phone drones who have to run you ragged before escalating to someone with a pulse, fingerpointing about software/hardware "user error", no developer/source access -- you are fucked, and you might as well be posting on Ask Slashdot, since you'll probably get a worthwhile answer there faster than from support. In fact, I know people who will pay consultants when they have problems because the consultancies usually have better contacts and can get beyond level 2 support faster than Joe Support Contract could ever hope to.I don't mean to be knitpicky, but the quote was "nobody ever got fired for buying IBM."
In what world is IBM NOT a mover and a shaker today?
If you want an enterprise system, IBM is a great place to go. They have good enough stuff in enough areas, and enough people to throw at any problems that need to be solved.
If you're talking PCs, then IBM doesn't matter, which is kinda ironic. But there's no money in PCs (besides a few companies). In Enterprise computing, it's still raining moolah.
-jon
Remember Amalek.
Yes, I have used WebSphere quite a bit. And I agree; it's shite. It was chosen before I was hired due to its integration with VisualAge. Now, none of our programmers are using VisualAge (JBuilder and NetBeans have pretty much won) and I've tried to push my company into looking at other app servers. The fact that it's possible is a testament to how spiffy J2EE is.
I didn't say that IBM products fall into the "best of breed" category. The thing is that WebSphere (like many IBM products and services) is good _enough_. IBM is so big that for enterprise customers, the IBM good enough products combined with IBM's good enough service are good enough to seal the deal.
To the dismay of geeks worldwide, mediocrity usually wins the day. And a giant mediocre company is a mover and shaker by any measure.
-jon
Remember Amalek.
Since you recommended Interbase, have you used both the commercial and open source versions? Now that Interbase is open sourced, is Borland still continuing develop?
I've also heard that there is an Interbase code fork called Firebird. Do you know anything about Firebird?
thanks!
cpeterso
If you have a task that you know you can do with the necessary reliability with MS SQLServer and Access, or mysql, or whatever other low-end database you want... then you don't need oracale. If you have such a task, you also are not a bank doing transaction processing, and you are not doing any truly mission-critical tasks.
Oracle can cost a lot more than the 50 thousand bucks you mention... a lot more. Oracle is extremely scalable, and extermely stable. Oracle offers 24x7x365 support and backs their product 100% (for a fee, of course).
To put it differently, if you were aware of a situation that actually used oracle for good reasons, you probably wouldn't have asked the question in the first place.
Scope: Oracle provides business and enterprise solutions from ground zero to the never ending support and uprgade cycle
Support: You can't really have better support then some of the talent working support. Sure the first person you get in touch with may not have any clue what you are talking about, but the support infrastructure is there and works great! Just create your Itars and TAR's according to the guidelines and recommendations of support and they will fix your issues
Solution: This is the biggy. For example, with Oracle 9i AS you have an incredible applications server that cannot be beat! Built on Apache, Oracle 8.1.7, and Portal 3.0 with Forms and Reports 6i. You can build your own portals running Apache, PHP3, MySQL, and Zope and a conglomerate of modperl and such, but with 9i AS you have a foundation already built that you plugin saving hundreds of millions of dollars in development.
API's & Developer Support: Oracle does provide alot of its technology stack, open API's and such to developers. You buy Oracle Applications 11i and you can integrate that and customize to your hearts content. Most companies wouldn't imagine providing tools like that and supporting it at the same time
Proven Technology: You use oracle software, and your database WILL work, simple as that. Need custom software and you don't want to develop it, oracle will, need an application to solve your business needs, oracle has it.
Open source is great, but commercial software that supports and open environment is just as superb in my opinion. You buy Oracle and you can run it on any architecture available today. You can use the skills and technologies already tried and true in your business to leverage oracle software to increase whatever capacity and concepts your trying to achieve.
Really? This doesn't fit with what I've seen. In my experience, disk read/write performance falls off about the same from first to last sector, on all products in a line. Regardless of the number of platters in the drive.
The fastest drives come out in small sizes first, but that's more of a sales and simplicity of manufacturing I'm sure than anything else. Toss more platters in it and you simply spread the performance curve over a much large data space.
As a reply to the post below this...
It's not as much "See this, it's *real* hardware which you require to run Oracle." as "You don't really need Oracle (or DB2, etc) unless you also need this kind of hardware - if you're playing with x86-level hardware, you don't need the high-end software."
This is where a DBA comes in. They'll know enough about how the data is stored (that stuff nobody is supposed to need to know) that they can tell if page level locking is sufficient. In most cases, I agree, it would be. If you're writing to phone records stored (for instance) in name order, page locking is okay for random access patterns. You'll get a block or two, but who cares in the long run. But if it was St. Patrick's day and you got a a run of calls from names starting with Mc, you'd be in trouble.
This is why keys are often assigned with things like MD5, an even distribution random appearing hash will prevent too many concurrent accesses from blocking.
Then you simply index by everything you want to look up. As long as the table doesn't block, who cares what order it's in.
But a skilled DBA will give you an answer that's related to the actual product you use, not just general comp-sci answers.
I think the key point here is heterogeneity: Oracle wants customer's money, that's obvious, but they do accept that they will have to work with other company's products. Microsoft do not accept that, and always seek to disable (or make suboptimal in some pernicious way) solutions involving other people's technologies.
To take an example: Oracle Designer, a product I used to be involved with, supports multiple database platforms for input and output of database schemas. Granted that the backend database for Designer must be Oracle, but the point is that Oracle as a corporate entity understands the point of interoperability.
Further, Oracle has made an effort to contribute to standards: UML is the one I know most about, but SQL is another obvious candidate. Microsoft's contributions to such standardisation efforts can be characterised as being half-hearted at best, deliberately disruptive at worst.
In other words, Oracle is a different kind of animal to Microsoft - dangerous to competitors yes, but not an all-consuming monster.
--
Dunx
Dunx
Converting caffeine into code since 1982
Oracle says they saved a billion dollars by using their own software.
Of course, they got it for free.....
The best summary of this is that "The Database IS the Business". It all depends on how much the integrity of the database is worth to you. It also depends on how well you want to scale up the business. And I'm not *just* talking about the database, but the level of support, and the personel who are trained and *qualified* to manage your data.
It's kind of funny to say it this way, but I'd have to wonder what the correlation is between successful businesses, and commercial databases.
At the big business side, an open source database isn't even a consideration. Its at the low-end of the scale that it is. And the single driver for going with an open source database doesn't *seem* to be reliability, cost, or 'openness'. (Do you want your people modifying how the database's internal code works?) Its about dollars. Businesses with dollars will (with rare exceptions) choose a commercial and well-trusted database.
Having a person to answer the fone and write down your question 24x7x365 is only 1% of the job. We've broken Oracle numerous times and it's taken them weeks to get back to us with something to TRY, not even a guaranteed fix.
I think the biggest thing that Oracle really provides is tight row-level locking (Sybase only locks in 4k chunks to my knowledge) and better transactioning or whatever you wanna call it.
Speed too I guess.
You've never used a large RDBMS, have you?
Most RDBMS' do allow you to choose between speed and ACID/atomicity/etc. DB2 supports a boggling array of options, including a MySQL-style "store with no security whatsoever" option. The latest SQL spec even provides standard terminology for some of these features. Most of the big DBs provide more speed vs. reliability reatures than the spec requires.
--
Forward, retransmit, or republish anything I say here. Just don't misquote me.
Oracle is worth it based on what you are doing, I have used MySQL, PostgreSQL and Oracle. I maintain some Oracle DBS at work. MySQL will shine for a news site like slashdot, PostgreSQL would shine for ebay. Oracle on the other hand will shine for something more complex. My DBs handles 10's of millions of transactions a day, very complex transactions, with each DB being half a terabyte, it is no easy feat! MySQL and PostgreSQL will not be able to even handle a quarter of what I give to Oracle. Oracle is way way way advanced, you just don't know much about it that is why you think it is the same as the low end free DBs. Take a trip to a good computer bookstore, and take a look at Oracle books, try reading one on performance tuning and you will quickly realize how complex it is... Anyway, it all depends, on what you want to do and of course how much money you have, and amount of effort you are willing to put to get creative.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
I've used Oracle and Sybase extensively. Sybase does not suffer from most of Oracle's speed problems, but neither one supports such features. Nice to see DB2 does, but please don't make sweeping assumptions about my experience.
A more two-fisted approach might be to note that yes, big-ass commercial databases (Oracle) have tons of features that you really, really need sometimes. That being said, the vast majority of sites don't need it. Sometimes, the real database professionals pipe up and see things all from their perspective. Fact is, I can do something the size of /. without really encountering a strong need for real database normalization.
Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Expanding a vast wasteland since 1996.
Most databases have some sort of an executive that runs scheduled jobs. It would be trivial to implement something which fires off an email message or beeps somebody when a disk is using 90% of it's space. I really don't see why this is such a big deal.
War is necrophilia.
" I'm assuming that the statement "none of these databases can comete with Oracle head to head" applies to the open-source databases. I'd be most happy to put DB2 up against Oracle (and Oracle up against a wall. ;-)"
Yes I should have clarified that. DB/2 can scale from your laptop to your mainframe. It's very nice.
War is necrophilia.
It depends on your app.
Lots of writes postgres is faster then mysql.
Lots of selects with comples queries postgres is faster.
lots of selects with no joins mysql is faster.
War is necrophilia.
Check out interbase. Great GUI tools, great SP language, fast, stable, sql92 compliant and open source. It runs on windows and linux.
War is necrophilia.
Extemely stable as in a 74 pinto is extrememly stable compared to a 72 pinto.
War is necrophilia.
"But where do you draw the line?
"
Here..
If the program is expecting to use some resource it ought to check that the resource is available. This applies for anything. A program ought not to crash because some file it expected is missing and it ought not to crash because there is no more room on the drive. Seems simple to me.
War is necrophilia.
If you are running a DataBase containing a few meg (or even a few hundred) that can afford to come down for backups / maintenance (vacuming anyone?) then you will probably get no advantage from going to a more expensive commercial product.
Oracle (the DBMS I use most) lets you do funky things like online backups (backing up while your database is up & serving data), interesting index options, adding terabytes of disk while the system is up and running. All things that *most* people don't care about BUT are vital for 24/7 shops.
Of course, anything on an MS Windows platform has stability and security problems... but it's not only the platform that contributes to such things. If you're dealing with a database which tracks things that matter, then only a very robust database will do. Use Oracle if you can afford it, Postgres if you can't.
And if you don't have the skills, hire someone who does - it will be cheaper in the long run.
I'm old enough to remember when discussions on Slashdot were well informed.
Is there anything more to this than correct support of Unicode (+ maybe various other national charsets)? I'm having difficulty seeing what a Chinese user would want that an English user wouldn't, besides the ability to use Unicode/Big5/GB/etc..
*All* modern DBs support Unicode, from MS to MySQL to Postgres to Oracle to DB2. But even if one didn't, as long as it supported ISO 8859-1 you could just use UTF-8. Sure, you'd have to multiply your field lengths by 3 to be on the safe side (or 6 if your users want to write Egyptian Hieroglyphics or Klingon), but it would work.
perl -e 'fork||print for split//,"hahahaha"'
In my limited experience, MySQL is faster at doing simple things than any other database out there.
When you're programming a web-based app, where response times are critical, MySQL may actually be a better choice than Oracle, even if you do a hybrid solution, with MySQL used for quick lookups and Oracle doing the back end transactional heavy lifting.
Notice that the Oracle $1,000,000 speed guarantee only applies to DB2, WebLogic and MS SQL Server, NOT Mysql or Postgres.
But you can't. And that's why the big software.
I just came off of a large customer site where, the VP(IS) having received the personal assurances of Bill Gates, the customer spent two years replacing UNIX-hosted RDBMS with NT4-based SQLserver. Result? Transaction query times went from 2 seconds to over two minutes. The UNIX programmers are moved on, the VP is out of the computer industry entirely, and the customer is in deep kimchee.
One of the hardest lessons for apprentice (and journeymen) programmers/analyts to learn is scalability. Just because the single-user prototype worked doesn't mean that the design will scale up to support hundreds of simultaneous users.
One of the marks of the veteran is how fast s/he checks the specs for the marks of scalability. In the case of an RDBMS, if it doesn't have row-level locking with transaction commit/rollback, then it's a toy to be discarded immediately. This isn't because s/he wants to spend the company's money faster, it's because seeing one's software design fold in production like the Tacoma Narrows suspension bridge is a gut-wrenching experience. Those users are riding your design and if they are being hurt, it's your fault.
I won't say that MSQL, MySQL, or Access are inappropriate for all uses; that would be silly. Ad-hoc databases, LDAP, fine. But they cannot hold up in serious, major applications.
Look, you cannot work in the software world without ever dropping a bad design into production. But you can try to minimize the number of times you do so.
And you have a professional obligation to your customer and your users to do so.
I've used PostgreSQL since it was Postgres95 and each major version seems to get much faster, (as in the same query executes in 1/3 to 1/2 the time.) However, I know nothing about running real benchmarks on database systems, so I can't quantify anything. I can only report my impressions, and I think that PostgreSQL is plenty fast enough for use in just about everything you'd use MySQL for.
I'm known to be biased, so make of that what you will.
The problem with using larger drives in arrays, is that the performance will drop noticeably for the same size.
Okay... I'll do the stupid things first, then you shy people follow.
Okay... I'll do the stupid things first, then you shy people follow.
[Zappa]
I use open source (MySQL mainly) databases for about 95/100 projects for which I need database support. That last 5 projects, tho, are by far my largest, for which I use Oracle (and once SQL Server... no more).
The first thing you get with the big boys is customer service support, which is very important, but not unavailable with Open Source stuff.
More importantly, tho, you get third party support. Hardware, backup software, any additional software you may want, are almost certain to support the larger databases, and be efficient about it, too. You're probably relegated to ODBC or NO support for smaller database engines. That's very important for long term planning. Also, if your DBA gets hit by a 747, at the moment it's easier to find someone who knows Oracle than PostgreSQL. (At the moment... hopefully, this will change).
Lastly, the RDBMS supports lots of exotic hardware and OSes efficiently. The difference between Oracle's HP and Sun ports exploit a lot more of the efficiencies of those systems than does a port of MySQL, because Oracle can put a handful of OS specific gurus on the project for each port. Smaller RDBMS may support additional Operating Systems/Hardware, but I'd wager that they rarely exploit them to their full potential. Support, for example, of RAW I/O is available on several platforms from Oracle, while far fewer from other engines. Over time, these sorts of things become important; especially if you ever need to migrate machines, or if performance or large scale is important.
My recommendation would be to look at size, complexity, and lifetime. Larger, more complex (requiring more tuning/speed requirements), and projects with realistic lifetimes of 5 years or more should rely on the big guys. Single DBA projects on budjet machines that really might be replaced in the next few years as people change their minds about things can be made perfectly functional with free (Free?) RDBMS.
If I can take a little different angle than the other posts here, there's more to this than "my product features can beat up your product features".
A large company picking a strategic database may be making a decision that needs to last 10 or even 20 years. Companies that standardized on DB2, dBase, FoxPro, or other older databases many years ago have had to live with that decision. In many cases, they may think they made the right decision and it worked out for them, in others, they may have regretted the decision later, but once you go down a deployment road with a database or any software product, to a certain extent you're locked in.
So, when big companies buy Oracle, DB/2, Microsoft SQL server, Sybase, or any of the big companies, they aren't just buying a technical product, they are buying a certain level of trust in the company that they won't screw them (at least technically, they probably will get screwed financially many times (grin)); that the company will be around in 10 years to migrate the database to a new system; that support will be there when they need it; and that they will have someone's balls to squeeze if the going gets tough.
Open source databases are very, very cool for small web shops and many other applications, but it's not a good fit for the realistic business needs of large corporations. While there is the advantage of having the source code, so you know you can always enhance or change the product yourself, it will be a long time before a typical corporate IT shop is willing to take on that task. They already have their hands full with maintaining less-ambitious in-house applications.
As the comp.risks guys can tell you, there's a lot more to it than just the software.
- "When you want something with all your heart, the entire universe conspires to give it to you" -Paulo Coelho
I see their ads for a $1,000,000 guarantee that Oracle 8 will 3x be faster than your existing server.
The challenge is at Oracle's site here and it mentions only Microsoft SQL server 7.0 against Oracle 8i.
If Oracle was to open it up to other RDBMSes such as Sybase, Informix and DB2/UDB, they would be broke paying folks (including myself) the million dollar prize.
MS SQL server is limited by the hardware that it can run on, so it is at a severe disadvantage to other RDBMSes...
Oracle's challenge is nothing more than a marketing ploy, albeit a good one.
---
Interested in the Colorado Lottery?
Interested in the Colorado Lottery or Powerball games?
check out http://colotto.com
What OS do you use?
I've used Informix on SGI for 1 year, a 5TB transaction database. And currently Oracle 8i on Solaris, a 100GB datawarehouse full of stored procedures, triggers etc running extremely large (generated) SQL queries, some of the queries alone are 100kb text!!!
In the 3 years intensive working with these databases, I've never seen a single crash, and could not imagine one.
Could the coredumps you see have something to do with the operating system you are using? Such as the ever changing glibc on Linux, which will surely make some applications instable?
>anyway, I wouldn't recommend Access
>for that purpose anymore
Anymore? You mean you _ever_ would have?
james
Absit Invidia
Oracle can do many things that MySQL cannot do. A more reasonable contender against Oracle would be Interbase, which is also open-source, but even Interbase 6.x can be bought!! What you get is a license with some support. The danish banks use this and pay for Interbase 6.x clients.
What Oracle provides is a big framework with education, client development tools etc. The closest I can imagine to that on Interbase would be Borland Delphi, which only now is being released in a Linux version. But the support behind using Delphi and Interbase has no long history and is therefore a bad choice in the eyes of many CIOs.
Lars.
I see lots of comments like "you don't just pay for the database, you pay for the people behind it" etc.
What is that supposed to mean? Does that mean that if you have problems with your database, Oracle will dress up their best monkeys in suits and jet them to your office to charette until your problems are solved? Bzzzt, wrong. That' more money - either per incident, or per service contract.
Do you recieve uptime guarantees? Performance guarantees? "We won't muck up your accounting data" guarantees? Don't think so. Their licensing terms are so chock-a-block full of "we're not responsible, don't sue us if something goes wrong" legalese that I'd be surprised if they ever paid out a penny.
I'm not saying that guarantees of this sort make any sense. I just can't understand what people are talking about when they say Oracle stands behind their products. Only to the extent you pay them they do. Which is fine. But how is this any different than, say, contracting with Great Bridge to support your PostgreSQL installation (to pick an example)?
You get the name, pure and simple. Oh, and you get Larry some jet fuel so he can buzz San Jose in his $38 million Gulfstream V. Hey, it's your money.
I mean no disrespect to the excellent staff at Oracle. But as a consumer, you need to ask yourself what you're really paying for.
--Lawrence Lessig for Congress!
There are some features provided by the so-called "expensive" RDBMSs that current "inexpensive", "free" and "open" source database management systems do not provide.
Replication is a feature that allows databases to keep each other up-to-date. In some modes, replication can occur to allow offsite databases to stay synchronzied with a master. Other modes offer replication, often with only seconds of latency.
Being able to perform transaction log dumps and incremental backups are also a feature the "expensive" databases have and others do not. This is very important to ensure minimal data loss in the event of catastrophic hardware failure.
Clustering, to provide transparent, seamless recovery when hardware fails is also a facility that other database systems to not currently offer. This is important in installations that absolultely require 24/7 uptime.
Some "expensive" SQL databases are becoming particularly good at caching data, query plans and even result sets, so that it need not invest large amounts of resources in oft-used queries.
Some expensive engines are capable of analyzing past queries to determine what indexes and stored procedures should be created to optimize efficiency.
High-end databases have been focusing on providing more than just a tabular view of the data. Many are providing complex text-based searching capabilities, which requires a far-different indexing scheme than what is used in traditional SQL databases.
On other fronts, expensive and inexpensive databases seem to do similarly well, and the inexpensive ones are getting more sophisticated with each release. One in particular that has been making such strives is PostgreSQL.
PostgreSQL still has some quirks, though. One in particular is the need in many situations to "vacuum" the database. Hopefully in a future release such garbage collection and optimization management will be transparent to the user.
My car gets 40 rods to the hogshead, and that's the way I likes it!
The fact is that there are a lot of RDBMS Solutions out there that are a lot less costly than Oracle and offer the real power of an RDBMS. Solutions like SQL Server are far less expensive.
What are the magical features that make RDBMS so powerful? Well things like Stored Procedures to control the input and output of data, Views to control access, powerful Optimizers to make queries more efficiently, Replication to protect critical information from hardware failure, and Transactions to keep atomic operations together. Without these featues we are back to the old days of dBase and storing data in files. It offers no way to plan or tune those operations and no way to protect the data from being used improperly.
While mySQL is fine for simple data storage and retrieval needs it gets out of it's league real fast when you start thinking about a mission critical application running in a high volume environment.
Is there a role for mySQL? Yes! Smaller, simpler sites that don't need to deal with complex transactions or large volumes of access. Is there a role for commercial grade RDBMS? YES! I'll bet you have bought at least one item on the internet through an Oracle or SQL Server DB and you would have been mighty upset if it had failed, or double billed you, or didn't ship you the product.
We have learned a lot from all those years of MainFrame and Client/Server development. Protect you data, keep it safe, use it wisely. You can access it with all kinds of tools from Web Sites to Fat Clients, but never compromise on the integrity of that precious resource!
$30,000 will seem like small potatoes if you orders DB was trashed and there is no fail-over.
9. Performance - simple databases are fast with simple queries, but sophisticated databases are fast with complex queries (and, maybe, slower with simple queries...). M$ uses simple benchmarks to tell their customers that they are fast (TCP-C), but most other vendors have stopped three years ago to post TCP-C benchmarks, so M$ is able to beat three year old databases on three year old hardware... TCP-D is more complex, and M$ couldn't show that their database wasn't 100 (one hundred) times slower on a specific TCP-D part than Oracle - though they tried hard. But benchmarking is a complex matter...
Are you trolling or astroturfing for Oracle?
Go visit the TPC website. Funny how they don't mention the "all important" TPC-D benchmark on their front page. The TPC-D benchmark is listed under the obsolete section under "benchmarks".
Now go visit the TPC-C results page.. The last posted results by Oracle are from January the 18th 2001. Doesn't quite sound like something they don't care about to me. (Although the results are listed as being posted by the hardware manufacturer, anyone who has worked with benchmarks knows it's impossible to post strong results without strong support from the database vendor).
Mmmm.. Donuts
Also, if they fail, you're still stuck with the bill for all the hardware they said you have to buy plus all the consulting they gave you. This can easily run to more than 1 million dollars. You get the $1,000,000 but you can't talk about it. We will never hear it when they fail the challenge!
Mmmm.. Donuts
It is *very* convenient to develop for, but something of a pain to maintain. (Depending on wether or not you know your stuff)
I'd say that SQL server works as well as DB2 and Oracle as long as you do not have extreme load.
Of course, again, you must know your stuff. Don't use all fancy wizards and widgets. Script everything and skip the GUI and you'll be fine...
All opinions are my own - until criticized
This topic has been addressed several times already on Slashdot but here it goes again. For 99% of the uses of a database today where data integrity is not of the utmost importance, the data sets being handled are relatively small, and the ability to scale to millions of hits a minute is unecessary, the simple RDBMS's like Access and MySQL can handle the job.
Oracle and DB2 are meant to primarily run on systems that will receive a lot of traffic (both reads and writes) and where data integrity is important (i.e. failure recovery, transactions, integrity checking, etc). Sites like eBay, Yahoo and Amazon are probably better off running Oracle and the like while smaller sites that have traffic that consists primarily of reads and where the integrity of data isn't extremely important can use MySQL or even Access.
Banks and Fortune 500s are also examples of companies that need the additional features of Enterprise database systems. Realistically for most people's needs Access or MySQL are all that is required.
Those are the technical requirements of building a very scalable DB-backed web application. The only two RDBMS systems that truly support these features, to the best of my knowledge, are Oracle and PostgreSQL.
At this point in time, Oracle is more scalable on *VERY* large systems, because it can be tuned more precisely when you have 22 mirrored disks and a 16-processor box. Also, Oracle is usually very stable (although the latest versions which come with a bloated VM and all sorts of additional crud have become significantly less stable than Oracle DBAs were used to).
For most people, though, PostgreSQL is a fantastic technical solution. It provides all the features in an easy-to-manage package with an extremely advanced architecture. Within a few months, it will support replication much more easily than Oracle does, and will continue to lead the way in SQL92 compliance.
Also, PostgreSQL and Oracle both have serious support options. In fact, PostgreSQL is supported by multiple companies, so you actually have a choice. If you're worried about the quality of support you'll receive from these new organizations, then you've clearly never dealt with Oracle's pathetic excuse for support.
There is a catch, though. Your job may be at stake if you use PostgreSQL. No one ever got fired for choosing Oracle. PostgreSQL will probably work better than Oracle at significantly less cost of administration with significantly better support. However, because it isn't nearly as well accepted in the IT community, you are taking a personal risk by choosing PostgreSQL. If Oracle fails, it's Oracle's fault. If PostgreSQL fails, it's going to be your fault for choosing a "non-standard" software product.
From a technical/usability standpoint, PostgreSQL is the way to go. If you consider the politics of your organization, though, and your organization isn't comfortable on the cutting edge, you may still have to go Oracle for a while.
I didn't see any mention in any of the responses yet of the obvious difference, which would be the inability of postgres or mysql to scale to a distributed environment, since neither support multiphase commit. This is the single feature that separates the high-end database solutions from everything else.
maru
Well, don't get me wrong, I love Postgres, but I doubt it could handle the transaction load of eBay. Further I doubt it could run on hardware robust enough to not instantly croak under the load (eBay's peripheral machines like webservers are all NT/2K (dumb IMHO), but the central database last I heard was pure oracle on solaris (and presumably one to several big Enterprise machines); I guess you could compile postgres on solaris, but would it be able to take advantage of the features of something like an E10K?).
--
News for geeks in Austin: www.geekaustin.org
News for Geeks in Austin, TX
For the love of all that is decent and holy, you get a code shop that can afford a decent Quality Assurance process. Linux the kernel is fine, but too many things ship as part of a system that are there because they compile with nothing worse than warnings.
Vintage computer games and RPG books available. Email me if you're interested.
GemStone/S is in version 5.1.4. I would hardly call it a "research idea." It is a high-stability, high-performance, and costly DB. Get over it, man.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Hmmm..., not *all* websites are small. Think about the Avis, American Airlines, or Best Western websites. Don't you think those sites are mission critical and hold vast amounts of data?
I agree with you, in that I don't feel ready to entrust one such system to mySQL.
But, although I'm still trying to muster up the courage (is that the correct way to use the verb "muster"?) to use mySQL for a large database, I have already taken a large step in getting rid of the large-database guys. I recently had to upgrade an Ingres database system. Rather than pay $30000 for an extra licence for the back-up computer, I got a fully redundant machine, with dual power supplies, 3+3 disks RAID, etc. I hope someday I will be macho enough to stick a finger to those guys at CA and use a free database...
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
If you build your database so that all your business rules are embodied in stored procedures & triggers, it makes it very to do things like write multiple front-ends (for example, a web-based interface for remote users, and a 4GL GUI app for local users). It also makes it much easier to maintain your system - if your business logic changes, you drop in a new stored procedure on the server and you're done. If that logic was in the client-side code you'd have to distribute a new client app to all your users.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
Although I'm just a mere home user, I've contacted various OSS developers on problems with the software they wrote and got the exact reply I needed to fix it. I've been in IT for 12 years and have dealt with the likes of IBM, Compuware and CA, and despite having problems with their software the answer varied from disinterest to slightly helpful. You need to be someone like Citibank before corps give a damn, whereas the OSS guys prefer their software to be working for as many people as possible.
Although DB2 on a mainframe absolutely creams Oracle on Unix, so is the only real option for large-volume batch processing. Rexx/DB2 is just as good if not better than PL/SQL and
DB2 has had stored procedures since v4, but I'm not sure what the other 2 are though, so maybe you could clarify.
I'm developing programs for financial institutions. Here are the advantages of commercial solutions over the free ones. That said, YMMV. 1. Support - you get support around the clock from the commercial vendors. This goes so far that, for Informix for example, the actual source code is handed every 8 hours to the next team that starts working (so the source code wanders around the world in 24 hours). 2. Transactions - yes, they will add transactions to MySQL in the future, but for now I go for safety. The database vendors have years of experience, and considering how complicate it is to do reliable transactions, I'll go with the experienced ones. 3. Scaleability - you get the commercial databases for nearly every platform that you can lay your hands on. If your database is too slow, you can always change your hardware (this is the major reason why I don't think that SQLServer from M$ is good solution for my needs). 4. Migration - with commercial vendors, you can always upgrade to the next version without pain (it killed Sybase nearly when they didn't do it right once). You can easily migrate to other platforms (but not necessarily to another RDBMS). 5. Standards - only the big databases confirm very rigid to standards (though they all try to lock you in by offering enough "nice goodies", and if you're dumb enough to take the offering, you're lost). For all major database vendors you get ODBC, JDBC, native drivers etc. 6. Interoperability - if you work with tools like ER/Win, development tools like Prolifics Panther or Power Builder, they are supported. Don't count too much on ODBC, its slow, and it does not support everything you need. 7. Multi-tier - if you need to support many , many users, you will have to use n-tier environments, and the transaction monitors (Tuxedo, JetNet etc.) will support only the major database vendors. And one day you'll wake up and need just that. And with the internet, this day will come earlier than you think. 8. Database replication, load balancing, fail-over and such things are, to my knowledge, only supported by big database vendors. It took them more than ten years to get this right (and M$ is still not able to do it right, though they claim the opposite). 9. Performance - simple databases are fast with simple queries, but sophisticated databases are fast with complex queries (and, maybe, slower with simple queries...). M$ uses simple benchmarks to tell their customers that they are fast (TCP-C), but most other vendors have stopped three years ago to post TCP-C benchmarks, so M$ is able to beat three year old databases on three year old hardware... TCP-D is more complex, and M$ couldn't show that their database wasn't 100 (one hundred) times slower on a specific TCP-D part than Oracle - though they tried hard. But benchmarking is a complex matter... 10. Added values - like Object-relational databases - are a speciality of Informix and Oracle. If you need this, there is not much choice. E. g. storing, retrieving and searching of word-documents (with indexing), is it possible with MySQL? No. 11. OLTP - in this area you have no choice but use a big vendor. If your database has to run 24x7, can you do a reliable backup on tape or anything? Can you restore parts of your database while the database is online? Reliable backup means: a transaction-safe backup which will make a snapshot of the database where every transaction is in its correct state, and a continously running backup. 12. If you ever need data mining etc.: look what databases are supported. 13. If you have a few TB to store, you can't use MySQL. It might be possible, but I doubt that this will be fast. Most simple databases don't scale with sheer size. I can only stress that reliability has its price. And there is more to reliability than just transactions.
You found a sword: +4 damage, +5 moderator points
I think the decision betwene mySQL v. Oracle or MS-Sql is the same as other opensource v. non-opensource decisions. Here are the eternal truths I see on the topic...
...
1) There's always a faction that will go with Opensource just because it's opensource. Usually the underlying reason is philosphical: "I don't want to sell out" or the like
2) There's always a faction that goes with commercial software because its commercial software. Usually the underlying reason is "it's not real software unless I pay money for it"
3) The majority of people make educated decisions between the two options on an individual case-by-case basis. Usually, these decision are based on answers to the following questions:
- do I need extra features?
- do I need support?
- what sort of software does my shop currently use?
- what sort of training is involved?
- what sort of specialzied hardware or software is needed?
- how much installation time is needed?
Then, it's been my experience that people's biases are factored in after answering these questions. For example, I would like commercial support, but I really don't like Microsoft. So I chose an open-source solution.
I think, as a general rule, commercial software is going to be more functional and backed by better support (with notable exceptions). But, if you don't need the support or you don't need the extra features, then why bother paying all of that money? I think a case-by-case decision is the best way to go.
GnuPS ia a new SourceForge project to develop a peer-to-peer parcel delivery service.
Parcels are carried in hub-and-spoke fashion by opensource developers commuting to and from work in major metropolitan cities. The service is open to anyone without any restrictions, except that all parcels delivered by GnuPS must be available for inspection by anyone.
Although delivery options, service time and reliability don't yet match that of commercial parcel delivery services, GnuPS is improving every day with suggstions from GnuPS users and new volunteers in the GnuPS delivery network.
GnuPS runs on Linux 2.4.2 + MySQL 3.23.33 + PHP 4.0.
GnuPS CentralOffice requires a minimum of a 486SX-50 PC's with 32 MB of memory, 400MB disk space, a CueCAT barcode wand, and an interface to GnuPS Drivers (via 10BaseT or a docking cradle).
GnuPS Driver requires a minimum of a Linux-capable handheld PC or laptop, 30MB of storage (disk or flash), and a CueCAT Decoder.
you are building a website. You might take a look at http://www.onlamp.com. Has some good info. Granted it leans towards MySQL but it does explain why so many websites use MySQL. Having said that if you need *really* big databases Oracle does rock hard.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
In life there are always extenuating circumstances. Unfortunately, bosses who want blood from a stone are quite common.
I bet when you called Oracle support, you didn't have a chip on your shoulder, some people do. Hell, I corupted a database once with a bad script. At first I thought it was a problem with the database, because I looked over the script and couldn't see where my mistake was therefore there was no mistake. When I called support, they were a little skeptical that it was a bug and instead wanted to see my script. They took one look at it and politely tore it apart. They told me how to fix the database, how to rewrite the script, and to call them if I had any problems. It was a humbling experience, because I was to blame for my mistake. Some people can never admit when they're wrong and support people have to deal with them daily.
I only hope that when you did screw up, your bosses didn't hang you out to dry. I've seen that happen many times before. A few words of advice, suck up as much knowledge and experience you can and find someone who is willing to pay you to be a real DBA.
BTW, Oracle support is the best support organization I've ever encountered, you really can count on them.
"The words of the prophets are written on the Slashdot walls."
The problem with your thinking however, is that no large scale application or even small scale for that matter can trap for all the things that can go wrong in an operating system.
The last thing I want is for Oracle or any other DB vendor to spend so much as fifteen minutes developing error handling to account for things any brain dead sysadmin should already be monitoring with at the very least a cron job. It is simply not their responsibility to check for every event under the sun.
"The words of the prophets are written on the Slashdot walls."
Technically no it isn't a relational database. According to Codd's definition of a relational database the software must meet a certain set of criteria.
- All information must be represented explicitly in one and only one way: as values in tables.
- Each and every datum in the database must be accessible by specifying a table name, a column name, and a primary key.
- Null Values must be treated systematically.
- At least one character-based language must be provided which can be used to modify the structure and contents of the database. This language must be able to do all of the following:
data definition
view definition
data manipulation
integrity constraints
- At least two integrity constraints need be supported:
No primary key can have a null value, and no primary key can be duplicated.
For every non-null foreign key there must exist a matching primary key.
Although non-relational tools are allowed, it must be possible to manage the database using only relational tools, and the non-relational tools must not be allowed to bypass the integrity constraints imposed by the relational tools.
The last I heard, MySQL did not support foreign keys natively and while referential integrity could be maintained through code, the database itself cannot insure RI.
However, I believe whole-heartedly that this omission is what makes MySQL so fast and ideally suited for the web.
"The words of the prophets are written on the Slashdot walls."
But where do you draw the line? While I'll admit that there are certain circumstances that should be checked for there does come a point where the application vendor must say, "This is the users/admins responsibility. Without that dividing line between application and user responsibility, then all applications will eventually become operating systems.
In the example the poster stated, those admins are clearly derelict in their duties. Every admin worth their weight in dung has some kind of monitoring in place for that kind of thing. Be it Tivoli, Shell scripts, Oracle Enterprise Manager, or even checking the space manually every so often would have clued them in ahead of time. And even if they somehow missed it, a competent Oracle DBA who stumbled across a hung database would immediately check for a log switch, missing file, or lack of free space. For DBA's this knowledge should be as second nature as breathing.
If John Doe goes out and buys a Porsche with a five speed manual transmission without even knowing how to drive a stick, is it the car's responsibility to tell him that he needs to push in the clutch when he comes to a stop? No it isn't, because there is a modicon of user responsibility that they know what they are getting themselves into.
"The words of the prophets are written on the Slashdot walls."
First of all, what is the DB supposed to do. Set off a klaxon horn? Call the hardware vendor and request another drive? or just start overwriting files at will?
I don't think you understand how Oracle works. One of the reasons people put such a premium on Oracle is because of its reliability and durability. Oracle (in an optimal configuration) will back up every transaction log it writes, if this back up does not complete and the database continues on its merry way then the DB will most likely not be recoverable if it should crash. As a result Oracle has a brake mechanism built in that if the database for whatever reason cannot backup the transaction log, switch log files, or write to a datafile it is going to stop in its tracks immediately, because at that specific moment the database is recoverable. If it continues it may not be. This is not only acceptable behavior for a DB it is desirable. Most people would rather have the DB come to a grinding halt and do absolutely nothing until the "skilled DBA" has time to correct the problem. And if that "skilled DBA" was doing their job, they got a page as soon as it happened, if not before. I personally would not want my DBMS do anything more than that, I'll happily leave the rest up to the monitoring scripts, Enterprise Manager Event handler, and the cron job running df every other hour.
"The words of the prophets are written on the Slashdot walls."
Well, I don't know about mySQL, but GreatBridge provides 24x7x365 support for PostgreSQL, which is also open source and said to be more scalable than mySQL.
1. Online backup. The database system that I manage needs to be up 24x7 and needs a 100% reliable parallel backup system Oracle, Informix, etc offer that. El-cheapo DBMS's do not.
2. Referential Integrity and Triggers.
3. Documentation. Commerical RDBMSs include accurate, up-to-date multi-volume documentation sets.
4. Storage management. If I stick data into my database. I know that it is there and accessible. How do I know this? My RDBMS spoke to the storage hardware directly. A glorified flat-file DB like MySQL does not give me the confidence.
5. Scalability/Flexibility. I don't know about Oracle, but Informix can scale from 1 to 64 CPU's over 1 to 128 servers.
Right now we run Sun Enterprise servers. If we decide to migrate to DYNIX, HP-UX, Windows 2k, Linux, etc we can without worry. You cannot do that with MySQL access or Postgre. (since you have to worry about incompatibilities between filesystems)
6. When we find a bug or have a serious problem, we talk to skilled engineers on the phone. No trolling newsgroups or modifying code by myself. I'm a DBA, I don't have the time or the desire to hack database code. We pay good money for support, but then again, the database makes us alot of money too.
If you suggested running Oracle or some other expensive RDBMS for a little website, I'd say you are crazy to pay that much. Same thing goes for a small inventory database or something similar.
At the same time, if you run a large multiuser financial, sales, or data warehouse application on a 'free' database you are far too reckless and incompetent to be a IT professional.
Conformity is the jailer of freedom and enemy of growth. -JFK
Uh, Oracle.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
mySQL doesn't do lots of things, like 2-stage commits, rollbacks, remote replication. Access is a horrible excuse for a "database" and shouldn't be considered for use by more than one user at a time, ever. Postgres and other open-source RDBMSs are closer to having the "full feature set" that the commercial vendors advertise, but are still a couple of generations behind the technology curve and can have some serious support issues if you don't want to grow your own internal database hackers (which most companies don't want to do).
Then you get into high-availablilty, massive data storage requirements, huge transaction-per-second rates, complex apps where you want to enforce rules in the database... these are the areas where the commercial databases compete with one another. Oracle, Informix, Sybase, and SQL Server are the big names we consider most when we start thinking about a project, although IBM keeps trying to make DB2 a competitor. For personal and small group use, heck, PHP and mySQL works great. For Amazon.com, it's a different story, and for the back-office types that crunch lots of data lots of times (insurance companies, etc.) mySQL doesn't even show up on the radar.
I love vegetarians - some of my favorite foods are vegetarians.
That being said, part of the support issue in that end of the market is design. You get an awful lot of adhoc awful designs. An example would be using a single name field. Not separate fields for first name, last name, title, etc. - but a single field for everything, entered any old which way. Great for mailing labels, useless for anything else. Stupid design, as as soon as you have thousands of records, and you want to find an individual person, etc. And then you have somone who calls up, and wants to sort this out automatically (HA HA HA!)
One call I recall was one person who wanted us to help him design his invoicing system. I asked him if he understood accounting. He said "No ..." I asked him if this was his first computer ... (you can figure out the rest.) Point being is that some of these things are complex, and they are not intuitive, and there is a market for some sort of solution.
Another part of the problem at that end of the market is the new owner of the business. A guy sets up his files with the old dos program, learns it pretty well, gets to be a wiz, grows the business well, and then decides to sell the business and go play golf or something. The new owners do not know dos, do not know database basics, do not know that design or that system, and might be simple users.
And now the madness begins, when they want to move it to a windows system, and do not know the windows version either.
The mom and pop shop are usually farming their work out as far as a database system goes, or they are band-aiding it with what they have been sold on as a solution, such as that intuition impaired product of the Very Important Software Company. Let's face it, that was designed for people who are programmers, and even then it can be a rather big hassle.
The best low end rdbms I have seen is the one put out by Alpha Software, at least for the Windows platform. Granted you still have to know something, but you can get something productive on it faster than anything else out there I know. They used to be a bit bigger, but then there was the power of Microsoft marketing.
There is a market for a good solution, but sadly, the dominant player is putting out something ordinary folks cannot use. You have to be a guru.
"It is a greater offense to steal men's labor, than their clothes"
Mission Critical does not always equate to vast though. Large and critical in these cases, but still not vast (only in comparison to something small... think multi-terrabyte databases)
---
Video meliora proboque deteriora sequor - Ovidius
Yes it is a demo system, but it runs real applications and a full support load (simulated customer service requests, live data warehousing, etc.). It was originally setup as a Telco ZLE, and operates continuously with a simulated load (90 days of up to 5 times the current number of phone calls made world wide). To quote from the website:
The benchmark implementation retains 100 billion Call-Data-Records (CDRs). At peak operation, it accepts up to 50,000 random transactional inserts per second through the CORBA-based application and handles more than 100,000 customer service agents performing more than 3,000 transactions per second in the TUXEDO environment. It also processes 100 customer profile updates per second, physical defragmentation of CDR tables, trickle feed to the data mart, and batch extracts to the mining cluster and the massive ad hoc parallel query.
I would be interested in hearing about other large databases (business, not scientific which tends to have a very different set of db requirements). I know it was quite tricky designing a database that can handle data of this size, and still deliver acceptable performance while mixing inserts, searches, and parallel queries.
as a programmer who has worked with mssql, I have to second that- MSSQL does not scale that well, and even worse, it has all sorts of nasty problems with memory leaks and very awkward allocation schemes. MSSQL will blindly cache 10GB result sets in 1GB of memory while waiting for the socket to catch up and send it all to the client- it will then refuse to give that memory back to the system, or even for other queries. For trivial implementations, MSSQL is a pleasure to work with, but it is a total bagbiter when you need it to do heavy duty stuff. I havent had any problems doing transactional stuff on mssql.
I think my company might have switched entirely to linux/oracle if it werent for oracle. Why do we use MSSQL instead of Oracle?
-cost: oracle costs a ton more. If anything, oracle is a worse leech that microsoft ever was.
-administration: oracle admins cost a lot more than mssql admins. The idiot console (enterprise manager) is easy for anyone to learn really quickly.
-administration: its a lot easier to hose an Oracle installation if you are a moron and dont think carefully before you do something. Did i mention that proper Oracle admins cost more? Hehehe.
I know that this is going to be flamed and marked down as a pro-microsoft troll, but it isnt. I hate microsoft as much as anyone else here. However, is Oracle really that different from microsoft? Hardly the lesser of too evils. I wish that postGreSQL or mySQL would get its shit together so that I could have a COMPLETE open enterprise setup. This would save on licensing and peace of mind.
I work in Support for an RDBMS vendor. And before I did that I was a DBA for several years.
24x7 support is never to provide bug fixes. It's to give you emergency help to get your system back up when it's down. The timeframes for most bug fixes are days if you're lucky. 24x7 means that there's someone at the end of the phone who has the experience and confidence to talk you through getting your system back.
9 times out of 10 it's not that difficult either because there are a limited number of options open to you. Usually you'll be restoring a back-up or undoing a configuration change that had unexpectedly disastrous results.
As a DBA the nice thing about that kind of support call was there was someone to share the heat. When the production systems crashed - as all systems do on occasion - there would probably be 3 or 4 managers standing behind my desk asking me when it was going to be back. It was great to be able to say "I'm on the phone to Support now"
As for the "user error" response - it does happen I'm afraid but let me say this. I get so many calls from people who are supposedly IT professionals who have no clue at all that it's real hard to stay un-cynical - but I try. But I also make sure that I get them to check the simple things first. Sometimes people hear that as patronizing or me blaming them but it's not - it's a troubleshooting procedure. I know for a fact that for every guy who's offended by me asking if any of the filesystems are 100% - there's two who haven't checked it. (And 5 others who just say no and we move on.) Believe me we'll quickly get to the non-trivial problems if that's what it is.
I'm not saying all support is wonderful but I know ours is pretty good. I'm not saying Open Source support is bad either. I do think just having the source is not enough though. You need someone with the time and skill to actually do something with that source - whether that's in-house or a 3rd party. Also most problems I encounter don't require bug-fixes - just knowledge of the DBMS configuration and commands.
I think looking at the quality of available support is an important factor in choosing an RDBMS. Availability is usually not a factor on a commercial RDBMS - but quality may be.
Having said that I think features is probably a bigger factor. From what I've seen so far the available Open Source offerings are still playing catch-up on features.
Not only DID we pay this ammount for the pentiumII install, but I used their web site to generate the other figure of the ppro180. Keep in mind this is for a web site and not a developers license. Thats how they getcha.
Sneakemail is to spam filters what an ounce of prevention is to a pound of cure.
That a very reasonable price and very un-oracle like. I've priced a 2x ppro180 and my company bought oracle for a client for a dual 400 pentium II, both for a public web server, and both prices were about $200,000-250,000 dollars. Those prices make any alternative look good.
Sneakemail is to spam filters what an ounce of prevention is to a pound of cure.
I think there really was once a real "peer-to-peer" public mail service started by someone back in the 70s or 80s. I seem to remember that he was killed and someone speculated that government agents or post office staff had killed him. I've lost the bookmark and can't find it in a search. Does anyone know anything about this?
--
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
One of the great things about Open Source/Free Stuff -- and I think one of its broadest appeals -- is that it's easy to learn how to use it and what it's about and what it can do w/o shelling out much other than some spare time.
I'd love to learn about Oracle and how it works. However, I think most certification classes are lame, and don't want to pay for them. I can't to it on the job because I can't seem to get a job as an Oracle admin until I know my stuff (fair enough). And I can't spend $10,000-$30,000 on an installation.
Is there any (legal) way to get a hold of the software and begin to play with it until I understand it?
--
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
MySQL also supports an annoyingly incomplete subset of the SQL spec and of our (and my) required features. I need transactions. Period. (Please, none of the "transactions [as well as unsupported feature X] are unnecessary" arguments that proliferate everytime the MySQL debate pops up on /.). I needed row locking when MySQL didn't support it. Period.
Today we run on Oracle on Sun servers. Oracle doesn't have alpha transaction support. Oracle on Sun servers doesn't have scalability problems. Oracle offers proven, out of the box failover support. Oracle brings a DBA with letters after his name who knows all the dirty little corners of Mr. Ellison's weathered and polished computer program.
But all the developers still run their development systems on MySQL, 'cuz the Oracle client sucks ass :)
I would recommend using what works for you and what conforms to your business. If the database is mission critical, then having the 24/7 Oracle support may be useful. Oracle also likes to tout how they are faster than the compeition, thus the whole 1 million dollar bet they have. However do not overlook MySQL, as it could be exactly what you need, plus the added advantage of it's cost. Negative being no formal support infrastructure(That I know of) along the lines that Oracle has. Prehaps try setting up a test server with MySQL and do some load tests on it that you believe you be fairly close to what your production server would be handling. Actually, the old phrase goes "No one ever got fired for buying IBM". IBM was around LONG before Microsoft.
Ignoring for a moment our opinions of MS the corporation, let's have a look at the capabilities of MS SQL Server. It actually trashes the capabilities of ORACLE on most points with one notable exception reliability. And that fails mostly of the platform it runs on. But, to its advantage, it has excellent failover.
And it's much cheaper to boot.
When you consider Microsoft don't throw the baby out with the bath water.
No need for evaluations and proof of concept trials. Just look at this site (/.) with all its hiccups and outages and you realise why you want to run Oracle. Oracle software powers the internet.
Your pizza just the way you ought to have it.
The issue is obviously multi-faceted. The poster doesn't mention what size dataset the actual DB will be used for. Are we talking about a departmental server, a back-end for a small web application, or a DB to track airline reservations? Once that is known, the issues become less cloudy. One wouldn't attempt to run an airline reservation system on MySQL but they might run in for a myriad of other applications.
The other issue is hardware. Most of the "Big Iron" machines don't run Linux or *BSD because the companies have developed their own OSes. Clustering may help here though.
Back to the main point, cost. The only issues are the return expected and support. If you are running on extremely slim margins in your business, and who isn't, and if your developers are skilled with MySQL, then by all means you should use it. On the other hand, if you expect the DBMS to pull in 6-7 figures a month in incremental revenue, then maybe you should use Oracle and get Tier 3 support.
Value based analysis will tell you which one to use. Using one over the other blindly is just foolish.
__________________ Hey Moderators!! Fuck Off! Thanks.
I can't really speak from experience, only from what I've heard from friends and co-workers, but there can be a benefit of publisher/developer support vs. 3rd party support.
If you have a problem that the support people can't figure out, there's always the possibility that they can contact one of the developers directly, thus getting results. (Either a patch or a workaround somehow) Now, I know that this same thing is possible with Open Source, but if the company doesn't have their own developers, then you have to wait for one of the developers to fix the problem. (If you [i.e. the company] can't fix it yourself, then you probably wouldn't be calling tech support])
It's nice to have things free, but sometimes you need things *now*. Of course, if the developing company doesn't do that sort of thing for you, then they're certianly not worth the extra money. (Unless they are much faster/more stable, which I doubt.)
"The circle of spice, lying on the ground... who put it there?"
Given you even mentioned the multiple thousands of dollars it actually takes to get into a real Oracle system I shall assume you or your organization can afford it. I do have to say this. My wife is one of those people who carries the cell phone 24/7/365 as an Oracle employee. And she is good, real good. And I can say that she does get called at 2:30 am and she works on the problem until it is fixed, and not one minute less. Nothing else is satisfactory with her management. So if you do buy that Oracle system and you're up hacking away at 3am and just cannot get something to work and you've got to have the quarterly results out by tomorrow afternoon, you'll probably be waking my wife up. And from what I've seen so far, your numbers will probably go out on time. Just don't ask me for help because I'm probably just going to roll over and moan. Plus I personally know nothing about Oracle.
Caution: Contents under pressure
I've read through a number of replies and people seem to be concentrating on the support contract and scalability. Quite right too - these things are important. However, it should also be noted that mySQL in particular, which most people are referring to as an open-source alternative, is feature incomplete. It does not support foreign keys, nor does it support stored procedures. It does not support correlated sub-queries. It does not support triggers. On the web page, The mySQL team argue that lack of foreign key support is an advantage. I simply cannot agree with this - working with declarative referential integrity can be more awkward, but as the name imples it is the best way of ensuring logical consistency throughout a database. mySQL has its place, and I -am- a user of it. I wouldn't swap out Oracle or Sybase however and, to be fair, the mySQL team don't really seem to expect me to. Cheers, Ian
This is a laughable question to anyone who knows these products. In certain situations, Access or MySQL will outperform Oracle, even when Oracle is running on a million-dollar E10000. There's no way that Oracle can match what is essentially a flat-file read in one of these little databases.
BUT THAT'S BECAUSE ORACLE IS DOING A LOT MORE WORK!!! WORK THAT SERIOUS ENTERPRISE USERS NEED!
I have used Access/MySQL extensively (and successfully) for many years, and I currently use Oracle. In these Oracle database, my company maintains medical records in several 250GB+ databases (almost 1000 tables each) that at any given time have hundreds of users.
We would gladly stop transferring zillions of dollars a year to Oracle Corp. (and enriching Larry Ellison, that horrendous asshole), if you can give us a matching small-database solution. Sadly, we would be lost without Oracle. You ask what the advantages of a high-end RDBMS are - well here it comes: Does Access or MySQL...
1) Have many different index types to facilitate different types of joins and database uses? (Star queries, bitmap indexes, etc...)
2) Have a serious security model that is extremely fine-grained and capable (and correspondingly annoying to work with, of course)? We work with medical information, and unlike almost every other company out there today, we guard it extremely tightly.
3) Have fine-grained locking? I know the MySQL guys are tired of being pounded on because their locking isn't row level (I do know that they are improving this). But it is important when you have hundreds of users. And just as important is analysis capability: when users get locked, Oracle can tell us (with a little bit of sweat) what exactly the problem was, so that we can maybe fix it.
4) Have a great cost-based optimizer? Is the optimizer flexible enough to respond to hints for those rare situations when the programmer knows better than the database?
5) Have full-featured replication?
6) Have support for numerous production support tools that can report on time-consuming SQL statements and also do things like rebuild huge indexes without taking the database down?
7) Are completely multithreaded so it can take advantage of multiple processors? (Yes - most databases are IO constrained, but when you have powerful disk subsystems like we do, IO can increase to the point where CPU can be a bottleneck.)
8) Can horizontally or vertically partition huge tables so that they are spread across many different disks? This vastly increases IO.
9) Have a flexible and intelligent constraint system that has enterprise-level features such as the ability to enforce constraints on new rows but let pre-existing rows violate the constraints. Sounds stupid - but when a table has tens of millions of rows, it might take weeks to write the program to fix bad data - but in the meantime at least you know that no new bad rows are being created.
I don't mean to slam the smaller databases. In 95% of systems, they are probably OK. But for us in the remaining 5%, our databases are everything to us, and we'll pay almost any price for integrity and performance.
Atomicity. Either everything in a transaction gets committed, or everything doesn't. You make sure that no matter what happens, with anything, if you shipped one widget, that inventory is updated accordingly, etc.
Consistency. The database goes instantly from one valid state to another. It never allows integrity constraints to be disobeyed. Never.
Isoluation. The database gets updated in a manner such that until a transaction is complete, no other query shall see any portion of the results of that transaction.
Durability. Once committed, the results of a transaction are permanent. If the database returns success, then 2 milliseconds later a hole in time and space sends one of the db hard drives to 5th century china, after inserting a new drive, the state will be exactly as it should be, with no information lost.
MySQL, for example, fails every single portion of the ACID test. Yet people will tell you to run your business on it because "it's really fast!" Of course it's fast, it's the db equivalent of a honda burning nitrous, with no way to turn the nitrous off. It'll be fast as hell, but you know it's only a matter of time until it blows up.
A lot of free databases lack basic capabilities such as sub-selects. This is where the value you're searching for is actually the result of another search. Yes, it's fully possible to write code which will do this in the client, but that's ludicrously inefficient if you're working with moderately sized datasets or larger. Instead of letting the db take care of that natively, you not only do the work yourself, in a non-standard hack, but you pass large amounts of unused data across a network stack, which uses resources.
I'm not saying all free databases are evil, they aren't. PostgreSQL is a very reasonable database which passes 'ACI' out of 'ACID'. That might be good enough for a lot of applications. Hell, flat files are good enough for a lot of applications.
The key here is to evaluate what you're doing. Before you look at the cost of the database, look at the cost of downtime, the cost of lost data, the costs associated with misreported data (caused by, for example, the database updating non-atomically), etc.
If the answer to the above cost reporting questions are all 'zero', including salaried time, then use MySQL. If not, consider using a real RDBMS.
Contrary to slashthink, businesses aren't completely stupid, they don't spend large amounts of money unless there's the benefit is expected to exceed the cost. There's a reason why most every business on the planet uses a real RDBMS.
--
"Don't trolls get tired?"
You see, when properly setup, most databases keep the information written across numerous drive arrays. If you follow, as an example, Oracle's recommendations on how to setup your hardware, you'll never have data which cannot be reconstructed after the loss of a single drive.
Yes, almost all software will let you do stupid things like use files instead of raw partitions, or to use hardware which allows unrecoverable failure. The question is whether such a system is "properly configured" according to vendor documentation. In the case of commercial DBMS, such as DB2 or Oracle, they aren't.
Personally, I'd be a little upset if somebody claimed a database passed the 'ACID' test, but had inserted a notoriously unreliable single point of failure (hard drive) into the system. Wouldn't you?
--
"Don't trolls get tired?"
That's the extreme case; in rather less extreme cases, a benefit of Paying The Bucks for Oracle is that you can do online backups while the system is running, and have the expectation that any DBA that is worth his (or her) salt can bring it back up if there is a problem.
Those are the critical things that cause managers to be willing to pay the Big Bucks for licenses.
The fact that there's a sizable community of DBAs from which to hire is a nice bonus; the process feeds on itself in that it is profitable for everyone (well, almost everyone...) to get involved in certification activities. That means that there's a half-reasonable lowest common denominator set of skills out there.
Another "merit" is that there is a whole pile of third party software out there, whether in tools to help you manage databases, tools to help you build DB schemas, applications running atop Oracle ( e.g. SAP R/3 ), and such, again, with financial benefits to many of those involved. It is SAP's interests to promote Oracle sales, and vice-versa... (Albeit that being an example of a situation where there are some conflicts of interest!)
If you're not part of the solution, you're part of the precipitate.
High-end RDBMs (Oracle, MS-SQL, DB2) are beasts of a whole different nature from your regular, run-of-the-mill MySQL or Posgress installation.
First they have a price tag attached. A very high-end price tag. The figure you give for Oracle is the barely minimum a company would expect to expend at the lowest entry-level.
Second, they all must be baby-sited. You do not install Oracle from a CD, make it run and leave it alone. No, you musrt first pain-stakingly install it, sweat and curse for a couple of hours to make it run and them administer it forever. Leave it in the hands of the users for a couple of weeks and the meaning of the word entropy will soon be known at the upper organization levels.
Allright, these above are a bit dramatic but true. In a sense, RDBMS makers and specialists are fighting hard to defend the last outpost of what Allan Kay once called "the high priesthoood of a low cult" (talking about the computer people of the 60's).
Now, high-end software is for high-end jobs. First, they have a bunch of weird performance marks to show at Transaction Processing Performace Council results for TPC-C, for instance. Carrefully note the kind of hardware they are talking about. They are measuring RDBMS performance in machines costing millions of dollars!!
And then these beasts are capable of performance peaks unheard of in the free packages. Not that I do not like MySQL. I like it a lot and have used it in many enterprise systems I developed. But those were small enterprise systems. They did not had to sustain high transaction periods, nor high connection counts, nor gigabyte sized database tables. And certanly not all three together.
I am currently working in the development of a system for a large laboratory. They process thousands of clinical exams per day, mostly in the morning. The organic material for the exams must usually be processed within two to four hours after it is collected from a patient. We will pay whatever it takes to have peace of mind. And I tell you, those will be some well expend millions of dollars.
One thing that is different between commercial and free solutions is support.
I know that Oracle can offer you 24x7x365 support options if you have enough cash.
Can mySQL do that? My experience with support on open-source solutions has been good, but not good enough to bet my business on getting a problem fixed in a few minutes instead of a few hours or days...
Still, sites that use these databases are still prone to problems, just look at EBay!
-Hunter
RateVegas.com - Vegas Reviews
With a commercial database, you pay for proven reliability, proven scalability, support, thorough documentation, and features.
MySql is not a database in the same sense that Oracle is. The four basic criteria that need to be met by any database are summarized by the ACID acronym (Atomicity, Consistency, Isolation, Durability). MySql satisfies none of them and lacks a huge number of very basic features. It is not a database, but a simple SQL parser on top of a DBM file.
The ACID test assures that the data will always remain in a consistent state, despite failures. Most enterprises (banks, businesses, etc) would pay any amount for this feature.
Postgres is a real database. However, it is still _very_ slow and scales poorly. The documentation for Postgres has glaring omissions, and the database lacks some features.
It is often worth paying for a commercial database. There is not a substantial difference between Oracle the "other" commerical databases (DB2, Informix, Sybase, etc). All of those databases are enterprise-class and offer features and performance similar to Oracle. Oracle charges 3-4x as much money because they are the market leader and market leaders always do that. Managers are extremely comfortable with market leaders, programmers are familiar with it, and DBAs are easy to find. That justifies the extra cost for most corporations.
It is strange that this "ask slashdot" column lumped MSSQL in with Postgres and MySql. MSSQL is not free, and an enterprise license is not cheap (>$20k if I recall). I have very little experience with MSSQL but it is generally not well regarded.
The most important thing is to keep things portable across databases. The biggest danger with the high end database is their vendor-specific extensions keep you locked in. Once you've gone Oracle and done all the Oracleish things, it's hard to undo that. I fell into that trap with Informix.
Start small and keep it portable. Chances are that a solution like PostgreSQL will work quite well. If for some reason you start hitting a wall, it should be easy to move up if you were careful.
And that's what it's all about. Stay flexible, because it's a dynamic world.
Scalability & stability. If you don't care about those, use one of the free offerings.
We will know databases are a commodity technology when the free offerings are as good or better than the commercial offerings. Right now that isn't the case.
--
--
E_NOSIG
More to the point, if you are willing to do the work
of maintaining consistancy yourself where it counts,
you can often not only do so, but your code benefits
from it hugely. Example: my application has a few
statements which must be atomic (everybody does this,
AFAIK, certainly PostgreSQL, MySQL, MS, Ora, etc).
Now, I have one piece of code that needs to execute
a complex batch of statements with consistency and
rollback. I can easily write a library that supports
rolling back this one transaction. Oh, and look, this
one transaction also does not need to complete lightning
fast, and happens rarely. That means I can take advantage
of best speed everywhere else, and use table-level locking on this one transaction just to be safe. These are not options in most large RDBMS', but certainly are in something like MySQL. In fact, you can swap out which back-end storage system (MySQL, Berkely DB and soon Progress) to use on a table-by-table basis for best reliability/performance characteristics.
Bottom line is this: Oracle has it's place, but once you start
to need high-end performance, it falls over in the price/
performance arena. I can run the same database on
MySQL engine for 1/10 - 1/100 the cost and get the same
reliability.
What most people really need out of a database is to never
lose data. If your DB loses data, then get another
one fast. Otherwise, you should be looking at how
much you'll pay when you add the 4th processor....
It's a comples question with complex answers.
In the end you have to decide weather or not you need to scale up and when.
Of thhe free databases three that are closest to doing what oracle does are interbase, postgres and sybase 11.03 (not open source but free). Each one of these is suitable for a small to medium size company to start with. sybase is aging but still usable and postgres has a quirky set of features but keeps getting better at a very fast rate there are also a couple of companies prioviding support for it. Interbase has been around forever, is well tested and has a large userbase. It is supported by an exrtremely knowledgabel company called ibphoenix and borland too. It also runs equally well on windows or *nix and has great third party client side tools for administration.
The next tier up in price you have ms-sql, db/2, and informix, and sybase. MS-SQL is ok if you are willing to tie yourself to windows forever and are willing to pay extra for jdbc drivers and don't want to ever access from unix with php or perl or python (freetds is a valiant effort but it's still not 100% functional).
DB/2 is surprisingly affordable for the workgroup edition I was quoted about 6 grand for an unlimited user license. Compare this with the 5K per processor license for sql2000 and it's a bargain. Your mileage may vary depending on the size of your company and how afraid MS is of you switching. They offer deep discounts to large clients.
I have never used informix or sybase so maybe other people can talk about those but sybase does offer sqlanywhere studio which is a low cost alternative you can check out.
Mysql still has a way to go catch up with these databases so I would say forget about it for now.
In summary. The free databases do anywhere from 70-80% of what the big bucks databases do at about 70-80% of the speed. If you don't need that last 20% there is no need to spend the money.
Allthough none of these databases can compete with oracle head to head they would make great starting points for a company just starting out.
Of the open source databases Interbase is easiest to setup and use IMHO so it would get my final recommendation.
War is necrophilia.
There is an excellant middleware for delhi called ASTA look into it.
War is necrophilia.
In my opinion, it most definitely can be, if the business requirements are used as a primary factor in the database engine selection;
... dynamic tuning, and those dreaded vendor-specific extensions are often used in support of this area. In a modern enterprise, expect millions of transactions (each transaction could be updating 30 tables, with several hundred rows) on an hourly or daily basis.
... 3+ dimensional location data). Similarly, can I distribute my data (I'm not simply referring to tuning) so that it resides where it is required? Without thee included features, what effort must I make to program around the DB engines deficiencies (usually called 'undocumented features' by the vendor).
1. Availability: how crash-proof is the RDBMS is 1 part of the equation. Another is the ability to backup and recover the db. In a 24x7x52 shop, you virtually never get the opportunity to shut down the DB. A simple file or filesystem backup will NEVER let you recover a transaction-consistent system. Also, how well does the engine support high-availability clusters, with automatic replicatin and hot-standby servers.
2. Performance: This is the 1 area where no product is perfect, but the tier-1 products such as Oracle & DB2 particularly excel
Application availability: A company doesn't purchase a database just to have a database, anymore than they should purchase hardware or an OS for their own sake. There are more applications such as ERP and CRM, as well as many client-server and two-tier apps written to support the tier-1 engines.
Scalability: Its fine to cluster servers; I wouldn't want to tailor postgres or mysql to distribute my database on many servers in a number of different geographic areas. Tier-1 vendors have addressed this in the vendor-specific tools (although ANSI 92 attempts to incorporate many of the special features). Size is another factor; can the engine process terabytes as easily as gigabytes? If you have a server with 20GB RAM, will the database take advantage by caching objects (either automatically or by administrative instruction)?
Support: While support contracts CAN be purchased to support most anything, can you call the vendor at 8am Xmas day with an issue that has caused the database to crater? I know from personal experience that Oracle provides that level of support with reasonable expertise available.
Features: While this is a double-edged sword, can the database support all of the required corporate data entities? I include single fields of 400MB (Seismic traces and well logs), as well as providing indexing strategies that reflect the application (i.e. spacial data
Cost: The support and development cost of applications for a free engine MAY actually be higher than purchase of a packaged application for an expensive db.
Security: How does one secure transactions (not just https from the web) between the visible server and the application servers and the database servers? For example, in the petrophysical world, the most dangerous information for competitors to gain is the knowledge of the latitude and longitude that a company is querying.
There are few clear-cut answers in a general sense, but I believe that it is fair to say that the more demanding the application, the higher the probabability that a high-priced RDBMS will be required.
Bill
By itself, no, but there are a number of organizations who will support mySQL for you.
It's no different than support for any other open source software. If you want training and support, you find a third-party company that does training and support.
They may not even really be "third party". Randal Schwartz' Stonehenge Consulting does Perl training. Randal is a key developer in the Perl community. Does he count as third party?
--
Also keep in mind that Sybase offers Linux x86 binaries of it's previous major release for free for any use (deployed commercial use okay!). They offer the current version free for development purposes. The previous major version is plenty good enough for most applications. There is no comparison between MySQL and a real industrial strength database like Sybase. Maybe one day MySQL will be up to snuff and then we'll all use it, but Sybase and Oracle have been working on this stuff for a long time.
Burris
Along those lines, there's also GemStone/S and GemStone/J, OODBMSs for Smalltalk and Java respectively. I don't know about the Java version, but the Smalltalk version is pretty cool stuff, and can interface with C and C++. A lot of people prefer not to call it an OODBMS, but an application server. It's both, more or less.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Good comments/theads pertaining to this were...
Why do we always have to see stories in groups of 3 (that means there's one more DB story coming tomorrow)?
I just came across this, and it seems to address the topic quite frankly. It is, however, wuite simplistic and provides little technical detail. Perhaps someone more familiar with the field could comment...
Your information is old; MySQL does have transaction support now. http://www.mysql.com/news/article-18.html
Yet another RDBM debate cooking up! This is like asking whether there is any point to mission critical software since the mainstream works just fine for the majority of cases. See here lies the point the majority doesn't need an Oracle database just like the majority won't ever need high end servers because their requirements and constraints can be accomplished with the use of off the shelf hardware software. Specialised software fills specific niches and becasue the market for it is relatively small the sales margins have to be high to justify writing said software. If you think that Oracle licensing is steep I encourage you to look at pricetags for geoscience software products. We're talking an excess of $50000US per SEAT. Are some of the technologies more suited to different tasks? No. Not at all. EVERYTHING can be shoehorned to run on a pentuim box with Lenux preinstalled on it. You can be sceptical all you want but once you are responsible for a system where a downtime could mean lives lost or millions wasted you will realize that a meager few thousand bucks is just peanuts. How much would you be willing to spend to protect the life of your kid? Or your wife? Or your sister? (think air traffic control software etc.) Please think those things through before posting them to slashdot front page.
Your pizza just the way you ought to have 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
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.
Always keep a sapphire in your mind
... 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
Read my blog.
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.
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
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
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
News for Geeks in Austin, TX
North Carolina is entrusting their medicare system to some dude writing one page porn sites, are they?
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.
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.
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.
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.
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.
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.