Oracle Releases MySQL 5.5

darthcamaro writes "Two years after Sun released MySQL 5.1, Oracle has picked up the ball with the official release of MySQL 5.5. New features include semi-synchronous replication, InnoDB by default and new SIGNAL/RESIGNAL support for exception handling. Above all, Oracle stressed that they are committed to further MySQL open source development and that they see it as a complementary technology to their proprietary Oracle database."

Comments

You have nothing to fear.

[tautog]

You can trust us. Honest.

Re:You have nothing to fear.

[Anonymous Coward]

Let me be the first to suggest an outlandish conspiracy theory then. Oracle will develop mysql until they sink Postgres, and then kill mysql too.

Mwahahahaha.

/ 1/3-serious

Re:You have nothing to fear.

[erroneus]

I am simply not so optimistic. I am extremely wary of what Oracle will do. Sun was a positive. Oracle is a negative. I think by now, they are feeling the backlash of their previous missteps but that does not mean they have learned their lesson. If there's one thing I know about this type of business and that type of businessman is that once they set their mind on something, they are going to do it whether or not it is in their best interests. What they will do is back off, slow down or approach the end result from another direction. In the end, it will be the same.

OpenOffice.org will become something we don't want. MySQL will be used as a tool until it manages to kill the competition and it will get dropped. Java is already getting screwed up and over. VirtualBox? I'm afraid to even think about it... I love VirtualBox. I used to pirate VMWare Workstation, but I simply like VB better. I don't want to switch back.

I don't like Oracle. I never did. It will take some REALLY surprising things for Oracle to change my mind about them and I seriously doubt they are interested in what I think of them.

Re:You have nothing to fear.

[erroneus]

It's seriously not that simple. It takes a lot more than community agreement to defeat the power of a name. A name is an extremely powerful asset. Please learn at least that much about business. People are stupid because they believe so heavily in names and branding but knowing it changes nothing at all.

Hell, it took a huge effort just to get Linux distros off of XFree86 and that's not even as well known as MySQL which is now the famous and irreplaceable "M" in LAMP. There is already a fork of MySQL out there. Are people using it? Not really, no. It will take an act similar to that which occurred with XFree86->X.org for the landscape of MySQL dominance to change. And even then, I have my doubts as Oracle's influence runs far and deep in the corporate mind. They would be able to influence RedHat and others into not moving away from MySQL or at least into not supporting a fork of it.

Re:You have nothing to fear.

[davecb]

MySQL is a way to take market share away from MS Sql, and Access. It will be valuable to Oracle until MS dies.

--dave

Re:You have nothing to fear.

[tepples]

Postgres.

Any other questions you have?

Here's one: how to adapt LAMP applications that depend on behaviors of MySQL.

Re:You have nothing to fear.

[tepples]

MySQL is a way to take market share away from MS Sql, and Access.

Microsoft Access is more than just Jet or MSDE; it is also a scriptable GUI framework for accessing databases. What is the direct counterpart of Access that uses MySQL?

Re:You have nothing to fear.

[Anonymous Coward]

While I don't think Oracle views Postgres as threat in any definition of the term, they could hamper OS db field very easily, actually:

1. Over two or three years, Oracle can merge mysql into their Express edition. That'll basically require adding a mysql API onto it. They can probably do that over a few weeks, but why hurry?

When most users can download a compatible binary from Oracle, who'll care about the genuine "mysql", really? Especially given that mysql technologies are controlled by the same Oracle.

2. Over the same period, they can gradually kill the mysql trademark in favor of OracleSomething. Puff, mysql is gone.

3. You'll end up with a product that is mysql compatible, has Oracle features, and is usable "for free". By virtue of being an Oracle, it will compete well against Pg as well. Unlike Pg, it will also provide smooth migration path towards the slaughterhouse with all bells and whistles.

That may move some less ideological Pg users away, hurting Pg's acceptance and development long term.

So, the db landscape is left without mysql, and weakened Pg.

Not a compleat "kill", but close.

Re:You have nothing to fear.

[should_be_linear]

