> Science has nothing to say about any concept of God at all. > This being said, science clearly does conflict with his concept > of the origin of the world and of humans as a whole.
Right - as Galileo, and many other early scientists discovered.
Seriously, the current opposition of the fundamentalists to evolution is just the most recent battle in a long war in which religion has had to constantly give up ground for four hundred years.
The best response to Intelligent Design is probably not reason - it's lost on too many of its adherents. Redicule will probably work better - along the lines of the theory of Intelligent Gravity or the Flying Spaghetti Monster creator.
> There are quite a few people in the world who attack Christians for being ignorant of science, then go > and attack Christianity without having made any attempt to understand it. Providentially, I'm both a > physicist and a Christian.
Understand it? there is no simple "understanding of it" that is possible. This is clearly demonstrated by the facts that:
1. so many "followers of the book" are quite eager to kill one another over differrences in their interpretation of it
2. so many christian religious schools spend so much of their time learning how to interpret minor parts of the bible in order to support their particular sect
3. there is any value in graduate studies in christian theology - if the book was "understandable" and not subject to so much interpretation then it would read like a printer repair manual.
Back to your post: > as is clearly shown by Peter's dream in Acts.
Beyond the question of whether or not the thousands of christian, jewish, and islamic sects would agree with you in your interpretation...please, if there is a god that is omnipotent and omniscient I would sincerely hope that he would communicate a little more clearly than via one person's dreams from 2,000 years ago. Heck, it sounds like something out of a Diskworld novel.
> I mean, I can't imagine a storage requirement that large that you can build in a distributed model that > would beat on price per GB an EMC or Hitachi or IBM or whomever SAN solution. The administration and DR > costs alone for something like this would be astronomical.
This is exactly what I was thinking.
Look at it this way - lets say you spend $100k on a small but extensible storage array. Probably 90% of this cash would be paying for hard drives - a cost you'll have to spend anyway. Not sure of current prices, but $100k is something like 15 TB of fast disk in a raid5 configuration. Side benefits: 1. this is a capital investment - that can be written off by your company. Assume that this is the same as a 30% discount, which ends up costing you $70k. 2. the cost will be probably be paid in a lease stream across five years. Now, you're down to about $15k / year. 3. the cost includes support and replacement of defective equipment 4. it also includes a variety of interfaces, the ability to share disks between multiple hosts, dual-controllers to each array, etc, etc.
Ok, now compare this against assembling this yourself. Dealing with various vendors, working out firmware issues, working out performance-tuning strategies, etc, etc, etc. It could easily take you months to provide the same amount of well-tested, out-of-the-box functionality that this product has.
And you still have to buy the disk.
I'm not a storage expert, but I'd take a very close look at a commercial solution. It's probably cheaper in the long-term.
I'm not a huge fan of row locking and the associated lock types and escalations.
However, I work with db2 daily, and never really run into any problems with it:
- from a performance perspective it doesn't matter - db2 usually sets the record for transactional performance in spite of using row-locks, and it currently has it with something like 2x the speed of oracle. (www.tpc.org)
- for data warehousing applications (what I do mostly these days), it really doesn't matter since most operations aren't transactional or are serial anyway.
- for anything that's medium to small it doesn't really matter
For most database configurations it's merely a matter of setting a few locking parameters:
- how long to allow waits to last before you fail them
- how much space to dedicate to holding locks
- how much space to dedicate to holding locks for a single process
Having said this, there are situations where it is a real pain in the butt - usually porting extremely high-performance applications from oracle to db2 where you can run into locking challenges. Then you've got to look at the application. The only time I've run into this problem was when transactional ddl was being run within a load that also consisted of a high-volume of inserts to a low-speed table format (MDC) while massive selects were taking place. That was tough.
On the flip side:
- online backups & recoveries of db2 are extremely simple and reliable compared to oracle, and I assume some of this has to do with the extra locations that data is in
- and you never run into problems with long-running selects unable to find all their data.
Bottom line (my opinion): mvcc is simpler to work with for developers, but row-locking is probably simpler for product engineers and admins. Neither seems much better than the other in my experience.
I've run a sql server on a variety of apps, the latest one was a search engine. And it ran surprisingly well on small hardware - something like 4-way HP servers running around 700 mhz along with 120 gbyte database.
Anyhow, stability wasn't really a problem - once I got one of the databases up: I was invited in after the prior staff was fired for trying to deliberately bankrupt the company (long story). The main database was inoperable because it was using replication, had filled the logs, and some service had crashed. Working with SQL Server support took forever to fix the problem. They only had 2-3 people that could really figure it out.
My biggest complaints about SQL Server:
1. too much functionality is GUI-driven, for example:
- in order to promote DTS packages from dev to test to prod - you've got to recreate them from scratch on each server. There are work-arounds, but they are horrid.
- difficult to admin from command-line, had to use citrix remotely over dial-up line (that *sucked*)
2. stored procs in sql server are very easy to write, but have almost no exception handling
3. other product dependencies are sometimes horrific:
- exchange for emailing alerts from the database
- microsoft queue manager (can't remember exact name)
4. lacks a simple clustering/partitioning solution like oracle, db2, or informix.
5. cost
- most of the configurations we had cost upwards of $100k to license, whereas I could have gotten
similar performance out of oracle or db2 for a third of that
6. microsoft viral activities
- in order to get best prices on products, there was a benefit to having microsoft certification in-house. These people then ended-up with a microsoft-career-plan, in which they had their own agenda to get more microsoft cruft in-house. They wanted some of it in order to practice to pass the next set of exams, they wanted it for their resume, etc.
- so, bringing in any non-microsoft was a pain, and avoiding a massive microsoft build-up was difficult
In the end I ripped out quite a lot of the sql server add-ons (exchange, msqueue-thing, dts, etc) and replaced them with python running under cygwin. It made life unbelievably easier. In general I like sql server for puttering around with - creating quick prototypes, etc. But for anything in product, I loathe it.
two reasons to not use a different layer than stored procs: 1. some layers just don't work (EJB), and extra layers are always extra work to implement. This
includes stored procedures. 2. In spite of this, stored procedures just tend to work. Probably the main reason is that the same person who manages the data also manages the data's API:
- the dba should be the expert at sql, whereas many developers are barely sql-literate. When the
SQL is managed by a application/persistance layer you still end up with it spread all over.
- when a new technology is introduces that can't easily leverage the application or application
persistance layer, then it has to talk straight to the database. It's great that at least they
have that option. And if you've got a stored procedure front-end to the data, you're completely
set.
- the dba is in the best position to modify the database schema (due to performance, authorization,
etc) reasons - while encapsulating that change so that it doesn't impact the application layer.
I know there are exceptions to notion that the dba should be the most skilled sql user in a given shop, but this is generally true. Those companies that define dbas as backup-tenders that never use sql really need to get out of IT altogether.
Also, I'm not saying that writing stored procedures is a lot of fun - it isn't given the relatively primitive languages you've got to use. But for a very simple & resilient CRUD interface to the data, it can be excellent. Personally, though I usually try to just use views. Much less encapsulation, but much easier to implement. I only go to stored procedures when the development team really can't be trusted to handle queries at all, or there will be multiple apps writing to a single database.
I agree with you that mysql isn't riding the wave of popularity on slashdot that it used to three years ago. But are the issues with msyql overstated by those critical of it? Well, given the popularity of the product and the spin that the company has created, probably not in my opinion:
1. Regarding postgresql fans who move on to new complaints as quickly as mysql addresses old ones: I think that many people out there want to make sure that the community is informed that mysql had a *long* ways to go in order to be a standards-compliant database solution a few years ago. They've made great progress, but are still pretty dodgy about the outstanding issues - like insisting that accepting invalid dates is really ok behavior, etc, etc.
They'll get to the point in which the only issues people have with them are the problems with their dual-licensing, the problems inherent in licensing critical infructure pieces like Innodb, etc. If by that time they also have very cool functionality not found in postgresql - then I think most people will be completely cool with mysql.
2. Regarding MySQL's quality & features being "good enough": well, I doubt that many people care what database you use - but they do care that MySQL AB has engaged in a disinformation campaign to give their lack of basic features some coverage. Keep in mind that what they were missing weren't contraversial database features - they were the basics. Nobody really argues whether or not transactions are needed - except MySQL AB a few years ago. And in case you aren't a database expert, this is analogous to a new company with a feature-poor product aruing that: a. nobody needs built-in xUnit test harnesses like PyUnix, Junit, VBunit, etc b. nobody needs the try/except exception management mechanism c. nobody needs a firewall when they install a broadband modem d. nobody needs backups - just use raid e. nobody needs to patch their software, just keep backups, er raid All of the above are wrong - and so is the argument that "nobody needs transactions" or "nobody needs views". And just like the above statements would get a vendor some serious criticism if they made them, so MySQL AB has earned itself quite a lot of criticsm with similar statements.
3. Regarding "Yes, I've had problems, of course I have. You will with any tool": I run business critical databases. In nineteen years of developing, adminstering, and generally managing relational databases - I really can't think of a *single* time I've had a corrupt database. I've lost indexes, and had to rebuild them. I've lost the backplane on a raid controller, and had to restore from tape, etc, etc. But I really can't remember *ever* dealing with a corrupt database. I probably have, but have just lost those memories due to old age, or some kind of repression.
And professional dbas tend to get fired when their databases are corrupt. It just isn't ok when it comes to valuable data. In your situation - with a journal about your bike trips - although it is undoubtably a cool project, it probably isn't worth a a million + dollars, right? Ok, there's the difference - if your job, your career, your company is on the line - you do things in such a way that this kind of problem just doesn't happen. Again, this is why so many people have been critical of mysql: the company has defended the lack of features to prevent this kind of corruption. And there really is no defense.
Fyi, as far as my postgresql sympathies go - I've used it on just one project a few years ago. I keep in the loop since I plan to use it again in the future. But I'm hardly a postgresql fanboy, these days I'm primarily using db2.
> If you are going to repeat a computer industry myth at least get it right
Good nitpicking - but on going back and looking up the history of dr, it appears that the story that he was flying is only a little more credible than the story that he was sailing.
Anyway, I had forgotten about Gary's history. The way that he built up a very important early company, was a genuine innovator, but then completely bypassed is probably fairly common. Though maybe not on such a dramatic scale.
I was a heavy user of DR DOS when Microsoft was struggling to close the gap between ms dos 4.1 & dr dos 5.0. And got to watch first hand as Microsoft killed a superior product.
> And wasn't DR DOS originally owned by Caldera...? > Which turned into...SCO!
No, DR DOS was originally owned by Digital Research. These were the guys that IBM originally was going to buy their dos from, but their CEO at the time blew off IBM and went sailing instead(!). He was fired soon thereafter.
Anyhow, DR DOS 5 was a fine product - *far* better than MS or PC DOS. It was a completely compatible replacement to DR DOS that worked great with windows. If I remember correctly, it also included a very cool disk cache and set of memory management utilities. Anyhow, in reaction to its reviews & success, Microsoft:
- upgraded its MS DOS from 4.1 (a horrible product) to 5 (a reasonable one)
- dropped price for MS DOS from over $100 to something like $19
- generated fake compatibility error messages that DR DOS users would get when using Microsoft applications
- etc, etc, etc
Microsoft never did release a dos as good as DR DOS - with its conditional config.sys lines, online command help, etc, etc. But it did kill the product through illegal competition. Eventually, Caldera bought it out - just for the opportunity to sue microsoft over it. And won.
> True but not relevant. People use Excel for graphing only because it's there in front of them and > they don't know any better. If you want high quality flexible format graphs, go get a graphing tool. > And to the poster who complained about extending trendlines and stuff like that: don't confuse data > analysis with creating graphs. Get a real analysis tool, like MatLab or Regress+ or LabFit or aNova, > do your curve fits and error analysis, then plot the results.
Wow, your comments are so wrong that I almost wonder if you're a troll. Just try rolling out open office with the argument that missing features and capabilities that office people are using can be found in matlab, and you'll find that: 1. typical office users that require simple charting won't use matlab, and in fact are horrified by the
notion of having to learn a serious piece of software for a relatively simple function. 2. your office replacement pilot will fail 3. your next job will be running the leaf blower in the parking lot
Seriously, this is simple functionality that tons of people use. It needs to be better.
> Most users do not need to worry about any upgrade path to Oracle. Oracle cannot take away MySQL. MySQL is GPLed and we will always have the code.
no: mysql still has a ton of work to do in order to completely close its functionality gap with postgesql, let alone oracle/db2/sql server. You just leave behind the GPL'd code and what have you got? A complex system that uses another complex product (innodb). Who's going to move that large codebase forward? Database engine code is very complex, and not at all glamorous. Finding good developers to work for free won't be easy.
> However, Oracle would be dumb (as would MS, IBM) to think that they could switch a small to medium site to an expensive DB server costing $1,000's per processor.
I agree with you that the SMB market is more cost-competitive than the large enterprise market. But paying $5k / CPU isn't really that bad - given that the hardware (for a 4-way) costs more than that anyway (all things included). Plus, many licenses are cheaper than this.
> IMO, there is always going to be a nice market for the OSS DB's such as MySQL and PostgreSQL.
sure
> IME, the only reason to really use one of the paid-for databases is for some very expensive financial type applications where you want the support/reputation.
Depends on what you're doing. I'm analyzing security data - with tables of hundreds of millions of rows. My db2 license cost was just a fraction of the cost of the hardware. Getting the same speed out of mysql would require a *farm* of similar servers and would have sent the total server cost through the roof.
> Nobody outside of Oracle has any idea what their plans are for Inno. Pretty hard to call it a good/bad bet, given this.
Right, after all Larry Ellison & Oracle might have bought Innodb in order to both:
1. improve a competitor's product (mysql)
2. slash their own throats by cutting their primary revenue stream from the oracle database
Could be. Wouldn't be impossible. You never know. Better just wait and see. Cross our fingers and hope.
and the fact that in one fell swoop they can kill a competitor would never occur to a company like Oracle with such a philanthropic reputation.
Nope. Never. Not in a million years. Not in this lifetime.
This surely isn't a very complicated thing for people to work out - just follow the Very Simple Oracle/Innodb FAQ:
1. Does Larry Ellison (Oracle CEO) do things for the good of the industry or little guys?
Answer: *Never*
2. Is there any opportunity for the Oracle DB to reuse IP within Innodb
Answer: Almost certainly not
3. Is there a trivial upgrade path from Innodb/Mysql to Oracle
Answer: No
4. Ok, with that out of the way - what possible reason would oracle have to acquire Innodb?
Answer: obviously to cripple an opponent by robbing it of critical infrastructure - through licensing changes
5. How will this benefit OSS Customers?
Answer: not in any way imaginable
It's like this: Oracle is seeing customers moving to mysql for the small stuff. But they make money on the small stuff too - and even if oracle is superior to mysql in 7 ways out of 10, they're loosing cash to mysql. This move completely kills all mysql momentum in the market place:
- Mysql now has to dedicate resources to finding an innodb replacement. Good luck - there are no commodity persistant layers that support transactions like Innodb.
- Oracle can renew the license agreement at a much higher price, thereby winning short-term revenue at MySQL's expense!
- MySQL was talking about a big-enterprise role just down the road (before they got wind of this buy out and started acting meek a couple of weeks ago). Much of what they're missing is really functionality that should go into Innodb - Heikki Tuuri (innodb creator) has often stated that "partitioning for all table types will probably be available in 2006 or 2007". If Innodb built that they could start capturing a big chunk of the oracle revenue. This threat is now dead - with the only other strong competitors DB2 and SQL Server.
- In spite of being GPL, good luck on finding another crew of programmers that specialize in relational database engines to this product up. The few that exist in the open source world seem to all work at postgresql.
So yeah, Larry has MySQL by the balls right now. MySQL AB was probably looking forward to a big GA announcement for v5 next month - but there is no good publicity for MySQL in the foreseeable future now.
I used to like imdb, but have gradually grown tired of it:
- the interface has become too clutered with advertising
- the whole community-built, then commercialized for the profit of a couple is disheartening
- the recent reviews are *so* polluted with paid-for movie-industry propaganda or are created
by fourteen year old that I've got little taste in common with
So, here's a plug for something better: www.allmovie.com & www.allmusic.com. Why are they better, well:
- they are commercial, but they started that way, didn't exploit free contributions
- the categorization is far better
- the reviews are often fantastic
- it's hard for many people to objectively look at an alternative - if you don't think you'll
ever like anything but imdb - then check out www.allmusic.com. That site is quite amazing.
> Freer than GPL'd free software? > Oh, you mean free like in "free to deny everybody the right to redistribute it"?
Freer as in "not encumbered by complex dual-licensing with bizarre "linking" gpl definitions that require lawyers to determine whether or not your clients require licensing".
Freer as in "not owned by a for-profit company that has a history of changing its licensing to beging making money off its popularity"
Freer as in "doesn't rely on a product owned by Oracle & Larry Ellison for vital functionality"
I'd call that three good reasons why future costs of mysql are pretty unpredictable.
> There are some serious downsides too. Among them:
yeah, but mysql is going to face most of these issues with any data storage they attempt to license: there just isn't a commodity market for plugable transaction engines.
So, they'll want to replace innodb with something. But what? Assuming that the antiquated SAPDB is just a heap of scary code is probably safe. What else? BDB is probably a dead-end - way too primitive. That brings us back to postgresql, firebird, and sqllite...
and it might cause breaks with backwards compatibiity - but when the compatibility is with broken old stuff that should never have been provided anyway (accepting invalid dates, etc), then that's not the end of the world. Heck, innodb & myisam are not 100% compatible anyway.
> So, he's given you a fast and stable database for free. Or what part of what you just said contradicted that?
> The way I remember it, free software is a lot about contribution. So if you're > not contributing code to MySQL or sending in bug fixes, shut up and be glad > they're giving you a free database. If you don't like it then don't use it, > it's really very simple. But if you're not a contributor, you really have no > platform from which to moralize.
1. why would I contribute code to a dual-licensed product for someone else to make money on, without any compensation? 2. The product isn't free - mysql ab's position on linking is bizarre and contradicts the gpl faq. Their license has changed over time. There's no reason to assume it won't become increasingly more difficult to avoid paying a fee. 3. The current cost is $600 / year - likely to go up now that oracle owns innodb 4. Many developers have unfortunately embedded mysql in otherwise good products - which taints them with possible quality errors (silent errors, truncations, etc) as well as confusing future costs. 5. The company has been involved in misinforming the public about database best practices in order to cover their deficiencies. Telling programmers to write their transaction logic is like telling programmers that built-in testing is bad, they should just eye-ball the data. And it completely opens them up to criticism. 6. I often bump into the product in commercial settings where developers have used the database, then expect me to pick up support for it. First thing I do is insist that the database be moved to just about any other product. What a pain in the ass!
The gist of your lame argument is that you can't criticize something unless you're personally involved. What garbage. That's like saying we can't say that microsoft is wrong in trying to implement DRM unless we're employees of the company. bleh.
> This guy has given you a fast, stable database, that you can run and use for > free as you please. And now because he has committed himself to making a > version for SCO, you feel entitled to giving him crap? Okay... the Linux d00ds > of today really need to try working for a living sometime.
ah, no - more like:
This guy has played a bait & switch with a database - at first giving it away for free, then changing the licensing (using linking definitions that contradict GPL's FAQ) to hook users in.
Then he defended bizarre deficiencies in the product by arguing that nobody needs transactions, views, stored procs, triggers, accurate exceptions, referential integrity, etc anyway.
Then he gets lucky and licenses all the most valuable parts of the current product from another company (innodb).
Then he cuts a deal with SCO to make a little cash - which helps SCO also stay in business and continue to try to destroy the GPL.
Then Oracle buys Innodb - revealing that the mysql now is just an empty husk with nothing to offer. Leaving a lot of database developers out there saying - well, duh - tell me once again why you aren't using firebird, ingres, postgresql, sqlite?
> Time to fork Innobase right? Programmers, are you listening?
Not likely this isn't simple code, this would take a long time to get up to speed on and really understand. Let alone enhance. Mysql wasn't able to write a transaction engine on their own - they had to licese one. Don't you think they would have written their own if they could?
But here's a great solution: mysql could use postgresql for its transaction layer. Imagine the benefits:
- no licensing costs to pass on to mysql customers
- improved query optimization
- eliminates many of the annoying silent errors (truncations, conversions, etc)
- should eliminate the postgresql-vs-mysql arguments
- mysql could leverage from open-source momentum in postgresql
- might improve mysql portability
- might even allow users to easily port back & forth between postgresql & mysql
- postgresql can't be purchased away
I'm pretty sure this would be the easiest plug-in replacement for innodb. On the other hand...doesn't SQLite now support transactions & MVCC? And along these lines, could mysql pick up greater scalability by using db2 & oracle as storage layers as well?
> Although InnoDB is quite a niece piece of work, I wouldn't call it a key piece of the MySQL server > software. It is just one of the *many* storage backends supported by MySQL, and it's not by far > the most used (99% of the MySQL installs i've seen only use the internally developped MyISAM > storage engine which btw is the default one...
I think that's primarily due to all the legacy 3.* mysql databases out there: not because people are running 4.01 and want to keep using myisam.
There are legitimate times to use myisam, but aside from read-only reporting (which mysql isn't very good at), or very high-volume read-mostly content management that's about it. Backends for tools like bugzilla, for wikis, etc should be on innodb:
- it's easier to develop the app (don't have to reinvent transactions)
- the application code is more portable
- you avoid data corruption problems problems with buggy do-it-yourself transaction code
- you get to rely on declarative referential integrity to help ensure that 100% of the data in the database complies with the rules of the model
> And btw, people who need transactions and advanced features tend to use postgresql instead of mysql+innodb...
true - anyone who knows enough about databases to know why they should be using transactions also knows why they should be using views, stored procedures (occasionally), triggers (occasionally), and have an optimizer capable of joining 5 tables without a performance hit.
If mysql looses innodb they are in very deep trouble. Before they licensed innodb, MySQL AB insisted that:
- 99% of the programmers didn't need transactions
- that "real programmers" could easily write that code themselves in the app layer
- that all quality checks (pk/fk constraints) belonged in the app layer anyway Once they licensed innodb they changed that tune completely
- declaring themselves an "Enterprise Database"
- the only database people needed
- bragged about their fast paced development (even tho it was purchasing not development)
- buried all their previous comments about transactions not being necessary
So, now that they've been admitting that transactions are vital - won't they look stupid loosing them? At that point, why put *any* database on mysql? Postgresql/Firebird/SQLite are all *freer* anyway. And it isn't like MySQL is going to suddenly come up with a replacement to Innodb - that's the code they couldn't write themselves before, it's the most complex code in mysql, and they apparently don't have people capable of writing it.
> The article you're responding to is about MySQL 5.0, in which that misfeature can be disabled. (It's a > fair complaint, but worth pointing out that it's been addressed. You may as well complain that MySQL > doesn't have stored procedures.)
Not really - mysql manages to get into the v5.0 into the press every month with people making the exact same claim. However, it is not GA, not production, just beta. Once they actually get the product into production and it works, then the only relevant thing about this issue regards the credibility of a company that would put out such a product in the first place.
> I don't know if they've fixed that, but really, how often have you incorrectly installed the system > so it doesn't support innodb without immediately discovering that?
How would you immediately discover that? I can't remember anyone ever in twenty years of working with databases begin testing rollback functionality on a database. Even with mysql - nobody does that.
>> >> - etc > Please elaborate. "Etc." is FUD.
heh, not in this case. how about this abbreviated list: - primary key behavior is non-ansi (implicit pks, and fks that require explicit pks) - adding an index to an innodb table causes table to be rebuilt - which can fail if you don't have sufficient space for 2 copies of the table - no way to manually adjust identity column values - suggestion from mysql is to add dummy rows (!) - replication command LOAD TABLE FROM MASTER requires you to flip the table between innodb and myisam - stats - i don't think mysql gathers stats for any columns besides indexes - last year mysql's claim to fame for performance was 800 inserts / second. This was at the same time db2 is hitting 60,000 *transactions* a second - you can check on the gotchas list for quite a few more
> > [the reason for using MySQL] can't be cost > You may be surprised how much of a difference free is over a few grand for a lot of companies. > Especially when experimenting with some new thing. In addition to being a difference in amount, free > is a difference in kind.
Then i'd suggest a category shift in cost - go with genuinely free - something like SQLite or Postgresql. Both free, both high-quality products. No, they aren't up to db2/oracle/informix quality yet, but nevertheless are free of the bizarre quality and standardization problems in mysql.
> That's rubbish. MySQL is gpl'd, and for a gigantic number of uses that means zero cost, zero legal > troubles, forever.
It is gpled
- with a license requirement with a dozen convenient exceptions, that can be easily revoked later
- based upon a product subject to license renewal owned by Oracle (innodb)
- with client linkage definitions (socket communication with client is linking?) that is a contradiction what is stated in the GPL
- with recommendations to talk to them if you're not sure, or to just license if you're not sure
> The last time we priced Oracle was a couple of years ago, but the pricing was ridiculous. > And on top of paying the money for the software, and the support, you have to manage licences. > One of the nicest things to me about moving to open source software was that the software authors > *want* you to install and use it. There's no more barrier than "apt-get install ". Not having > anything in the way between you and installing the software saves real money, even if the software > weren't zero-cost. In an emergency you're trying to set up a new server, you don't want to be > hunting for a license key or faxing for an installation key or validating something over the phone. >(I've never installed Oracle, maybe it's less of a headache than dozens of other pieces of proprietary > software I've worked with.)
i partially agree with you here: 1. Oracle's pricing has come down hugely over
> Are you kidding? Have you ever priced out a real Oracle license for a web-based application? (IE > unlimited users or CPU basaed, which is what Oracle requires for anything that allows the general > Internet to use it).
You're right - i was thinking of other applications. I shouldn't have since the parent had mentioned a million hits.
Not positive on what the current unlimited users oracle license is for two cpus. But the license cost goes up steeply for unlimited users. For DB2 I think it the cheapest unlimited user license is probably $7500 / CPU (list). Even assuming a substantial discount, mysql will be cheaper.
Slashdot Mirror
> Science has nothing to say about any concept of God at all.
> This being said, science clearly does conflict with his concept
> of the origin of the world and of humans as a whole.
Right - as Galileo, and many other early scientists discovered.
Seriously, the current opposition of the fundamentalists to evolution is just the most recent battle in a long war in which religion has had to constantly give up ground for four hundred years.
The best response to Intelligent Design is probably not reason - it's lost on too many of its adherents. Redicule will probably work better - along the lines of the theory of Intelligent Gravity or the Flying Spaghetti Monster creator.
> There are quite a few people in the world who attack Christians for being ignorant of science, then go
> and attack Christianity without having made any attempt to understand it. Providentially, I'm both a
> physicist and a Christian.
Understand it? there is no simple "understanding of it" that is possible. This is clearly demonstrated by the facts that:
1. so many "followers of the book" are quite eager to kill one another over differrences in their interpretation of it
2. so many christian religious schools spend so much of their time learning how to interpret minor parts of the bible in order to support their particular sect
3. there is any value in graduate studies in christian theology - if the book was "understandable" and not subject to so much interpretation then it would read like a printer repair manual.
Back to your post:
> as is clearly shown by Peter's dream in Acts.
Beyond the question of whether or not the thousands of christian, jewish, and islamic sects would agree with you in your interpretation...please, if there is a god that is omnipotent and omniscient I would sincerely hope that he would communicate a little more clearly than via one person's dreams from 2,000 years ago. Heck, it sounds like something out of a Diskworld novel.
> Part of their hypocrisy is that they do not attack all science, but only certain parts that they disagree with.
hmmm...
use the part of the bible that says homosexuality is bad, ignore the part that says wearing two different types of cloth is bad
use the part of the bible that says witchcraft is bad, ignore the part that says not to eat shellfish
etc, etc, etc
> I mean, I can't imagine a storage requirement that large that you can build in a distributed model that
> would beat on price per GB an EMC or Hitachi or IBM or whomever SAN solution. The administration and DR
> costs alone for something like this would be astronomical.
This is exactly what I was thinking.
Look at it this way - lets say you spend $100k on a small but extensible storage array. Probably 90% of this cash would be paying for hard drives - a cost you'll have to spend anyway. Not sure of current prices, but $100k is something like 15 TB of fast disk in a raid5 configuration. Side benefits:
1. this is a capital investment - that can be written off by your company. Assume that this is the same as a 30% discount, which ends up costing you $70k.
2. the cost will be probably be paid in a lease stream across five years. Now, you're down to about $15k / year.
3. the cost includes support and replacement of defective equipment
4. it also includes a variety of interfaces, the ability to share disks between multiple hosts, dual-controllers to each array, etc, etc.
Ok, now compare this against assembling this yourself. Dealing with various vendors, working out firmware issues, working out performance-tuning strategies, etc, etc, etc. It could easily take you months to provide the same amount of well-tested, out-of-the-box functionality that this product has.
And you still have to buy the disk.
I'm not a storage expert, but I'd take a very close look at a commercial solution. It's probably cheaper in the long-term.
I'm not a huge fan of row locking and the associated lock types and escalations.
However, I work with db2 daily, and never really run into any problems with it:
- from a performance perspective it doesn't matter - db2 usually sets the record for transactional performance in spite of using row-locks, and it currently has it with something like 2x the speed of oracle. (www.tpc.org)
- for data warehousing applications (what I do mostly these days), it really doesn't matter since most operations aren't transactional or are serial anyway.
- for anything that's medium to small it doesn't really matter
For most database configurations it's merely a matter of setting a few locking parameters:
- how long to allow waits to last before you fail them
- how much space to dedicate to holding locks
- how much space to dedicate to holding locks for a single process
Having said this, there are situations where it is a real pain in the butt - usually porting extremely high-performance applications from oracle to db2 where you can run into locking challenges. Then you've got to look at the application. The only time I've run into this problem was when transactional ddl was being run within a load that also consisted of a high-volume of inserts to a low-speed table format (MDC) while massive selects were taking place. That was tough.
On the flip side:
- online backups & recoveries of db2 are extremely simple and reliable compared to oracle, and I assume some of this has to do with the extra locations that data is in
- and you never run into problems with long-running selects unable to find all their data.
Bottom line (my opinion): mvcc is simpler to work with for developers, but row-locking is probably simpler for product engineers and admins. Neither seems much better than the other in my experience.
I've run a sql server on a variety of apps, the latest one was a search engine. And it ran surprisingly well on small hardware - something like 4-way HP servers running around 700 mhz along with 120 gbyte database.
Anyhow, stability wasn't really a problem - once I got one of the databases up: I was invited in after the prior staff was fired for trying to deliberately bankrupt the company (long story). The main database was inoperable because it was using replication, had filled the logs, and some service had crashed. Working with SQL Server support took forever to fix the problem. They only had 2-3 people that could really figure it out.
My biggest complaints about SQL Server:
1. too much functionality is GUI-driven, for example:
- in order to promote DTS packages from dev to test to prod - you've got to recreate them from scratch on each server. There are work-arounds, but they are horrid.
- difficult to admin from command-line, had to use citrix remotely over dial-up line (that *sucked*)
2. stored procs in sql server are very easy to write, but have almost no exception handling
3. other product dependencies are sometimes horrific:
- exchange for emailing alerts from the database
- microsoft queue manager (can't remember exact name)
4. lacks a simple clustering/partitioning solution like oracle, db2, or informix.
5. cost
- most of the configurations we had cost upwards of $100k to license, whereas I could have gotten
similar performance out of oracle or db2 for a third of that
6. microsoft viral activities
- in order to get best prices on products, there was a benefit to having microsoft certification in-house. These people then ended-up with a microsoft-career-plan, in which they had their own agenda to get more microsoft cruft in-house. They wanted some of it in order to practice to pass the next set of exams, they wanted it for their resume, etc.
- so, bringing in any non-microsoft was a pain, and avoiding a massive microsoft build-up was difficult
In the end I ripped out quite a lot of the sql server add-ons (exchange, msqueue-thing, dts, etc) and replaced them with python running under cygwin. It made life unbelievably easier. In general I like sql server for puttering around with - creating quick prototypes, etc. But for anything in product, I loathe it.
two reasons to not use a different layer than stored procs:
1. some layers just don't work (EJB), and extra layers are always extra work to implement. This
includes stored procedures.
2. In spite of this, stored procedures just tend to work. Probably the main reason is that the same person who manages the data also manages the data's API:
- the dba should be the expert at sql, whereas many developers are barely sql-literate. When the
SQL is managed by a application/persistance layer you still end up with it spread all over.
- when a new technology is introduces that can't easily leverage the application or application
persistance layer, then it has to talk straight to the database. It's great that at least they
have that option. And if you've got a stored procedure front-end to the data, you're completely
set.
- the dba is in the best position to modify the database schema (due to performance, authorization,
etc) reasons - while encapsulating that change so that it doesn't impact the application layer.
I know there are exceptions to notion that the dba should be the most skilled sql user in a given shop, but this is generally true. Those companies that define dbas as backup-tenders that never use sql really need to get out of IT altogether.
Also, I'm not saying that writing stored procedures is a lot of fun - it isn't given the relatively primitive languages you've got to use. But for a very simple & resilient CRUD interface to the data, it can be excellent. Personally, though I usually try to just use views. Much less encapsulation, but much easier to implement. I only go to stored procedures when the development team really can't be trusted to handle queries at all, or there will be multiple apps writing to a single database.
Neil,
I agree with you that mysql isn't riding the wave of popularity on slashdot that it used to three years ago. But are the issues with msyql overstated by those critical of it? Well, given the popularity of the product and the spin that the company has created, probably not in my opinion:
1. Regarding postgresql fans who move on to new complaints as quickly as mysql addresses old ones: I think that many people out there want to make sure that the community is informed that mysql had a *long* ways to go in order to be a standards-compliant database solution a few years ago. They've made great progress, but are still pretty dodgy about the outstanding issues - like insisting that accepting invalid dates is really ok behavior, etc, etc.
They'll get to the point in which the only issues people have with them are the problems with their dual-licensing, the problems inherent in licensing critical infructure pieces like Innodb, etc. If by that time they also have very cool functionality not found in postgresql - then I think most people will be completely cool with mysql.
2. Regarding MySQL's quality & features being "good enough": well, I doubt that many people care what database you use - but they do care that MySQL AB has engaged in a disinformation campaign to give their lack of basic features some coverage. Keep in mind that what they were missing weren't contraversial database features - they were the basics. Nobody really argues whether or not transactions are needed - except MySQL AB a few years ago. And in case you aren't a database expert, this is analogous to a new company with a feature-poor product aruing that:
a. nobody needs built-in xUnit test harnesses like PyUnix, Junit, VBunit, etc
b. nobody needs the try/except exception management mechanism
c. nobody needs a firewall when they install a broadband modem
d. nobody needs backups - just use raid
e. nobody needs to patch their software, just keep backups, er raid
All of the above are wrong - and so is the argument that "nobody needs transactions" or "nobody needs views". And just like the above statements would get a vendor some serious criticism if they made them, so MySQL AB has earned itself quite a lot of criticsm with similar statements.
3. Regarding "Yes, I've had problems, of course I have. You will with any tool": I run business critical databases. In nineteen years of developing, adminstering, and generally managing relational databases - I really can't think of a *single* time I've had a corrupt database. I've lost indexes, and had to rebuild them. I've lost the backplane on a raid controller, and had to restore from tape, etc, etc. But I really can't remember *ever* dealing with a corrupt database. I probably have, but have just lost those memories due to old age, or some kind of repression.
And professional dbas tend to get fired when their databases are corrupt. It just isn't ok when it comes to valuable data. In your situation - with a journal about your bike trips - although it is undoubtably a cool project, it probably isn't worth a a million + dollars, right? Ok, there's the difference - if your job, your career, your company is on the line - you do things in such a way that this kind of problem just doesn't happen. Again, this is why so many people have been critical of mysql: the company has defended the lack of features to prevent this kind of corruption. And there really is no defense.
Fyi, as far as my postgresql sympathies go - I've used it on just one project a few years ago. I keep in the loop since I plan to use it again in the future. But I'm hardly a postgresql fanboy, these days I'm primarily using db2.
> If you are going to repeat a computer industry myth at least get it right
Good nitpicking - but on going back and looking up the history of dr, it appears that the story that he was flying is only a little more credible than the story that he was sailing.
Anyway, I had forgotten about Gary's history. The way that he built up a very important early company, was a genuine innovator, but then completely bypassed is probably fairly common. Though maybe not on such a dramatic scale.
> That's nice - so, what you're saying is that DR DOS was a replacement to DR DOS?
use your brain: it was an obvious typo
> Also, your story about how MS-DOS beat out CPM/86 is just misinformed.
use google:
http://en.wikipedia.org/wiki/DR-DOS - provides some general history
http://www.digitalresearch.biz/HISZMSD.HTM - describes some history of the DR blowoff of ibm
I was a heavy user of DR DOS when Microsoft was struggling to close the gap between ms dos 4.1 & dr dos 5.0. And got to watch first hand as Microsoft killed a superior product.
> And wasn't DR DOS originally owned by Caldera...?
> Which turned into...SCO!
No, DR DOS was originally owned by Digital Research. These were the guys that IBM originally was going to buy their dos from, but their CEO at the time blew off IBM and went sailing instead(!). He was fired soon thereafter.
Anyhow, DR DOS 5 was a fine product - *far* better than MS or PC DOS. It was a completely compatible replacement to DR DOS that worked great with windows. If I remember correctly, it also included a very cool disk cache and set of memory management utilities. Anyhow, in reaction to its reviews & success, Microsoft:
- upgraded its MS DOS from 4.1 (a horrible product) to 5 (a reasonable one)
- dropped price for MS DOS from over $100 to something like $19
- generated fake compatibility error messages that DR DOS users would get when using Microsoft applications
- etc, etc, etc
Microsoft never did release a dos as good as DR DOS - with its conditional config.sys lines, online command help, etc, etc. But it did kill the product through illegal competition. Eventually, Caldera bought it out - just for the opportunity to sue microsoft over it. And won.
what are people using for a viseo replacement?
i think we probably use viseo more than word or excel...
> True but not relevant. People use Excel for graphing only because it's there in front of them and
> they don't know any better. If you want high quality flexible format graphs, go get a graphing tool.
> And to the poster who complained about extending trendlines and stuff like that: don't confuse data
> analysis with creating graphs. Get a real analysis tool, like MatLab or Regress+ or LabFit or aNova,
> do your curve fits and error analysis, then plot the results.
Wow, your comments are so wrong that I almost wonder if you're a troll. Just try rolling out open office with the argument that missing features and capabilities that office people are using can be found in matlab, and you'll find that:
1. typical office users that require simple charting won't use matlab, and in fact are horrified by the
notion of having to learn a serious piece of software for a relatively simple function.
2. your office replacement pilot will fail
3. your next job will be running the leaf blower in the parking lot
Seriously, this is simple functionality that tons of people use. It needs to be better.
> Most users do not need to worry about any upgrade path to Oracle. Oracle cannot take away MySQL. MySQL is GPLed and we will always have the code.
no: mysql still has a ton of work to do in order to completely close its functionality gap with postgesql, let alone oracle/db2/sql server. You just leave behind the GPL'd code and what have you got? A complex system that uses another complex product (innodb). Who's going to move that large codebase forward? Database engine code is very complex, and not at all glamorous. Finding good developers to work for free won't be easy.
> However, Oracle would be dumb (as would MS, IBM) to think that they could switch a small to medium site to an expensive DB server costing $1,000's per processor.
I agree with you that the SMB market is more cost-competitive than the large enterprise market. But paying $5k / CPU isn't really that bad - given that the hardware (for a 4-way) costs more than that anyway (all things included). Plus, many licenses are cheaper than this.
> IMO, there is always going to be a nice market for the OSS DB's such as MySQL and PostgreSQL.
sure
> IME, the only reason to really use one of the paid-for databases is for some very expensive financial type applications where you want the support/reputation.
Depends on what you're doing. I'm analyzing security data - with tables of hundreds of millions of rows. My db2 license cost was just a fraction of the cost of the hardware. Getting the same speed out of mysql would require a *farm* of similar servers and would have sent the total server cost through the roof.
> Nobody outside of Oracle has any idea what their plans are for Inno. Pretty hard to call it a good/bad bet, given this.
Right, after all Larry Ellison & Oracle might have bought Innodb in order to both:
1. improve a competitor's product (mysql)
2. slash their own throats by cutting their primary revenue stream from the oracle database
Could be.
Wouldn't be impossible.
You never know.
Better just wait and see.
Cross our fingers and hope.
and the fact that in one fell swoop they can kill a competitor would never occur to a company like Oracle with such a philanthropic reputation.
Nope.
Never.
Not in a million years.
Not in this lifetime.
This surely isn't a very complicated thing for people to work out - just follow the Very Simple Oracle/Innodb FAQ:
1. Does Larry Ellison (Oracle CEO) do things for the good of the industry or little guys?
Answer: *Never*
2. Is there any opportunity for the Oracle DB to reuse IP within Innodb
Answer: Almost certainly not
3. Is there a trivial upgrade path from Innodb/Mysql to Oracle
Answer: No
4. Ok, with that out of the way - what possible reason would oracle have to acquire Innodb?
Answer: obviously to cripple an opponent by robbing it of critical infrastructure - through licensing changes
5. How will this benefit OSS Customers?
Answer: not in any way imaginable
It's like this: Oracle is seeing customers moving to mysql for the small stuff. But they make money on the small stuff too - and even if oracle is superior to mysql in 7 ways out of 10, they're loosing cash to mysql. This move completely kills all mysql momentum in the market place:
- Mysql now has to dedicate resources to finding an innodb replacement. Good luck - there are no commodity persistant layers that support transactions like Innodb.
- Oracle can renew the license agreement at a much higher price, thereby winning short-term revenue at MySQL's expense!
- MySQL was talking about a big-enterprise role just down the road (before they got wind of this buy out and started acting meek a couple of weeks ago). Much of what they're missing is really functionality that should go into Innodb - Heikki Tuuri (innodb creator) has often stated that "partitioning for all table types will probably be available in 2006 or 2007". If Innodb built that they could start capturing a big chunk of the oracle revenue. This threat is now dead - with the only other strong competitors DB2 and SQL Server.
- In spite of being GPL, good luck on finding another crew of programmers that specialize in relational database engines to this product up. The few that exist in the open source world seem to all work at postgresql.
So yeah, Larry has MySQL by the balls right now. MySQL AB was probably looking forward to a big GA announcement for v5 next month - but there is no good publicity for MySQL in the foreseeable future now.
I used to like imdb, but have gradually grown tired of it:
- the interface has become too clutered with advertising
- the whole community-built, then commercialized for the profit of a couple is disheartening
- the recent reviews are *so* polluted with paid-for movie-industry propaganda or are created
by fourteen year old that I've got little taste in common with
So, here's a plug for something better: www.allmovie.com & www.allmusic.com. Why are they better, well:
- they are commercial, but they started that way, didn't exploit free contributions
- the categorization is far better
- the reviews are often fantastic
- it's hard for many people to objectively look at an alternative - if you don't think you'll
ever like anything but imdb - then check out www.allmusic.com. That site is quite amazing.
What I really miss is www.allbooks.com
> Freer than GPL'd free software?
> Oh, you mean free like in "free to deny everybody the right to redistribute it"?
Freer as in "not encumbered by complex dual-licensing with bizarre "linking" gpl definitions that require lawyers to determine whether or not your clients require licensing".
Freer as in "not owned by a for-profit company that has a history of changing its licensing to beging making money off its popularity"
Freer as in "doesn't rely on a product owned by Oracle & Larry Ellison for vital functionality"
I'd call that three good reasons why future costs of mysql are pretty unpredictable.
> There are some serious downsides too. Among them:
yeah, but mysql is going to face most of these issues with any data storage they attempt to license: there just isn't a commodity market for plugable transaction engines.
So, they'll want to replace innodb with something. But what? Assuming that the antiquated SAPDB is just a heap of scary code is probably safe. What else? BDB is probably a dead-end - way too primitive. That brings us back to postgresql, firebird, and sqllite...
and it might cause breaks with backwards compatibiity - but when the compatibility is with broken old stuff that should never have been provided anyway (accepting invalid dates, etc), then that's not the end of the world. Heck, innodb & myisam are not 100% compatible anyway.
> So, he's given you a fast and stable database for free. Or what part of what you just said contradicted that?
> The way I remember it, free software is a lot about contribution. So if you're
> not contributing code to MySQL or sending in bug fixes, shut up and be glad
> they're giving you a free database. If you don't like it then don't use it,
> it's really very simple. But if you're not a contributor, you really have no
> platform from which to moralize.
1. why would I contribute code to a dual-licensed product for someone else to make money on, without any compensation?
2. The product isn't free - mysql ab's position on linking is bizarre and contradicts the gpl faq. Their license has changed over time. There's no reason to assume it won't become increasingly more difficult to avoid paying a fee.
3. The current cost is $600 / year - likely to go up now that oracle owns innodb
4. Many developers have unfortunately embedded mysql in otherwise good products - which taints them with possible quality errors (silent errors, truncations, etc) as well as confusing future costs.
5. The company has been involved in misinforming the public about database best practices in order to cover their deficiencies. Telling programmers to write their transaction logic is like telling programmers that built-in testing is bad, they should just eye-ball the data. And it completely opens them up to criticism.
6. I often bump into the product in commercial settings where developers have used the database, then expect me to pick up support for it. First thing I do is insist that the database be moved to just about any other product. What a pain in the ass!
The gist of your lame argument is that you can't criticize something unless you're personally involved. What garbage. That's like saying we can't say that microsoft is wrong in trying to implement DRM unless we're employees of the company. bleh.
> This guy has given you a fast, stable database, that you can run and use for
> free as you please. And now because he has committed himself to making a
> version for SCO, you feel entitled to giving him crap? Okay... the Linux d00ds
> of today really need to try working for a living sometime.
ah, no - more like:
This guy has played a bait & switch with a database - at first giving it away for free, then changing the licensing (using linking definitions that contradict GPL's FAQ) to hook users in.
Then he defended bizarre deficiencies in the product by arguing that nobody needs transactions, views, stored procs, triggers, accurate exceptions, referential integrity, etc anyway.
Then he gets lucky and licenses all the most valuable parts of the current product from another company (innodb).
Then he cuts a deal with SCO to make a little cash - which helps SCO also stay in business and continue to try to destroy the GPL.
Then Oracle buys Innodb - revealing that the mysql now is just an empty husk with nothing to offer. Leaving a lot of database developers out there saying - well, duh - tell me once again why you aren't using firebird, ingres, postgresql, sqlite?
> Time to fork Innobase right? Programmers, are you listening?
Not likely this isn't simple code, this would take a long time to get up to speed on and really understand. Let alone enhance. Mysql wasn't able to write a transaction engine on their own - they had to licese one. Don't you think they would have written their own if they could?
But here's a great solution: mysql could use postgresql for its transaction layer. Imagine the benefits:
- no licensing costs to pass on to mysql customers
- improved query optimization
- eliminates many of the annoying silent errors (truncations, conversions, etc)
- should eliminate the postgresql-vs-mysql arguments
- mysql could leverage from open-source momentum in postgresql
- might improve mysql portability
- might even allow users to easily port back & forth between postgresql & mysql
- postgresql can't be purchased away
I'm pretty sure this would be the easiest plug-in replacement for innodb. On the other hand...doesn't SQLite now support transactions & MVCC? And along these lines, could mysql pick up greater scalability by using db2 & oracle as storage layers as well?
ken
> Although InnoDB is quite a niece piece of work, I wouldn't call it a key piece of the MySQL server ...
...
> software. It is just one of the *many* storage backends supported by MySQL, and it's not by far
> the most used (99% of the MySQL installs i've seen only use the internally developped MyISAM
> storage engine which btw is the default one
I think that's primarily due to all the legacy 3.* mysql databases out there: not because people are running 4.01 and want to keep using myisam.
There are legitimate times to use myisam, but aside from read-only reporting (which mysql isn't very good at), or very high-volume read-mostly content management that's about it. Backends for tools like bugzilla, for wikis, etc should be on innodb:
- it's easier to develop the app (don't have to reinvent transactions)
- the application code is more portable
- you avoid data corruption problems problems with buggy do-it-yourself transaction code
- you get to rely on declarative referential integrity to help ensure that 100% of the data in the database complies with the rules of the model
> And btw, people who need transactions and advanced features tend to use postgresql instead of mysql+innodb
true - anyone who knows enough about databases to know why they should be using transactions also knows why they should be using views, stored procedures (occasionally), triggers (occasionally), and have an optimizer capable of joining 5 tables without a performance hit.
If mysql looses innodb they are in very deep trouble. Before they licensed innodb, MySQL AB insisted that:
- 99% of the programmers didn't need transactions
- that "real programmers" could easily write that code themselves in the app layer
- that all quality checks (pk/fk constraints) belonged in the app layer anyway
Once they licensed innodb they changed that tune completely
- declaring themselves an "Enterprise Database"
- the only database people needed
- bragged about their fast paced development (even tho it was purchasing not development)
- buried all their previous comments about transactions not being necessary
So, now that they've been admitting that transactions are vital - won't they look stupid loosing them? At that point, why put *any* database on mysql? Postgresql/Firebird/SQLite are all *freer* anyway. And it isn't like MySQL is going to suddenly come up with a replacement to Innodb - that's the code they couldn't write themselves before, it's the most complex code in mysql, and they apparently don't have people capable of writing it.
> The article you're responding to is about MySQL 5.0, in which that misfeature can be disabled. (It's a
> fair complaint, but worth pointing out that it's been addressed. You may as well complain that MySQL
> doesn't have stored procedures.)
Not really - mysql manages to get into the v5.0 into the press every month with people making the exact same claim. However, it is not GA, not production, just beta. Once they actually get the product into production and it works, then the only relevant thing about this issue regards the credibility of a company that would put out such a product in the first place.
> I don't know if they've fixed that, but really, how often have you incorrectly installed the system
> so it doesn't support innodb without immediately discovering that?
How would you immediately discover that? I can't remember anyone ever in twenty years of working with databases begin testing rollback functionality on a database. Even with mysql - nobody does that.
>>
>> - etc
> Please elaborate. "Etc." is FUD.
heh, not in this case. how about this abbreviated list:
- primary key behavior is non-ansi (implicit pks, and fks that require explicit pks)
- adding an index to an innodb table causes table to be rebuilt - which can fail if you don't have sufficient space for 2 copies of the table
- no way to manually adjust identity column values - suggestion from mysql is to add dummy rows (!)
- replication command LOAD TABLE FROM MASTER requires you to flip the table between innodb and myisam
- stats - i don't think mysql gathers stats for any columns besides indexes
- last year mysql's claim to fame for performance was 800 inserts / second. This was at the same time db2 is hitting 60,000 *transactions* a second
- you can check on the gotchas list for quite a few more
> > [the reason for using MySQL] can't be cost
> You may be surprised how much of a difference free is over a few grand for a lot of companies.
> Especially when experimenting with some new thing. In addition to being a difference in amount, free
> is a difference in kind.
Then i'd suggest a category shift in cost - go with genuinely free - something like SQLite or Postgresql. Both free, both high-quality products. No, they aren't up to db2/oracle/informix quality yet, but nevertheless are free of the bizarre quality and standardization problems in mysql.
> That's rubbish. MySQL is gpl'd, and for a gigantic number of uses that means zero cost, zero legal
> troubles, forever.
It is gpled
- with a license requirement with a dozen convenient exceptions, that can be easily revoked later
- based upon a product subject to license renewal owned by Oracle (innodb)
- with client linkage definitions (socket communication with client is linking?) that is a contradiction what is stated in the GPL
- with recommendations to talk to them if you're not sure, or to just license if you're not sure
> The last time we priced Oracle was a couple of years ago, but the pricing was ridiculous.
> And on top of paying the money for the software, and the support, you have to manage licences.
> One of the nicest things to me about moving to open source software was that the software authors
> *want* you to install and use it. There's no more barrier than "apt-get install ". Not having
> anything in the way between you and installing the software saves real money, even if the software
> weren't zero-cost. In an emergency you're trying to set up a new server, you don't want to be
> hunting for a license key or faxing for an installation key or validating something over the phone. >(I've never installed Oracle, maybe it's less of a headache than dozens of other pieces of proprietary
> software I've worked with.)
i partially agree with you here:
1. Oracle's pricing has come down hugely over
> Are you kidding? Have you ever priced out a real Oracle license for a web-based application? (IE
> unlimited users or CPU basaed, which is what Oracle requires for anything that allows the general
> Internet to use it).
You're right - i was thinking of other applications. I shouldn't have since the parent had mentioned a million hits.
Not positive on what the current unlimited users oracle license is for two cpus. But the license cost goes up steeply for unlimited users. For DB2 I think it the cheapest unlimited user license is probably $7500 / CPU (list). Even assuming a substantial discount, mysql will be cheaper.