> That's exactly the reason people should stay away from Oracle. Simply because it backs you into the > product in a way the conversion is extremely painful and expensive. conversion from MySQL to > MS-SQL or a similar SQL complient database is really pretty simple. Oracle is the mongrel out > there and should be put to a very public open sourced death.
Funny, I don't have major problems on a typical migration between oracle/sqlserver/db2/postgresql. Oh sure, there are sometimes issues - differences in locking strategies, differences in partitioning, and differences in stored proc capabilities. Those three are the primary areas. But most of the time it's a nit. And of the major commercial databases - oracle has the least respect for standards.
However, Mysql very visibly defended the notion that 99% of the developers didn't need transactions, views, stored procs, subselects, unions, triggers, etc. Until very recently most of these capabilities were missing (even though oracle supported them almost 25 years ago).
Most mysql databases out there today still don't have transactions - and the applications that use them are often excessively complex due to poor legacy functionality in mysql. So, you often end up with 1000 lines of php & five queries in mysql when 10 lines of php and one query would do the job in any other database.
There's a lot of reasons to avoid oracle - its cost, Larry Ellison, oracle sales staff, its complexity, Larry Ellison, its low regards for standards, etc, etc. But the problems porting with msyql - are generally the fault of mysql ab and nobody else.
And until MySQL offers a full feature set nobody should be surprised that migration can be more expensive than necessary. And even then, if your database is going to get really huge - you'll probably want to think in terms of data architecture that go completely beyond what mysql has to offer (even at 100% Ansi-92 compatibility): and your application and overall architecture will be designed with parallelism, clusteroing, replication, partitioning, etc as part of the design.
And then you'll be able to reliably provide fabulous performance while casually slinging millions of rows around at a time. And it'll work great. No surprises.
That's why you sometimes *should* start out using oracle, db2, terradata, or whatever.
> I don't think a company would hire an idiot to admin an expensive tool like oracle.
oooh, I *so* wish that you were right. But it assumes that managers have more choice over staffing, outsourcing, as well as more knowledge of technology & people.
Nope, I've seen *tons* of idiots in charge of oracle databases. And the odd thing is - Oracle especially is so very unforgiving.
But you can usually spot the idiots a mile away - big circles under their eyes from fixing the things they are constantly breaking, small jobs take 8 hours since they can't write a script - and need to interactively modify 400 database object, etc, etc.
Also keep in mind that many very large companies have site licenses for products like oracle, db2, websphere, etc, etc. So - they use the big product for every application. And this makes sense - it's much easier to manage and develop expertise for just Oracle than for a frankenstein collection of a half-dozen databases.
And the less important ones should (theoretically) be where your junior dbas learn the ropes. But it all breaks down with bureacracy...
> This makes it really easy for open-source databases to step-in since there is no lock-in. > Later on if you figure out you need a big honking Oracle/DB2/whatever you can easily change your mind.
kinda-sorta:
what % of the ANSI-92 standard does your tool support? 80%? 85%? and since it probably doesn't support vendor extentions, you're going to be locked into the slowest and lowest-functionality sql.
and that will make you want to upgrade to a more powerful database (or more hardware).
however - getting the performance benefits of oracle or db2 won't come free just by migrating the data to the exact same model on the exact same server. You'll want to add partitioning, new index types, materialized views, etc, etc.
And when you do - you'll usually have to make small adjustments in your sql to take advantage of it. Not always - you can often slip materialized views under the cover in the database and have the queries rewritten by the server on the fly to use these new, faster tables. But still, for partitioning you'll typically need to slightly modify your queries. Hopefully your database-wrapper will make this job easier - but it will be a job.
And if you want to take advantage of non-logged inserts into a temp table, ddl in a transaction, tec, etc - your wrapper will break. It won't support it and you'll end up with some queries in the wrapper and some outside.
On the other hand, if you've got a database that's going to stay tiny, and you're *highly* unlikely to not need OLAP, recursion or other very useful database functionality - then it's probably a good idea. And then, if your application becomes extremely successful - and you get a lot of demand for new functionality. *then* you can rip it out.;-)
> With today's hardware, virtually any credible SQL Engine code-base would run the largest corporation.
ok, sure. You throw $2m at mysql and maybe it can provide the performance of $100k of Oracle or DB2: in running large decision-support queries.
And note: before you say that nobody needs these, keep in mind that most robust operational applications today include some business intelligence/DSS. It's mainstream stuff, and the hotting-selling component that Siebel (CRM) sells today. But mysql/postgresql/sap-db (bleh)/firebird/etc - lack the partitioning & parallelism necessary to pull off this common need at all.
And note again: don't even bother talking about the half-assed clustering solution that mysql has. It's about as credible in the large database world as their lack of transactions were two years ago in the oltp world.
Then you've got replication, high availability, etc, tec. Once again - don't bother offering up the limited/alpha capabilities of the open source databases here. They need some serious time to get those capabilities to 100% before picking up mission critical functions.
So, before talking about cost-benefit equations - you need to get more familiar with the technology. And more familiar with the larger issues within IT.
There's some cool stuff happening in the open source database world. But also a hell of a lot of hype - and some of the products are pure crap.
> It does not require knowledge of SQL. This is the killer feature, except no one seems to get it. The > query builder is simply superb. I am an ardent FOSS advocate and I helped found the first Egyptian > LUG. If I say it is superb know that I do not say so idly.
Man, I don't know how many times I've seen queries constructed by people using that interface - that provided incorrect results. Note to user: when the tool automatically includes 'distinct' in your queries you know it's a piece of shit. You might have better luck with Crystal or Brio, PHP with Chart Director, etc, etc.
> Killer feature number two: seamless interoperability with Excel. Ad hoc reporting nirvana.
Hmmm, interoperability with Excel is a good thing. Ad hoc reporting nirvana, however it is not.
Check out (R)OLAP tools if you want to see actual reporting nirvana...
> Everything noted in the parent is well documented functionality in MySQL, which takes the approach of > not generating application-breaking exceptions, and allowing you to split of data validation as > either a pre-processing step or a more macroscopic endevor.
Failing to provide exceptions to obvious errors is now 'well documented functionality'? Really? Exactly where? I remember when MySQL listed most of these issues as 'known problems'.
I think you're just misinterpreting the cause of these errors: they're *NOT* a part of a deliberate exception handling strategy. They go beyond input validation, and affect database configuration itself. They're simply shoddy workmanship that MySQL needs to clean up quickly.
> You may not like this approach. If you don't, then don't use MySQL. There are lots of other (very good) > choices. Slashdot doesn't need your redundant and off-topic flames.
Ah, the topic is: "Database Error Detection and Recovery", right? And the OP mentioned that this is the main reason cause of MySQL complaints these days, right?
> A well documented convinience for applications > which always behaves the same way.
Pardon? So when MySQL fails to report of an exception (incorrect date, string overflow, etc, etc, etc) - that's intentional? It wasn't sloppiness or incompetence? So, should the other database vendors start eliminating exception handling as well - perhaps in the interest of keeping the product easy to use?
On the other hand, maybe you need to get a little emotional distance from the product.
> Please explain your definition of erratic for me, because mine doesn't seem to match the example you > give.
How's this: sometimes mysql statements will produce exceptions consistent with every other major dbms product. And sometimes they won't. There's no discernable patten here. You might just need to: 1. perform *enormous* amounts of testing on your application to determine if database services things you should be able to take for granted really work. 2. read the gotchas page and review your code closely. Then test the hell out of it as well.
Of course, testing is always valuable. But putting an extra month of testing into an application just because the database lack reasonable exception handling is hardly expected in 2004 - or economical.
> Wrong. Simply wrong. What they said is that their PAYING CUSTOMERS prioritize their work, and > while having everything would be nice, they have to do things in the order that puts the bread on > the table.
No, I've specifically read interviews with MySQL AB leaders in which they stated that 99% of the applications out there didn't need transactions. Might have been on slashdot, will check later.
> For something like sub-selects, vies, and other goodies, I'd much rather have all of the features > of 4.0 and 4.1 before those.
Sure, given the list of missing features that they had two years ago, it could be difficult to prioritize. But keep in mind that these relational database features have always been provided in the v1.0 release of every other dbms product out there. DB2 & Oracle supported them *more than 20 years ago*.
An appropriate response from MySQL would be: we'll implement as soon as possible, or we see ourselves as a very simple database. The inappropriate response was: hey, all you new developers - you don't need that stuff anyway. Transactions? Only banking applications need that junk. That was unresponsible misinformation.
The point of the many of the 'gotchas' is that this software behaves erractically: rather than produce an exception during an overflow or conversion error, for example, it just silently modifies the data and returns no warning to the user.
The truly bizarre thing about this set of errors is that it is about the only database management software you'll find that is so guilty of this behavior. You'd never accept that behavior from SQL Server, Oracle, DB2, Informix, Sybase, etc - so why accept it from MySQL? Does it get some kind of 'get out of jail free' card regarding product quality just because it's open source?
Two years ago the folks from MySQL stated that transactions, views, subselects, etc weren't needed by 99% of the applications out there. That was pure misinformation. And a lot of people called them on it. Now they're getting around to fixing those feature dificiencies in the product. And it's a better product because of it.
Once they get around to fixing all the silent errors and other quality control problems in the product - it'll be a better product for that reason as well.
Anyhow - please don't blame us victims. If you don't want to hear about rediculous problems with the product - help get the vendor to fix them. There's really no excuse after all.
> After everything I've heard, I'm inclined to belive that just about any and every SQL solution > will give anyone and everyone grief, the only difference being the flavor of grief.
Well, if you only encounter a database on rare occasion, then it will probably be a bit of grief: SQL isn't like c/java/.net/perl/python/etc. It's like the difference between solving a puzzle (SQL) and building a house (python).
And that's just SQL: transaction management, relational (or dimensional) modeling, data management issues, data quality issues are all subjects of their own.
On the other hand, if you build many business applications, find yourself interfacing with databases commonly, or are crunching a lot of data...then learning about relational databases is probably well worth your while.
It's not really that difficult, and many of the concepts that are different than procedural or oo development are ultimately inescapable (such as transaction management).
And wrapping SQL in an abstraction layer can work, but there are many legitimate circumstances in which it won't - like when you're querying against 100 GB of data and must have good performance.
> But I'm curious where the best transition strategy lies: starting out with MySQL, can one > grow to a certain point and then transition to one of the more expensive, supported, > high-performance db engines in a reasonable way?
That's a good strategy - except - that mysql is probably the least portable database out there. Starting from postgresql then moving (if necessary) to db2/oracle/sybase/sql server would generally be easier.
On the other hand, keep in mind that the cost of commercial licensing for very small platforms is typically quite cheap for most databases anyway: DB2 is as cheap as $500 for a dual-cpu server. Oracle's lowest end configuration is almost as cheap as is SQL Server's.
And porting between databases is not trivial for applications of any complexity. Not to say that it shouldn't be done, but it's one of those projects that shouldn't be planned for a busy afternoon.
> I like MySQL as a concept, but my understanding is that it's missing a lot of the pieces that one > would need from an enterprise DB.
They've been addressing the missing feature set over the last couple of years. But there's still a way to go with the basics (in some ways Oracle/DB2 in '82 were more advanced than MySQL in '04).
However, I'd be more concerned with: 1. the non-ANSI philosophy 2. the flip-flopping on database philosophy (two years ago they insisted nobody needed transactions (!), views, stored procs, etc, now they have them) 3. the silent error approach: common sql errors (type errors, string truncations, etc) commonly fail with no exception to the user. This allows data corruption, and is completely unacceptable for a competitive database product.
On the positive side, it does have momentum. So, I'm sure the basic feature gap will eventually be resolved. The philosophical & design issues are another matter though. Perhaps they'll address those. Then again, maybe not. Until they do, I use alternatives like postgresql.
If you were thinking about bringing an infant or toddler, please don't.
This isn't "Finding Nemo" - it has people getting killed. It shows parental fear & inability to protect children. Scarey stuff for a four or five year old.
I saw (and thoroughly enjoyed) the film yesterday, but it was partly spoiled by screaming babies. If you're the couple at the Colo Springs showing with four kids under five, that allowed the one baby to cry continuously - please don't do that to a theater again. Next time someone might say something awkward to you. Like "hey man, go be a dad".
And next time, don't assume that because something's animated it's great for kids.
> I know sql, very well in fact. I'm not asking for low-level access to my data I'm asking for low level > access to my database server. Something native to my client language or my language of choice that > would integrate with my code insight and IDE features, use enums, classes, variables, exceptions > etc. Instead of a SQL reference and a billion static string resources.
To do this, you probably want a OODBMS, one that is tightly integrated into java, etc. Those options exist today - and provide very seamless persistence services to your application.
Relational databases are metadata-driven on the other hand - if you take a look you can see that all tables & columns are described in system tables. This gives other kinds of benefits - such as allowing the database to provide a generic joining capability in which you don't have to plan out how to do the joins - it does this for you.
OODBMS' can be very fast - but their performance stinks for long scans, huge queries, etc. Additionally - in everyone that needs access to your data should go through your API. While that make sense sometimes (for transactions), it completely fails when you want to do a simple report (Try marshalling 1 million objects in java).
No recommendation for you here, perhaps this is something that would be easier to manage from the IDE?
> Basically, if you have to mentally add an implicit "AND X IS NOT NULL" to every condition, wouldn't it be better to make everything explicit and clear instead?
The wacky part is using NULLs as a primary excuse to develop another language. First off - NULLs are optional in relational databases. Don't like them? Fine, don't use them. declare your columns 'NOT NULL'. It's that easy.
Secondly, most work-arounds for unknown data suck:
* The easy ones involve keeping an 'unknown' value row in most of your tables. That works great - except for high cardinality columns that aren't lookups - like monetary fields, etc.
* the more common easy work-around is to reserve some value as NULL (2000/01/01 for a date, -1 for an integer column, 'n/a' for a varchar, etc). This really sucks - not only do you have to exclude this from your queries, but you need to know exactly what value to check for, and it's very likely that you'll need a variety of values for each type.
* the approach I've seen most often by the more skilled of the anti-null crowd involves the creation of more tables - in order to isolate the nullable columns onto other tables that have condition rows. That's ok - but it involves an *explosion* in the size & complexity of the data model. There are some benefits - like it may do a better job of explicitely describing the subject process. But the downside - is that we already *denormalize* (prejoin) many tables together for better performance - primarily for reporting & analysis. Of course, the anti-null crowd also believes that denormalization is a sin - and that database vendors could theoretically provide great performance without denormalization. Unfortunately, their supporting analysis is based upon transactional rather than analytic systems. Ultimately, this approach looks like something that was baked up by people who might work on database software, but don't actually build real-world systems using it.
BTW, SQL does support hierarchies - Oracle & DB2 in particular are very good at it.
Also, keep in mind that you can easily wrap low-level SQL operations (insert,update,delete,select - each for one row) with another language. That would allow you to use your own database language.
Of course, the performance wouldn't be the best, and certain features would be difficult to implement. But, it could be metadata-driven, and would allow the option of using either language.
sure - code modularization is way too unpleasant: we do it through views typically rather than table functions. Theoretically we could use table functions, but they're non-portable and often have performance problems.
and how about network data models - that allow nearly infinite flexibility. They're cool stuff, can be built in a RDBMS, take advantage of many database features BUT aren't supported with constraints.
see, if you were born around 1940 you could have been using IMS/DB, VSAM, ISAM, IDMS, etc back in the 70s.
Tons of opportunities there for low-level access to your data. Of course, there's a reason that all those database management systems were abandoned for a 'busted ass super high level language'. It's because they sucked to maintain, they didn't evolve well as business requirements changed over time, and if you had the *most* basic of business questions - you'd never get an answer without a month of writing code.
But don't despair - pick up a little more SQL and you may find it isn't that tough.
Given the recent dramatic drop in rs/6000 prices, it might be cheaper & safer to just get a new aix box.
You could probably get a new p615 for under $10k. Add four 15k-rpm 36-gbyte drives internally for data, and you've got a surprisingly cheap, fast, and reliable box. And there are lower-end options as well that might be able to save more money. Then once you migrate off this application you could resell the box, or put linux on it.
Alternatively, getting an updated application from your vendor that specially supports linux would be another safe option.
Back to the original question - emulate aix on linux, that unfortunately doesn't sound likely to be reliable...
In spite of the fact that Filemaker Pro isn't a 'real database' - it's developed a well-earned reputation for being a quick & effective tool.
I'd stick with it unless you've got some genuine objectives/requirements that exceed its capabilities.
If you can't afford the licensing costs (which are modest), and have quite a lot of time on your hands - then there are a wealth of options. I personally like php/python + postgresql. But none of these options will match the development ease of filemaker pro. You'll be kissing that goodbye.
yuck, the reasons given in the article are all just back-handed compliments. Like being asked by a job interviewer what's your biggest weakness, and saying that you work too hard and care too much!
How about something like - programmers want a language, not a lifestyle: and java's ambition to do *everything* is more than just about anyone wants.
How about the 'not invented here' syndrome? EJBs? Container-Managed Persistence? Ever try to get some other application to talk to a database where they used container-managed persistence? You're out of luck. And before you say go through the Java app - you need to understand running *major* analytics on a large database will do to java - like imaging marshalling 500 million objects...
At a java systems integrated during the dot-bomb I performed some productivity analysis, and discovered that it look us just as long to create a webpage using java in 2001 as it did to create a stateless page using cics on mainframes in 1989. Of course, this is partially due to the fact that we had one person creating the entire page in cics, but required separate html, jsp, & ejb people with java due to its specialization.
You can always dismiss any heated debate as simply a result of nit-picking or personal preferences.
However, the differences here are quite substantial. And it isn't really 'mysql vs postgresql' - it's more like 'mysql vs inexpensive standards-compliant database solutions'. What really irks most experience database developers about mysql is that mysql abandoned decades of standards and standard features - while insisting that 90% of the users didn't need transactions, triggers, views, etc. That's disingenuous misinformation.
mysql still has a role out there - since it has such a wide host base and so much 'mind share'. But this is all marketing. In almost any technical comparison, Postgresql now comes out on top.
Furthermore, since postgresql is very similar to other relational databases - migration between it and oracle, db2, sql server, etc is relatively painless (unless you went overboard on stored procs, etc). This means that your investment in postgresql is fairly 'future-proof'. If on the other hand, you've gone with mysql, you will always have a more difficult migration - and may fail to get anticipated performance benefits since you are probably using the target database is a way not recommended by its vendor (joining inside application rather than inside sql, etc). This is especially true of the many mysql applications out there that believed MySQL AB when they told people that 90% of the applications didn't need transactions (!)
Of course, you can wait for mysql to catch up to everyone else in the database features area, and perhaps they'll try to become more standards compliant along the way. But that's going to be a tough slog for them, probably involving a complete rewrite. Could take quite a while, and there may be no easy transition for today's mysql apps.
> As for parallel Oracle, it doesn't really live up to its hype. Even failover clustering on Oracle > sucks (I'm speaking from 2 years ago, so it may have improved - however, people were using Oracle > for mission-critical applications 2 years ago, so I think my argument still stands).
Well, oracle ops/rac has always been an extremely complex product - one that most folks have avoided for good reasons IMHO. But that's not what I'm talking about here - I'm just talking plain/vanilla partitioning & parallelism. Well, the parallelism comes free with their standard & higher packages, you pay an extra $15k or so for partitioning. But it's very simple & easy to use, and most oracle applications these days take advantage of it. It's one of the chief reasons to use oracle these days, since that part of the product really sings.
> I agree that for VERY LARGE data sets, PostgreSQL still lacks, but most of the industry > isn't working with VERY LARGE sets -- that's basically a niche market.
The only reason that most people aren't using very large volumes of data - is that they haven't yet figured out the value of analytics and how to preprocess data. For those that do understand this what data can do know that a small amount of transactional data will balloon in size once you set it up for analytical purposes. So, that 5 gbytes of data in your transactional database can easily consume 100+ gbytes in a warehouse or data mart.
Why so large? You've performed heavy transformations on the data to cleanse, integrate, summarize, and cleanse it. Then you kept every single version so that you have a complete historical recond. Once you've done this the data may be huge - but now you can finally start answering the basic business questions with it.
And maybe get into that profitable niche - where you're competing with companies that know exactly where they're making & loosing money...
I didn't think postgresql allowed inserts to the view itself though. If it doesn't, then you'll have a much more complex application - since it always needs to know which table to insert to.
> For (1) and (2), I've never seen it. I worked w/ Travelocity and Cheaptickets.com and numerous > other websites at EDS, and none of them used those features. Most of them were simply > multiprocessor CPU boxes with lots of memory. I'm sure there are several cases where it's > needed, but I don't think it's as ubiquitous as you indicate.
No, not ubiquitious. But it has been common in data warehousing now for almost ten years. Teradata then Informix became famous for their parallelism & partitioning capabilities based on it by mid-90s. Outside of data warehousing, these capabilities are commonly used in any large reporting systems, (r)olap, fraud detection, any scoring systems (especially balanced scorecard systems), clickstream analysis, etc.
The main reason to avoid the clustering form of parallelism (used in teradata, informix, and db2) is that the database licensing can get expensive. The main reason to avoid some of the parallelism capabilities within oracle is that the database AND hardware can get expensive. But that still leaves you with several options, take db2 for example:
- spend $50k (list) on a fast 4-way
- spend $30k (list) on db2 workgroup edition
- run parallel queries
- cluster your data with multi-dimensional clustering and/or union-all views. A solution like this is about twice as expensive to purchase as postgresql but no extra cost over a plain commercial solution. And loads data at speeds like 50,000 rows / second - and leverages both parallelism and partitioning in query responses.
Neither Postgresql nor mysql can match the performance of that solution without relying upon multiple machines and manual partitioning. Both the labor and hardware costs of this alternative approach far outstrip the database licensing cost of using oracle or db2.
Basically, anyone who isn't leveraging these capabilities (and other similar ones) in large commercial databases these days either can't afford to change a legacy application, doesn't have the (relatively simple) database skills to pull it off, or really should be using postgresql...
And of course there are good reasons to use postgresql in this space - say you've got a start-up and can't afford the initial commercial licensing investment. That's fine, we just shouldn't kid anyone that postgresql at the high-end is very competitive (yet).
Postgresql is cool, but it isn't ready to compete directly with Oracle or DB2 on large databases yet.
For example, lets say you've got a large reporting application...
1. DB2 can leverage all CPUs on a single CPU - and split the workload for a query across 2,4,8 or more CPUs.
2. you can partition data across multiple servers. This allows you to spread a single 400 gbyte table across a dozen fast 2-4 way servers. This allows you to leverage cheaper hardware (commodity servers vs sun e10ks), and with relatively low cost be able to throw 40 cpus at a query.
3. you can also use multi-dimensional clustering or union-all views (similar to Oracle partitioning). This allows you to avoid scanning data that isn't in the partition you're interested in - often dropping 95% of the workload.
Note that all three of the above can be used in conjunction - so you can create a database with 40+ CPUs that allows you to focus on just the 20 million rows of the 400 million in that table. Postgresql (or mysql) on the other hand will be slogging through all 400 million rows on a 4-way. No comparison whatsoever in performance at this level. They'll eventually get there, but they've got a long way to go.
Of course, most people don't have this kind of performance-challenge, but most of this capability is useful even at the 10 gbyte database size. In the meanwhile, postgresql is a great little database for quite a few applications: and it does a good job of supporting ansi sql, it is generally simple to port from postgresql to oracle, db2, etc.
heavy transactional read loads for non-critical apps perhaps.
- Not heavy DSS/OLAP read loads though (where indexes don't work well and you want partitioning to bypass 95% of your rows). See Oracle, Informix & DB2 to see how this is done and the results it achieves.
- Haven't seen a proper benchmark but antecdotal evidence points to problems that MySQL has scaling to meet much write traffic. Postgresql, Firebird, etc on the inexpensive/free side appear to be better choices for this kinds of applications.
- Then you've got the entire managability issue - on larger projects in which you desperately want the kind of functionality that MySQL AB has claimed that 95% of database applications don't need and which they've failed to support well: like database-enforced data quality constraints (referential, uniqueness, and check constraint declaratives). Add to that the lack of flexibility that comes from various missing features like views & stored procedures. Add to that the problems porting their non-standard SQL. Lastly, add to all of the above their massive list of exception-handling problems - in which errors silently fail.
Nah, MySQL is a nice little database. But unless 'heavy loads' means non-critical, read-only, index-oriented loads - I think that there are about a dozen better options available.
Oh yeah, and no - cloudscape isn't a competitor for mysql in general. They each bring different strengths to the table.
However, Oracle is free to change their licensing once again.
Remember, it was just a few years ago that Oracle introduced, and then was forced to abandon, the "Power Unit". According to that licensing schema you paid $15-100 / Power Unit to license their product (depending on version, year, etc).
A power unit was a mhz, so for example: - single server with 2x400 mhz CPUs could cost $100*2*400 = $80,000.
On the other hand, if they were still using this today, you could be priced for a fast four-way: $100 * 4 CPUs * 3000mhz= $1,200,000
The only reason that they backed down from this pricing was that SQL Server was eating their lunch. In fact, their greed is the main reason sql server gained so much market share around 1999-2002.
So, anyhow they aren't charging for hyper-threading today - but if they think that they can get away with it in the future they certainly will do so. Luckily, between SQL Server , postgresql, and mysql at the low-end and DB2 at the high-end Oracle's not in a good position to raise their rates any time soon.
Slashdot Mirror
> That's exactly the reason people should stay away from Oracle. Simply because it backs you into the
> product in a way the conversion is extremely painful and expensive. conversion from MySQL to
> MS-SQL or a similar SQL complient database is really pretty simple. Oracle is the mongrel out
> there and should be put to a very public open sourced death.
Funny, I don't have major problems on a typical migration between oracle/sqlserver/db2/postgresql. Oh sure, there are sometimes issues - differences in locking strategies, differences in partitioning, and differences in stored proc capabilities. Those three are the primary areas. But most of the time it's a nit. And of the major commercial databases - oracle has the least respect for standards.
However, Mysql very visibly defended the notion that 99% of the developers didn't need transactions, views, stored procs, subselects, unions, triggers, etc. Until very recently most of these capabilities were missing (even though oracle supported them almost 25 years ago).
Most mysql databases out there today still don't have transactions - and the applications that use them are often excessively complex due to poor legacy functionality in mysql. So, you often end up with 1000 lines of php & five queries in mysql when 10 lines of php and one query would do the job in any other database.
There's a lot of reasons to avoid oracle - its cost, Larry Ellison, oracle sales staff, its complexity, Larry Ellison, its low regards for standards, etc, etc. But the problems porting with msyql - are generally the fault of mysql ab and nobody else.
And until MySQL offers a full feature set nobody should be surprised that migration can be more expensive than necessary. And even then, if your database is going to get really huge - you'll probably want to think in terms of data architecture that go completely beyond what mysql has to offer (even at 100% Ansi-92 compatibility): and your application and overall architecture will be designed with parallelism, clusteroing, replication, partitioning, etc as part of the design.
And then you'll be able to reliably provide fabulous performance while casually slinging millions of rows around at a time. And it'll work great. No surprises.
That's why you sometimes *should* start out using oracle, db2, terradata, or whatever.
> I don't think a company would hire an idiot to admin an expensive tool like oracle.
oooh, I *so* wish that you were right. But it assumes that managers have more choice over staffing, outsourcing, as well as more knowledge of technology & people.
Nope, I've seen *tons* of idiots in charge of oracle databases. And the odd thing is - Oracle especially is so very unforgiving.
But you can usually spot the idiots a mile away - big circles under their eyes from fixing the things they are constantly breaking, small jobs take 8 hours since they can't write a script - and need to interactively modify 400 database object, etc, etc.
Also keep in mind that many very large companies have site licenses for products like oracle, db2, websphere, etc, etc. So - they use the big product for every application. And this makes sense - it's much easier to manage and develop expertise for just Oracle than for a frankenstein collection of a half-dozen databases.
And the less important ones should (theoretically) be where your junior dbas learn the ropes. But it all breaks down with bureacracy...
> This makes it really easy for open-source databases to step-in since there is no lock-in.
;-)
> Later on if you figure out you need a big honking Oracle/DB2/whatever you can easily change your mind.
kinda-sorta:
what % of the ANSI-92 standard does your tool support? 80%? 85%? and since it probably doesn't support vendor extentions, you're going to be locked into the slowest and lowest-functionality sql.
and that will make you want to upgrade to a more powerful database (or more hardware).
however - getting the performance benefits of oracle or db2 won't come free just by migrating the data to the exact same model on the exact same server. You'll want to add partitioning, new index types, materialized views, etc, etc.
And when you do - you'll usually have to make small adjustments in your sql to take advantage of it. Not always - you can often slip materialized views under the cover in the database and have the queries rewritten by the server on the fly to use these new, faster tables. But still, for partitioning you'll typically need to slightly modify your queries. Hopefully your database-wrapper will make this job easier - but it will be a job.
And if you want to take advantage of non-logged inserts into a temp table, ddl in a transaction, tec, etc - your wrapper will break. It won't support it and you'll end up with some queries in the wrapper and some outside.
On the other hand, if you've got a database that's going to stay tiny, and you're *highly* unlikely to not need OLAP, recursion or other very useful database functionality - then it's probably a good idea. And then, if your application becomes extremely successful - and you get a lot of demand for new functionality. *then* you can rip it out.
> With today's hardware, virtually any credible SQL Engine code-base would run the largest corporation.
ok, sure. You throw $2m at mysql and maybe it can provide the performance of $100k of Oracle or DB2: in running large decision-support queries.
And note: before you say that nobody needs these, keep in mind that most robust operational applications today include some business intelligence/DSS. It's mainstream stuff, and the hotting-selling component that Siebel (CRM) sells today. But mysql/postgresql/sap-db (bleh)/firebird/etc - lack the partitioning & parallelism necessary to pull off this common need at all.
And note again: don't even bother talking about the half-assed clustering solution that mysql has. It's about as credible in the large database world as their lack of transactions were two years ago in the oltp world.
Then you've got replication, high availability, etc, tec. Once again - don't bother offering up the limited/alpha capabilities of the open source databases here. They need some serious time to get those capabilities to 100% before picking up mission critical functions.
So, before talking about cost-benefit equations - you need to get more familiar with the technology. And more familiar with the larger issues within IT.
There's some cool stuff happening in the open source database world. But also a hell of a lot of hype - and some of the products are pure crap.
> It does not require knowledge of SQL. This is the killer feature, except no one seems to get it. The
> query builder is simply superb. I am an ardent FOSS advocate and I helped found the first Egyptian
> LUG. If I say it is superb know that I do not say so idly.
Man, I don't know how many times I've seen queries constructed by people using that interface - that provided incorrect results. Note to user: when the tool automatically includes 'distinct' in your queries you know it's a piece of shit. You might have better luck with Crystal or Brio, PHP with Chart Director, etc, etc.
> Killer feature number two: seamless interoperability with Excel. Ad hoc reporting nirvana.
Hmmm, interoperability with Excel is a good thing. Ad hoc reporting nirvana, however it is not.
Check out (R)OLAP tools if you want to see actual reporting nirvana...
> Everything noted in the parent is well documented functionality in MySQL, which takes the approach of
> not generating application-breaking exceptions, and allowing you to split of data validation as
> either a pre-processing step or a more macroscopic endevor.
Failing to provide exceptions to obvious errors is now 'well documented functionality'? Really? Exactly where? I remember when MySQL listed most of these issues as 'known problems'.
I think you're just misinterpreting the cause of these errors: they're *NOT* a part of a deliberate exception handling strategy. They go beyond input validation, and affect database configuration itself. They're simply shoddy workmanship that MySQL needs to clean up quickly.
> You may not like this approach. If you don't, then don't use MySQL. There are lots of other (very good)
> choices. Slashdot doesn't need your redundant and off-topic flames.
Ah, the topic is: "Database Error Detection and Recovery", right? And the OP mentioned that this is the main reason cause of MySQL complaints these days, right?
Hmmm, seems 100% on topic.
> A well documented convinience for applications
> which always behaves the same way.
Pardon? So when MySQL fails to report of an exception (incorrect date, string overflow, etc, etc, etc) - that's intentional? It wasn't sloppiness or incompetence? So, should the other database vendors start eliminating exception handling as well - perhaps in the interest of keeping the product easy to use?
On the other hand, maybe you need to get a little emotional distance from the product.
> Please explain your definition of erratic for me, because mine doesn't seem to match the example you
> give.
How's this: sometimes mysql statements will produce exceptions consistent with every other major dbms product. And sometimes they won't. There's no discernable patten here. You might just need to:
1. perform *enormous* amounts of testing on your application to determine if database services things you should be able to take for granted really work.
2. read the gotchas page and review your code closely. Then test the hell out of it as well.
Of course, testing is always valuable. But putting an extra month of testing into an application just because the database lack reasonable exception handling is hardly expected in 2004 - or economical.
> Wrong. Simply wrong. What they said is that their PAYING CUSTOMERS prioritize their work, and
> while having everything would be nice, they have to do things in the order that puts the bread on
> the table.
No, I've specifically read interviews with MySQL AB leaders in which they stated that 99% of the applications out there didn't need transactions. Might have been on slashdot, will check later.
> For something like sub-selects, vies, and other goodies, I'd much rather have all of the features
> of 4.0 and 4.1 before those.
Sure, given the list of missing features that they had two years ago, it could be difficult to prioritize. But keep in mind that these relational database features have always been provided in the v1.0 release of every other dbms product out there. DB2 & Oracle supported them *more than 20 years ago*.
An appropriate response from MySQL would be: we'll implement as soon as possible, or we see ourselves as a very simple database. The inappropriate response was: hey, all you new developers - you don't need that stuff anyway. Transactions? Only banking applications need that junk. That was unresponsible misinformation.
> It's software that does what you tell it to do.
Actually, no.
The point of the many of the 'gotchas' is that this software behaves erractically: rather than produce an exception during an overflow or conversion error, for example, it just silently modifies the data and returns no warning to the user.
The truly bizarre thing about this set of errors is that it is about the only database management software you'll find that is so guilty of this behavior. You'd never accept that behavior from SQL Server, Oracle, DB2, Informix, Sybase, etc - so why accept it from MySQL? Does it get some kind of 'get out of jail free' card regarding product quality just because it's open source?
Two years ago the folks from MySQL stated that transactions, views, subselects, etc weren't needed by 99% of the applications out there. That was pure misinformation. And a lot of people called them on it. Now they're getting around to fixing those feature dificiencies in the product. And it's a better product because of it.
Once they get around to fixing all the silent errors and other quality control problems in the product - it'll be a better product for that reason as well.
Anyhow - please don't blame us victims. If you don't want to hear about rediculous problems with the product - help get the vendor to fix them. There's really no excuse after all.
> After everything I've heard, I'm inclined to belive that just about any and every SQL solution
> will give anyone and everyone grief, the only difference being the flavor of grief.
Well, if you only encounter a database on rare occasion, then it will probably be a bit of grief: SQL isn't like c/java/.net/perl/python/etc. It's like the difference between solving a puzzle (SQL) and building a house (python).
And that's just SQL: transaction management, relational (or dimensional) modeling, data management issues, data quality issues are all subjects of their own.
On the other hand, if you build many business applications, find yourself interfacing with databases commonly, or are crunching a lot of data...then learning about relational databases is probably well worth your while.
It's not really that difficult, and many of the concepts that are different than procedural or oo development are ultimately inescapable (such as transaction management).
And wrapping SQL in an abstraction layer can work, but there are many legitimate circumstances in which it won't - like when you're querying against 100 GB of data and must have good performance.
> But I'm curious where the best transition strategy lies: starting out with MySQL, can one
> grow to a certain point and then transition to one of the more expensive, supported,
> high-performance db engines in a reasonable way?
That's a good strategy - except - that mysql is probably the least portable database out there. Starting from postgresql then moving (if necessary) to db2/oracle/sybase/sql server would generally be easier.
On the other hand, keep in mind that the cost of commercial licensing for very small platforms is typically quite cheap for most databases anyway: DB2 is as cheap as $500 for a dual-cpu server. Oracle's lowest end configuration is almost as cheap as is SQL Server's.
And porting between databases is not trivial for applications of any complexity. Not to say that it shouldn't be done, but it's one of those projects that shouldn't be planned for a busy afternoon.
> I like MySQL as a concept, but my understanding is that it's missing a lot of the pieces that one
> would need from an enterprise DB.
They've been addressing the missing feature set over the last couple of years. But there's still a way to go with the basics (in some ways Oracle/DB2 in '82 were more advanced than MySQL in '04).
However, I'd be more concerned with:
1. the non-ANSI philosophy
2. the flip-flopping on database philosophy (two years ago they insisted nobody needed transactions (!), views, stored procs, etc, now they have them)
3. the silent error approach: common sql errors (type errors, string truncations, etc) commonly fail with no exception to the user. This allows data corruption, and is completely unacceptable for a competitive database product.
On the positive side, it does have momentum. So, I'm sure the basic feature gap will eventually be resolved. The philosophical & design issues are another matter though. Perhaps they'll address those. Then again, maybe not. Until they do, I use alternatives like postgresql.
If you were thinking about bringing an infant or toddler, please don't.
This isn't "Finding Nemo" - it has people getting killed. It shows parental fear & inability to protect children. Scarey stuff for a four or five year old.
I saw (and thoroughly enjoyed) the film yesterday, but it was partly spoiled by screaming babies. If you're the couple at the Colo Springs showing with four kids under five, that allowed the one baby to cry continuously - please don't do that to a theater again. Next time someone might say something awkward to you. Like "hey man, go be a dad".
And next time, don't assume that because something's animated it's great for kids.
> I know sql, very well in fact. I'm not asking for low-level access to my data I'm asking for low level > access to my database server. Something native to my client language or my language of choice that
> would integrate with my code insight and IDE features, use enums, classes, variables, exceptions
> etc. Instead of a SQL reference and a billion static string resources.
To do this, you probably want a OODBMS, one that is tightly integrated into java, etc. Those options exist today - and provide very seamless persistence services to your application.
Relational databases are metadata-driven on the other hand - if you take a look you can see that all tables & columns are described in system tables. This gives other kinds of benefits - such as allowing the database to provide a generic joining capability in which you don't have to plan out how to do the joins - it does this for you.
OODBMS' can be very fast - but their performance stinks for long scans, huge queries, etc. Additionally - in everyone that needs access to your data should go through your API. While that make sense sometimes (for transactions), it completely fails when you want to do a simple report (Try marshalling 1 million objects in java).
No recommendation for you here, perhaps this is something that would be easier to manage from the IDE?
> Basically, if you have to mentally add an implicit "AND X IS NOT NULL" to every condition, wouldn't it be better to make everything explicit and clear instead?
The wacky part is using NULLs as a primary excuse to develop another language. First off - NULLs are optional in relational databases. Don't like them? Fine, don't use them. declare your columns 'NOT NULL'. It's that easy.
Secondly, most work-arounds for unknown data suck:
* The easy ones involve keeping an 'unknown' value row in most of your tables. That works great - except for high cardinality columns that aren't lookups - like monetary fields, etc.
* the more common easy work-around is to reserve some value as NULL (2000/01/01 for a date, -1 for an integer column, 'n/a' for a varchar, etc). This really sucks - not only do you have to exclude this from your queries, but you need to know exactly what value to check for, and it's very likely that you'll need a variety of values for each type.
* the approach I've seen most often by the more skilled of the anti-null crowd involves the creation of more tables - in order to isolate the nullable columns onto other tables that have condition rows. That's ok - but it involves an *explosion* in the size & complexity of the data model. There are some benefits - like it may do a better job of explicitely describing the subject process. But the downside - is that we already *denormalize* (prejoin) many tables together for better performance - primarily for reporting & analysis. Of course, the anti-null crowd also believes that denormalization is a sin - and that database vendors could theoretically provide great performance without denormalization. Unfortunately, their supporting analysis is based upon transactional rather than analytic systems. Ultimately, this approach looks like something that was baked up by people who might work on database software, but don't actually build real-world systems using it.
BTW, SQL does support hierarchies - Oracle & DB2 in particular are very good at it.
Also, keep in mind that you can easily wrap low-level SQL operations (insert,update,delete,select - each for one row) with another language. That would allow you to use your own database language.
Of course, the performance wouldn't be the best, and certain features would be difficult to implement. But, it could be metadata-driven, and would allow the option of using either language.
sure - code modularization is way too unpleasant: we do it through views typically rather than table functions. Theoretically we could use table functions, but they're non-portable and often have performance problems.
and how about network data models - that allow nearly infinite flexibility. They're cool stuff, can be built in a RDBMS, take advantage of many database features BUT aren't supported with constraints.
see, if you were born around 1940 you could have been using IMS/DB, VSAM, ISAM, IDMS, etc back in the 70s.
Tons of opportunities there for low-level access to your data. Of course, there's a reason that all those database management systems were abandoned for a 'busted ass super high level language'. It's because they sucked to maintain, they didn't evolve well as business requirements changed over time, and if you had the *most* basic of business questions - you'd never get an answer without a month of writing code.
But don't despair - pick up a little more SQL and you may find it isn't that tough.
Given the recent dramatic drop in rs/6000 prices, it might be cheaper & safer to just get a new aix box.
You could probably get a new p615 for under $10k. Add four 15k-rpm 36-gbyte drives internally for data, and you've got a surprisingly cheap, fast, and reliable box. And there are lower-end options as well that might be able to save more money. Then once you migrate off this application you could resell the box, or put linux on it.
Alternatively, getting an updated application from your vendor that specially supports linux would be another safe option.
Back to the original question - emulate aix on linux, that unfortunately doesn't sound likely to be reliable...
In spite of the fact that Filemaker Pro isn't a 'real database' - it's developed a well-earned reputation for being a quick & effective tool.
I'd stick with it unless you've got some genuine objectives/requirements that exceed its capabilities.
If you can't afford the licensing costs (which are modest), and have quite a lot of time on your hands - then there are a wealth of options. I personally like php/python + postgresql. But none of these options will match the development ease of filemaker pro. You'll be kissing that goodbye.
yuck, the reasons given in the article are all just back-handed compliments. Like being asked by a job interviewer what's your biggest weakness, and saying that you work too hard and care too much!
How about something like - programmers want a language, not a lifestyle: and java's ambition to do *everything* is more than just about anyone wants.
How about the 'not invented here' syndrome? EJBs? Container-Managed Persistence? Ever try to get some other application to talk to a database where they used container-managed persistence? You're out of luck. And before you say go through the Java app - you need to understand running *major* analytics on a large database will do to java - like imaging marshalling 500 million objects...
At a java systems integrated during the dot-bomb I performed some productivity analysis, and discovered that it look us just as long to create a webpage using java in 2001 as it did to create a stateless page using cics on mainframes in 1989. Of course, this is partially due to the fact that we had one person creating the entire page in cics, but required separate html, jsp, & ejb people with java due to its specialization.
You can always dismiss any heated debate as simply a result of nit-picking or personal preferences.
However, the differences here are quite substantial. And it isn't really 'mysql vs postgresql' - it's more like 'mysql vs inexpensive standards-compliant database solutions'. What really irks most experience database developers about mysql is that mysql abandoned decades of standards and standard features - while insisting that 90% of the users didn't need transactions, triggers, views, etc. That's disingenuous misinformation.
mysql still has a role out there - since it has such a wide host base and so much 'mind share'. But this is all marketing. In almost any technical comparison, Postgresql now comes out on top.
Furthermore, since postgresql is very similar to other relational databases - migration between it and oracle, db2, sql server, etc is relatively painless (unless you went overboard on stored procs, etc). This means that your investment in postgresql is fairly 'future-proof'. If on the other hand, you've gone with mysql, you will always have a more difficult migration - and may fail to get anticipated performance benefits since you are probably using the target database is a way not recommended by its vendor (joining inside application rather than inside sql, etc). This is especially true of the many mysql applications out there that believed MySQL AB when they told people that 90% of the applications didn't need transactions (!)
Of course, you can wait for mysql to catch up to everyone else in the database features area, and perhaps they'll try to become more standards compliant along the way. But that's going to be a tough slog for them, probably involving a complete rewrite. Could take quite a while, and there may be no easy transition for today's mysql apps.
Sibling rivalry? hardly
> As for parallel Oracle, it doesn't really live up to its hype. Even failover clustering on Oracle
> sucks (I'm speaking from 2 years ago, so it may have improved - however, people were using Oracle
> for mission-critical applications 2 years ago, so I think my argument still stands).
Well, oracle ops/rac has always been an extremely complex product - one that most folks have avoided for good reasons IMHO. But that's not what I'm talking about here - I'm just talking plain/vanilla partitioning & parallelism. Well, the parallelism comes free with their standard & higher packages, you pay an extra $15k or so for partitioning. But it's very simple & easy to use, and most oracle applications these days take advantage of it. It's one of the chief reasons to use oracle these days, since that part of the product really sings.
> I agree that for VERY LARGE data sets, PostgreSQL still lacks, but most of the industry
> isn't working with VERY LARGE sets -- that's basically a niche market.
The only reason that most people aren't using very large volumes of data - is that they haven't yet figured out the value of analytics and how to preprocess data. For those that do understand this what data can do know that a small amount of transactional data will balloon in size once you set it up for analytical purposes. So, that 5 gbytes of data in your transactional database can easily consume 100+ gbytes in a warehouse or data mart.
Why so large? You've performed heavy transformations on the data to cleanse, integrate, summarize, and cleanse it. Then you kept every single version so that you have a complete historical recond. Once you've done this the data may be huge - but now you can finally start answering the basic business questions with it.
And maybe get into that profitable niche - where you're competing with companies that know exactly where they're making & loosing money...
> PostgreSQL supports union-all views.
I didn't think postgresql allowed inserts to the view itself though. If it doesn't, then you'll have a much more complex application - since it always needs to know which table to insert to.
> For (1) and (2), I've never seen it. I worked w/ Travelocity and Cheaptickets.com and numerous
> other websites at EDS, and none of them used those features. Most of them were simply
> multiprocessor CPU boxes with lots of memory. I'm sure there are several cases where it's
> needed, but I don't think it's as ubiquitous as you indicate.
No, not ubiquitious. But it has been common in data warehousing now for almost ten years. Teradata then Informix became famous for their parallelism & partitioning capabilities based on it by mid-90s. Outside of data warehousing, these capabilities are commonly used in any large reporting systems, (r)olap, fraud detection, any scoring systems (especially balanced scorecard systems), clickstream analysis, etc.
The main reason to avoid the clustering form of parallelism (used in teradata, informix, and db2) is that the database licensing can get expensive. The main reason to avoid some of the parallelism capabilities within oracle is that the database AND hardware can get expensive. But that still leaves you with several options, take db2 for example:
- spend $50k (list) on a fast 4-way
- spend $30k (list) on db2 workgroup edition
- run parallel queries
- cluster your data with multi-dimensional clustering and/or union-all views.
A solution like this is about twice as expensive to purchase as postgresql but no extra cost over a plain commercial solution. And loads data at speeds like 50,000 rows / second - and leverages both parallelism and partitioning in query responses.
Neither Postgresql nor mysql can match the performance of that solution without relying upon multiple machines and manual partitioning. Both the labor and hardware costs of this alternative approach far outstrip the database licensing cost of using oracle or db2.
Basically, anyone who isn't leveraging these capabilities (and other similar ones) in large commercial databases these days either can't afford to change a legacy application, doesn't have the (relatively simple) database skills to pull it off, or really should be using postgresql...
And of course there are good reasons to use postgresql in this space - say you've got a start-up and can't afford the initial commercial licensing investment. That's fine, we just shouldn't kid anyone that postgresql at the high-end is very competitive (yet).
Postgresql is cool, but it isn't ready to compete directly with Oracle or DB2 on large databases yet.
For example, lets say you've got a large reporting application...
1. DB2 can leverage all CPUs on a single CPU - and split the workload for a query across 2,4,8 or more CPUs.
2. you can partition data across multiple servers. This allows you to spread a single 400 gbyte table across a dozen fast 2-4 way servers. This allows you to leverage cheaper hardware (commodity servers vs sun e10ks), and with relatively low cost be able to throw 40 cpus at a query.
3. you can also use multi-dimensional clustering or union-all views (similar to Oracle partitioning). This allows you to avoid scanning data that isn't in the partition you're interested in - often dropping 95% of the workload.
Note that all three of the above can be used in conjunction - so you can create a database with 40+ CPUs that allows you to focus on just the 20 million rows of the 400 million in that table. Postgresql (or mysql) on the other hand will be slogging through all 400 million rows on a 4-way. No comparison whatsoever in performance at this level. They'll eventually get there, but they've got a long way to go.
Of course, most people don't have this kind of performance-challenge, but most of this capability is useful even at the 10 gbyte database size. In the meanwhile, postgresql is a great little database for quite a few applications: and it does a good job of supporting ansi sql, it is generally simple to port from postgresql to oracle, db2, etc.
> MySQL is definitely ready for heavy loads
heavy transactional read loads for non-critical apps perhaps.
- Not heavy DSS/OLAP read loads though (where indexes don't work well and you want partitioning to bypass 95% of your rows). See Oracle, Informix & DB2 to see how this is done and the results it achieves.
- Haven't seen a proper benchmark but antecdotal evidence points to problems that MySQL has scaling to meet much write traffic. Postgresql, Firebird, etc on the inexpensive/free side appear to be better choices for this kinds of applications.
- Aren't online backups unavailable except through separately-licensed (and expensive) products?
- Then you've got the entire managability issue - on larger projects in which you desperately want the kind of functionality that MySQL AB has claimed that 95% of database applications don't need and which they've failed to support well: like database-enforced data quality constraints (referential, uniqueness, and check constraint declaratives). Add to that the lack of flexibility that comes from various missing features like views & stored procedures. Add to that the problems porting their non-standard SQL. Lastly, add to all of the above their massive list of exception-handling problems - in which errors silently fail.
Nah, MySQL is a nice little database. But unless 'heavy loads' means non-critical, read-only, index-oriented loads - I think that there are about a dozen better options available.
Oh yeah, and no - cloudscape isn't a competitor for mysql in general. They each bring different strengths to the table.
However, Oracle is free to change their licensing once again.
Remember, it was just a few years ago that Oracle introduced, and then was forced to abandon, the "Power Unit". According to that licensing schema you paid $15-100 / Power Unit to license their product (depending on version, year, etc).
A power unit was a mhz, so for example:
- single server with 2x400 mhz CPUs could cost $100*2*400 = $80,000.
On the other hand, if they were still using this today, you could be priced for a fast four-way:
$100 * 4 CPUs * 3000mhz= $1,200,000
The only reason that they backed down from this pricing was that SQL Server was eating their lunch. In fact, their greed is the main reason sql server gained so much market share around 1999-2002.
So, anyhow they aren't charging for hyper-threading today - but if they think that they can get away with it in the future they certainly will do so. Luckily, between SQL Server , postgresql, and mysql at the low-end and DB2 at the high-end Oracle's not in a good position to raise their rates any time soon.