Only counterpart to Access I can think of would be if Fisher-Price and BP created DB engine together.

Re:You have nothing to fear.

[jimicus]

What is the direct counterpart of Access that uses MySQL?

You've had a number of replies so far. AFAICT, most have missed the point so thoroughly that they can't possibly have seen Access used in a business. So I'm going to explain Access.

Yes, Access gives you a database engine (and not a particularly good one at that). The other thing it gives you is a GUI-driven desktop application which makes it an absolute doddle to design tables, queries, forms and reports without having to write a single line of code.

The end result is frequently badly designed, with little or no attention paid to normalisation or data integrity, but it broadly works.

Now, you might very well turn around and say "Tough. You'll just have to get used to writing code." - you're talking to the wrong people. The people who are using Access in businesses are the middle managers who have never in their life written code and aren't about to start now. So many businesses pushed Access to the desktop years ago when they bought Office, and have since discovered that the reason the IT department hasn't heard from lots of parts of the business is because some manager decided that rather than to-and-fro with the IT department (which would cost a lot of money out of his budget - larger businesses just love shuffling money between departments), he'd cobble together a little application in Access to run his department. It's invariably a mess, but it's a mess that's so ingrained it isn't going anywhere.

Anyhow, these guys have no idea what SQL is and are only vaguely aware that a database stores everything in tables. You can no more ask them to do everything in PHP from now on than you can ask them to lick their own testicles.

Re:You have nothing to fear.

[BigDogCH]

This is exactly correct! It seems like every 3rd department has some access database that they use.....IT doesn't find out about it until someone broke it or deleted it. In the end, we ends up supporting it. Here is how it works.

1. A single user creats a simple access database for their own use.
2. That user shares this with their most trusted sidekick.
3. The sidekick takes over when the original user dies from intestinal parasites.
4. The entire department now uses this tool, and is fully reliant on it.
5. Requests now come into IT from other departments asking for access to the tool.
6. IT says "oh man, this sucks".

Re:You have nothing to fear.

[jimicus]

That's only the half of it.

You also have the people who took one look at Access and thought "Eeks, that's scary". They decided to work in Excel instead. Since that day, they have encompassed the business logic of an entire department in a spreadsheet (and almost certainly put in so much effort to understanding Excel that it would actually have been easier to learn a proper programming language, but that's not the point. They're not a programmer and they don't want to be one!)

Anyone who's been in IT support/management for any length of time has at least one Access/Excel related war story.

Re:You have nothing to fear.

[GooberToo]

Delusional much?

While I don't think Oracle views Postgres as threat in any definition of the term, they could hamper OS db field very easily, actually:

Wrong. Oracle is on record as stating PostgreSQL is one of their largest open source threats. PostgreSQL is one of the few open source competitors which offers comparable features, tunability, and can actually beat them in performance even up to the high end. Scalability is something PostgreSQL and Oracle share. Oracle still trumps them on the ultra high end and warehousing, but even that's eroding because of companies like EnterpriseDB (hint, its PostgreSQL).

When most users can download a compatible binary from Oracle, who'll care about the genuine "mysql", really? Especially given that mysql technologies are controlled by the same Oracle.

People don't care about MySQL. They care that its brain dead easy to start using and is pretty fast, especially for light loads, with hardly any tuning. Its basically the antithesis of Oracle. So suggesting that a binary compatible polar opposite of MySQL will magically grab mind share is stupidity at best.

3. You'll end up with a product that is mysql compatible, has Oracle features, and is usable "for free". By virtue of being an Oracle, it will compete well against Pg as well. Unlike Pg, it will also provide smooth migration path towards the slaughterhouse with all bells and whistles.

So you end up with a product that nobody wants and still can't compete with PostgreSQL.

MySQL fills a niche which Oracle doesn't otherwise provide a solution. Slapping a binary compatibility layer on top of a product which doesn't begin to address the niche, doesn't address the niche. Anything else is simply delusion and fueling an exodus to PostgreSQL.

Re:You have nothing to fear.

[bored]

rather than to-and-fro with the IT department

I've been around long enough to see this. You really have to ask what is wrong with the IT departments. If a middle manager who doesn't know anything about programming can use a tool to solve his problem in a fairly short period of time, why can't the IT department do it quicker with better maintainability using a similar tool. Personally I believe its the same mindset that results in the IT department spending two weeks fscking around with Samba patches and config files to solve some obscure problem, when a crappy windows server doesn't have the problem. Its a serious case of "we know better, this is how it should be done" and an unwillingness to admit that maybe instead of building the golden gate bridge all we need is a couple of cinder blocks in the middle of the creek. This totally applies to access, I rarely meet someone who's job is IT/Programming who would stoop to using access to solve a problem. Instead its got to be done using Java (which still doesn't have a decent RAD environment), or PHP or any one of a number of other languages which can be used to build fairly large complex systems, but fail miserably when tasked with creating a functional UI to manipulate a couple database tables, in a hour or two. It still amazes me how hard it is in many languages to just display a table to the user complete with column sorting and searching, and similar functionality to what can be achieved with Access (VB, Delphi, etc) in a manner of minutes, often without any actual programming.

Fifteen years ago I had a job where I spent 50% of my time doing C++ for back-end processing, and 50% of my time in Access creating a UI to access/update data being handled by the back-end system. It taught me a very important lesson about picking the right tool for the job. Years later I'm still working on spit systems, only now its a PHP/Javascript/HTML front-end and C++ backend, and every day I think, this was easier 10 years ago. Back then, C++ was the heavyweight language with a lot of code to get anything done. Now the situation has reversed, and the C++ code is small and lean (100k or so), while the UI is approaching 3x that. Plus writing it with a web UI has actually made the job of concurrent access to the system harder for my particular circumstance, because the management aspect is far more complex than just selecting a couple of values and submitting a form.

Re:You have nothing to fear.

[raddan]

Actually, as someone who has spent the better part of the last decade writing database applications (mostly on MySQL and Postgres), I've come around to Access. Why, you might ask? Because it allows my more technical end-users to collaborate, and it allows you to build functional mockups extremely quickly.

Anyone with experience building enterprise applications can tell you that the hard part is NOT the writing of the code. Most database-driven applications work similarly. The hard part is gathering requirements from non-technical people. What you'll find in any sizeable business is that the knowledge of the business process is distributed among many people. You have to become the expert. I like to model the activity on paper, and then interview people to walk through their jobs with them. The hardest part is trying to decide what parts of the business process are wasteful traditions, and which parts are essential. You may find many subtleties in people's work, the importance of which is not discovered until much later. Good notes are essential.

Anyway, back to Access-- with Access, I can literally have someone sit next to me as I mockup a WORKING demo. When they see it working the way they want, and they walk out, I can rip it apart and do things the right way. On a recent project, I did this, and it finally got the software off the ground. The problem was that the requirements were changing too fast. The original developer had written something in PHP, but every time he was asked to change something, the result was weeks of agonizing bugfixes. We switched the frontend to Access, keeping the data in MySQL (we used the MySQL ODBC connector). Now that the software has matured, and the pace of changes has slowed, developers can replace Access with something like Rails. Access is a great tool if you want to rapidly beta-test your application. I've tried other rapid development frameworks (Rails, CakePHP, and .NET stuff), and they simply aren't as fast, although in the end, you should plan to switch to one of them.

Microsoft put a lot of thought into the GUI design features of Access. I have yet to find something that works as well, or as quickly. You're right, it's not a "real" database, but it can be *attached* to a real database. Microsoft gets a lot of crap (rightly) for their software that sucks, but Access is not in that category.

Re:You have nothing to fear.

[Anonymous Coward]

In fairness, most users do this because of the severe burden IT lays on them to get anything done. Suppose they want to build a simple db to hold vendors, addresses, and contacts... if they go to their IT dept to build it, it becomes expensive, it gets added to the bottom of an 18-month-long project list, and any future change to the table or addition of a new user becomes a hair-pulling bureaucratic nightmare.

Not in every case, of course... but there's a middle ground where departments can build small apps in cooperation with IT, rather than the binary choices of "completely independent of" or "at the mercy of" IT.

Re:You have nothing to fear.

[raddan]

Oh, one other thing I forgot to mention: Access has an excellent query builder. I've occasionally had to write very long queries (multiple joins, subqueries, IN or HAVING clauses, etc), and found myself getting lost while doing it. In Access, you can use the Query Designer to build them graphically, then switch to "SQL View" which spits out the SQL. It generates ANSI SQL, so you can usually just cut and paste it into code or a command interpreter. You may have to fiddle with the string quoting in psql if you're using Postgres, but mysql handles them as-is. Oh, and, as if I didn't have enough nice things to say about Access-- the Relationships window does a very nice job drawing relationships that MySQLWorkshop only recently started doing correctly (MySQLWorkshop *still* cannot auto-layout the tables without making a mess). Of course, you have to tolerate Microsoft's own variant of the ER diagram.

Re:You have nothing to fear.

[jimicus]

If it's anything like most of these databases, your users aren't really sure what information they want or how to get it - Excel gives more-or-less immediate feedback so they can fiddle with the queries they're making until they finally see the data they want, whereas most web interfaces force you to think about what you want, make the query, examine the results carefully, if they're not what you want you probably need to go back and re-run the query.... it's very fiddly and takes a very long time. But superficially, both are doing the exact same job.

From the article....

[Pharmboy]

From the article: There were concerns about how the open source database would fare under Oracle's leadership, but those concerns are now being put to rest by Oracle with the release of MySQL 5.5

Um, no, not all concerns are put to rest. This was a pretty fluffy piece of journalism, just quotes and feel good words. I'm glad that MySQL has moved up a notch, but I'm still looking really hard at PostgreSQL as a possibility in the long run.

Re:From the article....

[nxtw]

Until PostgreSQL gets ON DUPLICATE KEY support, it's off the table (pardon the pun). ON DUPLICATE KEY is just so handy, and solves so many problems, that it's amazing most people aren't using it.
And no, creating a function to handle it as an exception is not a real solution.

Depending on an inferior database for a trivial feature creates more problems than it solves.

If insert or replace with a single SQL statement is such an important feature, you could make a stored procedure.

Re:From the article....

[tomhudson]

As I pointed out, this is something that is so OBVIOUS in retrospect that it's a wonder other database products haven't gotten around to implementing it.

I know it's fashionable to rag on Oracle nowadays, but we've seen this with Sun as well - where one hand doesn't know exactly what the other is doing, or parts act in conflict.

MySQL has the features I want, including ON DUPLICATE KEY. When pgsql has it, I'll certainly look at it, but unless things change, why bother?

-- Barbie

Re:From the article....

[Anonymous Coward]

Or either MySQL or PostgreSQL could implement support for SQL:2008 MERGE syntax which is the appropriate method for handling this scenario, as well as countless others.

http://en.wikipedia.org/wiki/Merge_(SQL)

Re:From the article....

[nxtw]

MySQL has the features I want, including ON DUPLICATE KEY. When pgsql has it, I'll certainly look at it, but unless things change, why bother?

So you don't want data integrity? ACID?

Re:From the article....

[tomhudson]

that's because it isn't needed, the equivalent operations can be done in any SQL compliant database (or for that matter in ISAM and VSAM systems too)

you're wanting to use a less robust dbms because of your laziness.

Don't be silly. Sure, there are other ways to do it, but why should I when it "just works" and is easy to explain to others?

I don't need 100% sql compliance. I need something that does certain things well. Sorry, but postgresql lags in that area.

You can try to turn this into another vi vs emacs war, but I'm just not interested. I'll continue to use the right too for the job, based on the features *I* need, not some ideological nonsense.

-- Barbie

Re:From the article....

[tomhudson]

If I absolutely needed 100% data integrity, I'd write my own server. And I certainly wouldn't use SQL.

Re:From the article....

[h4rr4r]

Yeah Postgresql trades BS features for reliability and data integrity, clearly just like vim vs emacs. Oh wait no not at all.

Re:From the article....

[tomhudson]

When's the last time you lost data with mysql that was directly attributable to the database, and not to a messed-up query or a hardware or network problem?

To hear everyone going on so much, you'd think that you couldn't even run a web site with it.

Obviously that's not the case, so a LOT of the complaining is just nonsense, same as the vi vs emacs jihads.

-- Barbie

Re:From the article....

[nxtw]

When's the last time you lost data with mysql that was directly attributable to the database, and not to a messed-up query or a hardware or network problem?

On 0000-00-00 00:00:00, of course.

Re:From the article....

[tomhudson]

If I absolutely needed 100% data integrity, I'd write my own server. And I certainly wouldn't use SQL.

You think you're smarter than the people working on PostgreSQL, Oracle DB, and other databases (SQL relational or otherwise) known for their ACID properties?

You think writing your own server will provide 100% data integrity?

First, if I wouldn't need to implement all the features - just the ones I want, the job would be a lot simpler.

And yes, I *have* written multi-threaded servers - in c - and they run for months at a time without losing one byte of memory, and without having to kill off threads to reclaim memory lost from leaks.

So yes, if I had to, and someone was willing to pay for it, I could write a server to do a specific job, which is not the same as writing a general-purpose rdbms.

But that's neither here nor there - mysql is good enough for many tasks, so I use it.

Re:From the article....

[Bacon Bits]

The ANSI SQL standard way to do this is to create "INSTEAD OF" triggers, which means you're permanently modifying how INSERT works on a given table. ON DUPLICATE KEY means the behavior of the DB ("On INSERT do I error or UPDATE?") is dictated by the query and not the DB schema. That's sloppy. If Bob writes an application that uses the same database as Alice, now he has to use ON DUPLICATE KEY in order to ensure consistent behavior. That's awful.

Re:From the article....

[Anonymous Coward]

Hey, I've written multithreaded servers that have run for months without leaking as well. That's got fuck-all to do with data integrity as a general concept, but I was hoping we could jerk each other off for a little while since you seem to be in a self-congratulatory mood.

Re:From the article....

[Sxooter]

No, the ANSI SQL way to do this is to use MERGE. Unfortunately, pgsql doesn't support that yet. It's on the todo list so I'm sure if someone got out their checkbook and wrote the pg developers a check we'd see it soon enough.

Re:From the article....

[Billly Gates]

Name one ISP where I can get a PostgreSQL database with my account without getting my own server?

Until that day happens it is Mysql only for me.

Please someone patch PostgreSQL to handle multiple user accounts so ISPs can switch? That is the only thing holding it back and why ISPs include MySQL

Re:From the article....

[tyrione]

Or either MySQL or PostgreSQL could implement support for SQL:2008 MERGE syntax which is the appropriate method for handling this scenario, as well as countless others.

http://en.wikipedia.org/wiki/Merge_(SQL)

It's target for PostgreSQL is 9.1

http://wiki.postgresql.org/wiki/PgCon_2010_Developer_Meeting#Development_Priorities_for_9.1

Re:From the article....

[GooberToo]

Uptime is not the least bit comparable to ACID. The fact this has to be explained means you're way over your head here. If everyone had perfect uptime, we'd likely have ACI-compliant systems.

Threading is the opposite of reliability. That's one of the reasons why IT always schedule periodic reboots of Windows boxes and/or services they run on that platform. When something bad happens to a thread, it can take with it important system and/or application resources, including memory and even locks. Even MS, with some extremely complex recovery code under the covers, has great difficulty here with MSSQL Server - and they have a pretty decent product these days.

As a side note, this is one of the primary reasons PostgreSQL still uses the forked process model. Because with the termination of each back-end comes automatic reaping and cleanup of resources. Not to mention, process isolation.

And yes, I *have* written multi-threaded servers - in c - and they run for months at a time without losing one byte of memory, and without having to kill off threads to reclaim memory lost from leaks.

That last part proves you don't know what you're talking about. And if "kill off threads" is your notion of resource reclamation, then you have absolutely no idea what you're talking about because that wouldn't work in the first place. On all likely relevant platforms, processes hold resources, not threads. So killing a thread doesn't do anything to help with resource management and/or reclamation.

I have created small ACID database systems, back in the OS/2 days, for a highly specialized encryption key management system. Its a tough problem which requires lots and lots of time and even more testing. It absolutely can be done, but what it supports (feature set) will be less than trivial compared to what you get from other offerings which are developed and widely tested. So the comparison is ultimately idiotic.

Re:From the article....

[shish]

When's the last time you lost data with mysql that was directly attributable to the database

A couple of years ago (the last time I used mysql), I was running it on a tiny VM, where I found it hit the memory and disk limits quite frequently -- and in each case, the server would crash and leave corrupt tables which required 20-30 mins of fixing. Running postgres in the same situation, out of memory causes a single worker process to die (but you can then reconnect, it's not the whole server that's down), out of disk causes "error, out of disk space" (and you can still make read-only queries).

Also, running a pretty high load website (>1000 queries/sec) on not-that-great hardware, it seems mysql would randomly drop table indexes when it couldn't keep up with inserts, thus bringing the whole site grinding to a halt. Since switching that site to postgres, it's been a lot more reliable (it's also been faster, since postgres' indexes are better, and it runs straightforward queries better, where I was always contorting queries to avoid mysql performace gotchas, but those aren't really data loss)

Re:From the article....

[GooberToo]

When's the last time you lost data with mysql that was directly attributable to the database, and not to a messed-up query or a hardware or network problem?

If you're losing data from queries, then you're the poster child of just how bad MySQL actually is. Furthermore, do some simple searches on your favorite search engine. Or you can just look at your replies. Data loss from MySQL is extremely common. That's exactly why MySQL has such a poor reputation with knowledgeable DBAs and why, in general, DBAs don't like MySQL.

Re:From the article....

[greg1104]

Someone did get out their checkbook, which is why MERGE has been under development for months already, with working prototypes being tested since late August. The hope is that this makes it into PostgreSQL 9.1, due to be released next summer. Right now trivial cases work, the main bugs found in the last round of review involve concurrency issues that are still being ironed out.

The thing is, Oracle still owns it.

[Nefarious Wheel]

The thing is, Oracle still owns it. Or at least as much as Sun owned it. GPL to the contrary nonwithstanding, who (among the open source community) is going to want to update MySQL, now that it's in Oracle's hands?

The popular euphemism for that arrangement is "A mature technology".

Well, maybe it is. But Oracle's product acquisition is like product punctuation, full stop.

Re:The thing is, Oracle still owns it.

[gman003]

MySQL is still just as good as it was under Sun. If you don't like whatever changes Oracle makes, fork it. Make your own. Call it LibreSQL if you wish. Until I hear of Oracle actually doing something bad to MySQL, I'm going to keep using it.

Re:The thing is, Oracle still owns it.

[h4rr4r]

I would suggest planning ahead, based on their track record it sure seems like you might one day need to go some place else.

Re:The thing is, Oracle still owns it.

[adolf]

I'd like to suggest that, based on the track record of open-source stuff it sure seems like a fork will happen whenever it is deemed necessary.

Re:The thing is, Oracle still owns it.

[syousef]

MySQL is still just as good as it was under Sun. If you don't like whatever changes Oracle makes, fork it. Make your own. Call it LibreSQL if you wish. Until I hear of Oracle actually doing something bad to MySQL, I'm going to keep using it.

If you don't like your life, fork it! Grow wings and fly away to an island paradise.

For most people, and by that I mean 99.9999% the above is a hell of a lot more realistic a suggestion than forking a codebase like MySQL

Re:The thing is, Oracle still owns it.

[icebraining]

They are getting rid of GNU autotools, because autotools is a mess of applications being layered on top of each other through the years. CMake accomplishes the same stuff, including most parameters you need, in a much cleaner way.

If you want to change the prefix, you just need to override CMAKE_INSTALL_PREFIX with "cmake -DCMAKE_INSTALL_PREFIX=/new/path ."

Yeah right.

[Arancaytar]

Oracle is absolutely and steadfastly committed to Open Source, as seen from their admirable interaction with the OpenOffice.org and Java communities.

Re:Yeah right.

[MemoryDragon]

In case of Java Oracle did not do too much which Sun has not started. It is more or less a timely coincidence that Oracle now gets the blame. The entire TCK issue regarding Apache Harmony already was started by Sun in 2006 and the Google lawsuit was pitched by Sun to Oracle as sales argument. Sun already had this idea but not the balls to do it (after all they were the good guys :-) )
Just to make matters clearer. OpenOffice is a similar situation Sun has dragged things along before the Oracle merger.
Although Oracle had its fair share of own sins, some of them were inherited in this regard.

Why not Firebird?

[spynode]

Nobody seems to mention Firebird which is supposedly on hell of a RDBMS. I wonder why it is so unpopular while it offers so much.

Re:Why not Firebird?

[Bacon Bits]

Pretty easy really.

1) It was originally an embedded or server-less DBMS. That instantly makes devs think "Oh Lord, it's Access!"
2) It had a large number of security problems at one point (pre v2 era) in the past that went un-addressed for entirely too long.
3) It uses Interbase Public License (a modified Mozilla Public License) that is not compatible with the GPL... that's really, really bad for an Open Source embedded-style DB.

It's gotten leaps and bounds better since early versions, but it's never really beaten the early reputation, IMO.

Yeah right

[sletraBydnaR]

Trust me, says the devil.

Re:Possible to emulate via temporary tables

[nxtw]

Yes, Oracle has done some stupid things. If you have forgotten, so had Sun. It's amazing how selective our memories have become - Sun is now seen as a candidate for canonization. Sheesh!

The comment you replied to criticized MySQL purely on technical grounds, not because they were owned by Oracle... Indeed, the technical complaints made against MySQL mostly do not apply to Oracle DB.

Windows kernel-mode code signing

[tepples]

VirtualBox? I'm afraid to even think about it... I love VirtualBox.

At ever step of the way it still be open source. If you don't like what they're doing and want to change it, make a fork.

Some virtualization features, such as USB forwarding, require kernel-mode device drivers. On 64-bit Windows Vista and 64-bit Windows 7 operating systems, all kernel-mode device drivers must be digitally signed with a timestamp from a commmercial certificate authority recognized by Microsoft. If you add your own self-signed CA, you get the always-on-top notice "Test Mode" in all four corners of the screen. Unless you are forking on behalf of an established organization that already has a kernel-mode code signing certificate, the advantage of the official version over your fork is that the end user doesn't have to throw his computer into "Test Mode". The only way out that I can see is to run GNU/Linux on the bare hardware, and that brings hardware compatibility issues that I don't feel like bringing up yet again.

Re:Shared web hosting

[tsalmark]

That and MySQL can be used with little or no knowledge other than how to write basic sql statements. PostgreSQL expects just a little bit more, more than many web "experts" have.

Re:Possible to emulate via temporary tables

[afabbro]

Using ActiveRecord, I don't really care much what database I'm using.

Or what performance you get?

Database-independent applications are always a mistake. Always. Oracle functions differently than SQL Server which functions differently than MySQL. If your app is written not to care what database you're using, then your app is either trivial or broken.

Re:Its a trap

[Bill, Shooter of Bul]

Its GPL. You can't link to one of its libraries and satisfy the GPL without releasing your source code. If you do release your code under the GPL,then you may charge what ever fee you would like without Oracle's interference.

Now, if you don't link against it any other GPL'd code and just provide a standard way of connecting to a database like ODBC and have the configuration as part of the program's setup, you're in the clear.

The Decline of MySQL and Rise of Firebird SQL

[mAriuZ]

The decline will not be immediate, it will take some time, notably Apache distributions like XAMPP and WAMP will have to offer users alternatives to MySQL, as most developers use these packages, instead of installing products independently. All is not lost, the Open Source community has plenty of options. There are two well established alternatives to MySQL: PostgreSQL and Firebird. Both have large established communities, and support of major corporations. All of these will become the next MySQL