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.

[RedACE7500]

It's the first good sign I've seen from Oracle since they announced they'd be aquiring Sun.

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.

[alvinrod]

So what? 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. If the community agrees with you, they'll gravitate towards your version. If not, you'll parish into obscurity. That's the beauty of open source, it let's you do what you want; but it also means you need to put up or shut up. You can't have open access and complete freedom to freely change things, but still whine about what someone else is doing with the project.

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.

[h4rr4r]

Postgres.

Any other questions you have?

Re:You have nothing to fear.

[Gadget_Guy]

1/3-serious

Which third of that was serious, because it is all 100% wrong. If Oracle improves MySQL, then great for them. But how could they possibly kill off two open source programs? They can't put the genie back in the bottle.

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.

[arth1]

There are plenty of closed source apps that only support a few select databases, usually Oracle, MSSQL and mysql. And plenty of open source ones too, and with no-one with time, knowledge, skills and interest enough to do a port.

In the corporate world, you don't always get to choose your software, but have to work with existing dependencies. postgresql is simply not an option when business critical systems don't support it.

Re:You have nothing to fear.

[pinkushun]

Yup. Perhaps Oracle is somewhat penitent and trying to regain trust with the Open Source Community. The sad part is we can't be 100% (or even 50%) sure their intentions are good. That would be nice though!

Addendum for those who don't know: LibreOffice is the new OpenOffice.

Re:You have nothing to fear.

[TooMuchToDo]

PostgreSQL drives the .ORG DNS root.

Re:You have nothing to fear.

[Jane Q. Public]

The answer then is not to use the only choice you are given, but to push for other choices. If a business-critical system depends on Oracle, I'm sorry to say you are screwed and must bend over if anything should happen to Oracle.

With open source, your business-critical functions are not dependent on the health of OTHER COMPANIES to survive. If your own business is not taking this fact into account, then "critical" is perhaps a better word than you knew.

Re:You have nothing to fear.

[Pax the Evil]

"That is all I have to say" - ooooh, I doubt that _very_ much. You are on Slashdot, after all :-)

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.

[bmcage]

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?

django

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.

[ashkante]

Or perhaps they intend to slowly increase bloat and decrease quality, until mysql becomes basically unusable. At which point, they can say "Oh, I almost forgot, there's this new, *BETTER* RDMS we also make, but it isn't exactly free."

Re:You have nothing to fear.

[moofmonkey]

When supposedly business critical applications are running on a db which, even at its most ACID, can't provide transactions for DDL schema evolutions (during updates, for example) - i.e. the MySQL schema is MyISAM and not ACID InnoDB. Which means, still open to corruption. Not my definition of business critical. Businesses which decide they want certain applications - their cms, erp systems etc. to be business critical, need full ACID compliance from their dbms, and the open source choice for that is PostgreSQL if they don't go commercial. Choose other applications on top of that by all means, but don't refer to any which offer mysql only as business critical (or, the IT staff who do are fools.) These will drive porting efforts for the inferior OS software which supports mysql only.

Re:You have nothing to fear.

[mwvdlee]

To be fair, both Postgres and MySQL have been slowly moving towards eachother over the past years. Postgres's performance is closing in on MySQL's and MySQL's features set has gotten more complete.

Chosing between the two is increasingly about details rather than the big "performance vs. features" difference from the past.

I'd say for most real-world use, there isn't any significant difference between them anymore.

Re:You have nothing to fear.

[Anonymous Coward]

Fix them.

Re:You have nothing to fear.

[mwvdlee]

MySQL which is now the famous and irreplaceable "M" in LAMP.

Just like PHP/Perl/Python/Ruby is now the famous and irreplaceable "P" in LAMP?

p.s. My LAMP runs on BSD. Is it a BAMP now?

Re:You have nothing to fear.

[Anonymous Coward]

Hire a programmer.

Re:You have nothing to fear.

[daremonai]

merging candy cigarettes with big chew bubblegum.

You mean, candy chewing tobacco? That is the most awesome idea I've ever seen posted on Slashdot. "Kids! Now you can chew like a major leaguer!"

Re:You have nothing to fear.

[tepples]

I take it you meant Access connecting to MySQL through ODBC, did you not?

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.

[Zaiff Urgulbunger]

I liked VMware, but it was always a pain when upgrading to a new version of Ubuntu -- VMware would invariably not work and require a custom patch. VirtualBox on the other hand works perfectly.

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.

[GameboyRMH]

I'm not worried, MySQL is dead, long live MariaDB

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.

[yupie]

Very true, so familiar.
And the steps that follow:

7. There is a growing major problem with the application (data inconsistency, request to integrate with other IT-established applications, performance,...)
8. IT is told "this is an IT problem which you have to solve since you are the IT department."
9. IT now has to solve this. But there are no specs, no documentation, no budget. And yes, in a hurry please.

Re:You have nothing to fear.

[GooberToo]

Years ago, on a modern computer, I saw a spreadsheet take over ten minutes to load and allow Excel to become responsive. It was a massive spreadsheet which literally pushed both Excel and Windows to its limits. Literally it was at the point where the author was extremely limited what he could add to it because otherwise it would load and crash.

That's some scary shit! IT wouldn't touch it with a ten foot pole.

Re:You have nothing to fear.

[ericrost]

MySQL Workbench. http://wb.mysql.com/

Re:You have nothing to fear.

[TheRaven64]

Postgres's performance is closing in on MySQL's and MySQL's features set has gotten more complete

Postgres has been becoming slower? I'd not seen those benchmarks.

For anything other than pure SELECT queries, PostgreSQL has been faster for a very long time (and if you're only doing SELECTs, you want a tuple store, not a relational database, and you'll get significantly better performance than with MySQL).

Re:You have nothing to fear.

[TheRaven64]

Are there any of these left? It's been a good five years since I saw something that actually required MySQL - pretty much everything now has some kind of database abstraction layer and, even if MySQL is the default, will support Postgres and often SQLite (usually only for testing) and a few other things.

Re:You have nothing to fear.

[TheRaven64]

I love VirtualBox. I used to pirate VMWare Workstation, but I simply like VB better. I don't want to switch back.

I never used VMWare, but switching from Parallels to VirtualBox was great. It had two major advantages. It was free, and it didn't cause kernel panics. They eventually found the bug that was causing Parallels to crash the host kernel every couple of days - apparently their developers can't read Intel's (very clear) documentation on how interprocessor interrupts work. This didn't fill me with confidence in their ability to write ring 0 code. I was left with even less confidence in the company when I was told that the only way to get the bug fix was to pay for the new version.

Re:You have nothing to fear.

[raddan]

Having done this recently for a relatively complex Rails application, I can say that it wasn't terrible. Fortunately, if you're using Rails' migration facility, you have a record of all of the SQL definitions you've done. We ran into three trouble spots: MySQL views, the TRUNCATE command, and foreign key definitions which have different syntax in MySQL and Postgres. This meant that we had to change a few things (we wrapped views in this gem and foreign keys in this gem). Turns out the TRUNCATE calls were not necessary, so we ditched them.

The hardest part, for me, was getting used to psql, which is the Postgres equivalent to the mysql command-line utility. MySQL's commands are SQL-like, whereas Postgres' are all prefixed with a backslash to distinguish them from regular SQL. Postgres, as you'll discover, is much more picky than MySQL in some SQL queries. The HAVING clause, for instance, requires you to be very specific in Postgres, whereas MySQL just chugged along and made some (correct, in my case) assumptions. I have mixed feelings about the switch, but we needed the PostGIS geographical functionality which is sorely lacking (or, I should say, implemented poorly) in MySQL. I'll probably continue to use MySQL for my own personal projects... at least until Oracle destroys the project.

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.

[vegiVamp]

Spot on, to my great regret. Way back, I seem to recall DBase having some kind of application builder, but I'm talking DOS era.

This, desktop publishing and gaming are the three great voids on the (generic) Linux desktop, as far as I'm concerned. That being said, inways into the void are being made: Wine supports more and more games; Scribus is shaping up to be a reasonable DTP package; and OpenOffice has sprouted some kind of database frontend application builder in recent years - although I personally haven't really looked at it, yet.

Not that I did say the generic Linux desktop - of course there's always specialised areas like high-end photo editing, video stuff, music and whatnot.

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.

[FlopEJoe]

You can no more ask them to do everything in PHP from now on than you can ask them to lick their own testicles.

Clearly, in both cases, it would just be a matter of will, time, and practice.

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.

[operagost]

You can no more ask them to do everything in PHP from now on than you can ask them to lick their own testicles.

What if my manager is a dog?

Re:You have nothing to fear.

[hanshotfirst]

I don't see a merge as feasible in any way. The two RDBMSes have drastically different architectures. I could maybe see some moves toward common programming syntax, but a merge doesn't make technical sense.

Re:You have nothing to fear.

[kobaz]

....Chosing between the two is increasingly about details rather than the big "performance vs. features" difference from the past.

I'd say for most real-world use, there isn't any significant difference between them anymore.

Which rock have you been hiding under?

Thinking about choosing Postgres or Mysql is like pondering about whether to bring a war tank or a volkswagon bug to the battle of the bulge. If you want to write real database applications, with real consistency and functionality at the database level, you will pick Postgres. If you want to do all the work at the application level (bad), put up with blind truncation (bad), and put up with a lack of some basic features... by all means pick mysql.

The only reason I can fathom that companies are using mysql for any large scale database system is that the project probably started out simple. It grew and grew and became "too big to port" to anything else. Now they are stuck with mysql and its limitations when they should have been with something better.

I used mysql for many many years. I stayed away from postgres because for some reason I had the impression that it was really complicated. Once I had started using posgres, it was an amazing feeling of new freedom that I had.

Re:You have nothing to fear.

[itlurksbeneath]

and if you're only doing SELECTs, you want a tuple store, not a relational database...

I'm curious... How do you get data out of a relational database if you're not using the SELECT statement?

Re:You have nothing to fear.

[HiThere]

Around a decade ago I had a job were I developed in MSAccess. Every upgrade broke backwards compatibility. (Forwards compatibility worked, but to export the database to the older version I had to export the data as text and re-import it. Otherwise in a month or so the database would become corrupt. OK, once I figured that out I could live with it. Then I caught it adding two numbers incorrectly. This is hard to notice, so I have no idea how often it did this without my noticing.

I dropped MSAccess as quickly as I could after that. Shortly afterwards I retired, so I don't know if there was any followup, and on my home systems I'd already switched to Linux. So, for various reasons, I haven't touched MSAccess for over a decade. But I think "toy system" overstates it's value. Yes, it's easy to use. That's the bait on the hook.

P.S.: Before I'd retired I'd already reached the point of being unwilling to agree to the MS EULA. (Read the hideous thing!) So there's no chance that I'll ever find out if MS has mended their ways. But I really doubt it.

Re:You have nothing to fear.

[Anonymous Coward]

Yes, but this only happens because:

1. Single user asks IT to help him setup a My SQL DB with some simple SOA to aid the department in data tracking.
2. IT asks what an engineer needs a DB for.
3. Single user explains mandate from Supervisor.
4. IT asks what an engineer needs a DB for.
5. Single User asks Supervisor for support. Supervisor forwards same email to IT.
6. IT asks what an engineer needs a DB for.
7. Single user explains IT exactly what he wanted, offering a simple diagram of the relational tables and required queries / input and output forms.
8. IT asks why they need to make this DB.
9. Single user explains the need again.
10. IT claims they cannot give Single User a DB.
11. Single user explains job function and supervisor approval.
12. IT claims they have never heard of a DB.
13. Single user points to existing DB across company.
14. IT says "oh THAT db. We can't give you access to that db"
15. Single User explains he doesn't need access to DB, just needs to do X, why can't they add X to existing or create new DB as requested?
16. IT asks why an Engineer needs a DB.
17. Single user begs for access to existing DB function (read-only, anything) to run custom queries so he can at least do his job.
18. IT asks why an Engineer needs a DB.
19. Single User smashes keyboard with face. Calls IT to fix keyboard.
20. IT refuses to open work order without Single User entering it into online DB tracking system.
21. Single use asks how he can do this without a keyboard.
22. IT hangs up.
23. Single User uses neighbor cube to enter in Work Order.
24. IT assigns Single User priority # 19883010299301092920101991010.6
25. Single User dies of old age processing remaining paperwork by hand and keeping track of data with post-it notes.
26. Mail room complains over post it note usage and post-it notes replaced with cheap off brand with no-stick backing.
27. Single User's replacement can no longer follow post-it note filing system since new post-its do not stick and determines that a paperless DB system would be ideal.
28. Single User's replacement get's Supervisor's approval to create DB.
29. Single User's replacement goes to step 1.

Re:You have nothing to fear.

[Doomdark]

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?

Surely you are jesting here. Getting anything done at Oracle goes at glacial speeds, in general; but change you are talking about is not exactly trivial (at too many levels to enumerate).

Re:You have nothing to fear.

[psydeshow]

Postgres.

Any other questions you have?

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

Here's another: how to adapt developers and sysadmins who are used to the mysql command line interface, mysqladmin, and my.cnf to the Postgres toolkit.

Re:You have nothing to fear.

[WuphonsReach]

Music to my ears, someone who "gets" what MSAccess is good at.

The other thing that it's good at is dealing with small ad-hoc databases for a non-technical group of users who just want to be able to run a few queries, create new tables, etc. Without having to deal with a central server. Which, if you do a lot of short 1-2 week projects where every data set is different except for a few key similarities, is handy. Heck, some of these projects only live 3-4 days from start to finish.

Not to mention all the nice import/export features. Having everything in a single file (which is good/bad...). Being able to copy/paste tables or queries to make a quick backup. Or being able to restore from a "oops" without bugging IT for backup tapes (as long as you did that copy/paste step). Near seamless copy/paste between Excel and MSAccess for times when it's faster to setup, transform or analyze the data in Excel.

I'm not holding my breath that OOBase or LibreBase will catch up. I've been waiting for the Base developers to grasp the concept of MSAccess for almost 10 years now, and it hasn't happened.

Re:You have nothing to fear.

[jimicus]

Now that is an interesting view and not one I'd considered. I knew Access could connect to MySQL but I never thought of it as a prototyping tool.

Damn good idea. Extra bananas that ape.

Re:You have nothing to fear.

[jimicus]

OpenOffice has sprouted some kind of database frontend application builder in recent years - although I personally haven't really looked at it, yet.

Save your energy. By my reckoning, it's 3-5 years of fairly solid work behind Access 1997.

Re:You have nothing to fear.

[GooberToo]

Actually, I have used the express edition.

Re:You have nothing to fear.

[jimicus]

P.S.: Before I'd retired I'd already reached the point of being unwilling to agree to the MS EULA. (Read the hideous thing!) So there's no chance that I'll ever find out if MS has mended their ways. But I really doubt it.

We're going off on a tangent here, but I have to ensure we're up to date on licensing as part of my job. I've reached a simple, inevitable conclusion.

You aren't meant to get commercial software licensing right. Indeed, you are being set up for failure.

Now I don't know if this is because of lawyers infesting big commercial software houses or if it's conspiracy, but looking at the various conditions attached to different pieces of software, it's hard not to reach that conclusion.

For instance: According to the EULA for server versions of Windows, any sort of muilti-user GUI-driven remote access requires Terminal Server licensing even if you don't actually use Terminal Server to do it. There are products on the market proudly announcing "Terminal server functionality without the licensing cost!" Erm... I've got news for you guys.

It gets better. Windows OEM stipulates that end users aren't allowed to use an OEM copy of Windows as the basis for an image to roll out to all their PCs. End result? Following the letter of the licensing, even if you set up a business tomorrow and buy all new PCs shipping with Windows 7, you still need an enterprise license if you want to roll out the same image to every PC. And the enterprise license contains a clause saying "You license for every PC in your business. Not every PC you plan to run Windows on." And people wonder why big businesses really don't care about desktop Linux.

Re:You have nothing to fear.

[jimicus]

This is an extremely good point, it's something that Apple fully understand, Microsoft sort-of understand and most F/OSS project leaders need beating into them with a heavy stick.

User interfaces matter, and they matter at all levels - not just for the end-user. With the possible exception of Gentoo users, nobody wants to fuck around with their computer. They want to use their computer to solve some other problem - and the best thing the software can do is get the hell out of the way.

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.

[vegiVamp]

3 to 5 years for how many people ?

OOO split out from Oracle, but if Larry were to decide it'd be funny to give Ballmer a heart attack, I suspect progress could be made pretty rapidly.

Now to convince Larry :-)

Re:You have nothing to fear.

[jp10558]

I have to admit that I am stumped that all the medium to large OSS projects (that I've used) seem to use MySQL. Though this may betray my ignorance, I'm thinking of things like OCSNG, Zenoss, etc.

Re:You have nothing to fear.

[jp10558]

Well, yes - unless I'm misinformed, things like GLPI (Inventory), Zenoss (monitoring event database) etc still only use MySQL.

Re:You have nothing to fear.

[jp10558]

I have to say, for some reason managers where I work really like excel. Even when we have all the data they want to look at already in a database with a web gui that lets them run queries by selecting field names and sort procedures, they then want to use the export to csv and manipulate in Excel. I honestly have no idea what excel does that this web app doesn't do (and it's instantly updated as users and computer client apps update it) nor have the excel people been able to tell me or show me what it does, but boy - everything ought to be a spreadsheet.

What's really sad is my coworker managed to get about half of the spreadsheets replaced with wiki table plugin, so all they really wanted was columns they could e-mail around!

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.

Re:You have nothing to fear.

[jp10558]

Sometimes IT can be very boneheaded. I've seen this. Other times, we get tired of being burned when instead of users telling us what they want to accomplish they say things like "I need a compiler". It took several days of back and forth to understand that what the user really wanted was someone to re-compile some dlls for Matlab to 64 bit so they'd work on Win 7 x64.

Often times, users ask for a specific program without understanding what it does, or if there's an existing tool that performs that function fine. For instance, users ask for a software package called Webdrive. We ask why. They say they want to share files. We say we already have a fileserver they can use, a Wiki they could use, SVN server they could use. So in this case we really don't see any reason to set up another proprietary program.

Re:You have nothing to fear.

[Firehed]

grep and some crazy perl scripts?

Re:You have nothing to fear.

[badkarmadayaccount]

Someone please implement a MySQL compat layer for Postgres, please...

Re:You have nothing to fear.

[badkarmadayaccount]

Yes.

Re:You have nothing to fear.

[kobaz]

The biggest problem with making a mysql compatibility layer on top of postgres is dumbing down the whole interface to be compatible. It would involve removing so many items and breaking many standards. You might as well just keep using mysql in the meantime while you port your app to postgres.

And... the whole point of a compatibility layer is so that you can either 1) run your whole app as-is and keep developing as-is on the layer on top of the system. So now you have zero gain from moving to postgres, you're still using the same old cruft... or 2) you want to run some code in the compat layer and some code in the native layer. Now you open up a whole huge can of worms. Now you need to specify which tables/functions/etc are running in which platform, the screwy mysql one, or the real postgres one. Unforeseen interactions between the two would be full of fun surprises I can assure you.

Off the top of my head I can think of a few horrid problems with mysql that would have to be ported. Silent truncation for instance. Insert 30 characters into a 20 character field and mysql will gladly accept it, and not even throw you an error. Now there is a flag you can turn on that will give you errors on some of these issues, but not all of them.

There's several other silent behavior type problems in mysql that would need to be ported over. See: http://code.openark.org/blog/mysql/but-i-do-want-mysql-to-say-error

There's a bit of a history of silently doing nothing with bad data, or silently doing nothing when there's a problem in general. See: http://use.perl.org/~Smylers/journal/34246

This next writeup is a year old, and obviously some shortcomings of mysql have been fixed up... but many of these issues still remain. The issues listed that have not been fixed.... and then some, would have to be ported.

See:
http://wiki.postgresql.org/wiki/Why_PostgreSQL_Instead_of_MySQL_2009

In conclusion... why waste time in porting such an array of limitations and buggy behavior to such a great platform.

You might say 'but EnterpriseDB is an oracle layer on top of Postgres'. Yeah... Oracle... a real database, not mysql.

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....

[tomhudson]

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.

-- Barbie

Re:From the article....

[corsec67]

Unless you are trying to do anything that involves subqueries. Hopefully they fixed it, but subqueries couldn't be used in views, and would often be executed slower than running the queries separately and typing the answers from one query into another.

Also taking the silent data truncation errors, MySQL isn't exactly a highly reliable database.

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....

[rubycodez]

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.

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....

[Anonymous Coward]

Heh, and I came here to warn the AP about Postgres' total lack of MySQL's silent truncation feature.

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....

[tepples]

I develop LAMP based retail warehouse automation software at work. I've generally used a workaround of realizing subqueries in temporary tables.

Re:From the article....

[Estanislao Mart�nez]

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.

Um, SQL Server 2009 and Oracle have the MERGE statement, which is a SQL 2003 standards, and sounds like it is exactly what "ON DUPLICATE KEY" is from my quick Googling.

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?

Because you probably need a lot of things that you don't know enough about to want.

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....

[afabbro]

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

....and your credibility just flew out the window. Data integrity is the mission of SQL relational databases and has been developed with that in mind for nearly 40 years.

No doubt, something you whip up in your basement will be much better...

Re:From the article....

[rubycodez]

I've been a developer and admin on both over the last ten years, two horrendous crashes losing mission critical data with mysql and none yet with postgresql.

mysql is ok for but I wouldn't build back end for say a medical insurance EDI system on it as I have recently with 18 month project on postgresql 7.3.10

Re:From the article....

[tomhudson]

I started on MySQL, but switched to Postgres because MySQL lacks deferred foreign key constraints. Real world example: Model a city<-->state relationship where every city must have a state. Now, require that every state have a capital city. Now, enable foreign key constraints. Oops, we just broke MySQL.

Just a quick observation: Your model is already broken. Even in the U.S., not every city has a state, and neither does every capital.

-- Barbie

Re:From the article....

[Pax the Evil]

You think that's air you're breathing? :-)

Re:From the article....

[Pax the Evil]

A decent DBMS will _not_ be affected by network or hardware problems.

Re:From the article....

[Anonymous Coward]

What. On December 14, 2009 (kinda like 1 year ago), Oracle said they would maintain MySQL just as nicely as Sun and et. al. December 15, 2010 (kinda like today), out comes a brand spanking new version of MySQL. Unlike mysql-5.1.53, 5.5.8 NO LONGER SUPPORTS GNU TOOLS. ./configure is gone. So if you want to add in little nicities like --prefix=$MYSQLHOME --with-unix-socket-path=/var/run/mysqld/mysql.sock --enable-thread-safe-client --enable-shared --with-mcrypt=$SCRIPTDIR/apx/mcrypt-* ....then you can't anymore. Its been 1 year. They played nice for 1 year. We got one year. Now the lockdown begins. Now the incompatibilities begin. Now the slow-ness and smaller maximum table sizes and all the rest begins. We knew this day would come. Its not like anyone who could fog a mirror couldn't see this coming. Today I made the switch to another database management system. It starts with GNU autotools being stripped out, then you need proprietary libraries to build it (or use the binary), then you need proprietary libraries anyway, then you just have to register for the proprietary libraries. Suddenly the proprietary libraries are behind a paywall. Finally, you are strongly encouraged to use their main product, and forget you ever heard of 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....

[curious.corn]

swooosh...

Re:From the article....

[Ginger Unicorn]

jesus christ...

Re:From the article....

[Yaa 101]

It seems you forgot to make a binary safe backup of your database.
b.t.w. my tip to you is not to trust PostgreSQL either as it like MySQL is a database server, not a backup method.
You wouldn't have lost your mission critical data if you used rsync to put a binary safe copy on (an)other machine(s).

Re:From the article....

[CBravo]

Exception reported on Wed Dec 15 17:20:02 CET 2010 from ... Cannot query XXX database with query SELECT * FROM YYY Table \'./XXX/YYY\' is marked as crashed and should be repaired at

Re:From the article....

[tomhudson]

Just skimming all your posts, if you're not a troll, god help you. Or rather any poor company that lets you touch their code. You shouldn't be allowed to touch any software with a 10 foot stick.

Here, let me give you a clue. If you're using a stick to write software, you're doing it wrong :-)

Re:From the article....

[GooberToo]

That might possibly be one of the least intelligent things I've ever read.

Can you possibly expound on that statement to explain why it makes any sense whatsoever? Or perhaps explain the relationship between SQL and ACID?

You do realize there are non-SQL ACID solutions already readily available right?

Re:From the article....

[pak9rabid]

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.

Oh gooood for you </Christian Bale>

Re:From the article....

[Atzanteol]

You might want to write your own OS to run it on too.

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....

[Anonymous Coward]

It regularily lost data for me years ago just before I stopped using it for anything important.

How about Ma.gnolia. MySQL silently lost everthing for them:
http://www.wired.com/epicenter/2009/01/magnolia-suffer/

Re:From the article....

[GooberToo]

That's a great list. One item on the list, "External security provider", has huge security implications for PostgreSQL down the road.

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....

[GooberToo]

webfaction.com

Re:From the article....

[TheRaven64]

An ACID-compliant database will always be in a consistent state. If a network connection fails in the middle of a transaction, that transaction will not be applied, it will never be half-applied. If the power goes out in the middle of a disk write, the last transaction will fail completely, it will not corrupt the database. If the RAID set dies completely, there's nothing any database can do, but an ACID-compliant database will ensure that any failure short of this will not result in a corrupt database, at most it will result in the loss of any in-flight transactions.

MySQL is not ACID compliant.

Re:From the article....

[gnud]

https://www.surftown.com/

Re:From the article....

[orient]

This week.

Re:From the article....

[DragonWriter]

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.

To my view ON DUPLICATE KEY is less useful than support of SQL common table expressions (which Postgres has and MySQL lacks). INSERT...ON DUPLICATE KEY can be expressed simply as an UPDATE/INSERT pair, whereas replacing a query using -- particularly recursive -- CTEs without support for them often can't be done without resorting to procedural code.

And no, creating a function to handle it as an exception is not a real solution.

Using a PL to create a function is unnecessary to replace INSERT...ON DUPLICATE KEY (though it may be a reasonable choice if the query is already being used in procedural code to start with.)

Assuming a table t with a primary key of k, a MySQL expression of the form:

INSERT INTO t [source expression] ON DUPLICATE KEY UPDATE [update expression];

Can be trivially transformed into PostgreSQL as:

UPDATE t SET [update expression] WHERE k IN (SELECT k FROM [source expression]);
INSERT INTO t
SELECT *
FROM [source expression]
WHERE k NOT IN (SELECT k FROM t);

While INSERT...ON DUPLICATE KEY is a a nice shorthand, it doesn't increase one bit what you can do within pure SQL, and in saves at most one SQL statement. Weighed against all the advantages that PostgreSQL in terms of SQL language support (not even getting into comparing the two systems outside of SQL language support), I can't see it as being that big of a deal.

But if you find it critical to your use, then MySQL obviously is the choice for you.

Re:From the article....

[DragonWriter]

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.

Several other database products have instead implemented the functionally-similar but slightly more verbose SQL:2008 standard MERGE INTO statement where MySQL has non-standard ON DUPLICATE KEY UPDATE clause on the INSERT statement, some other databases (SQLite, for instance) implement similar functionality using INSERT OR REPLACE INTO.

Re:From the article....

[jjohnson]

http://www.cartikahosting.com/

Re:From the article....

[Doomdark]

Does 'on duplicate key' have many use cases beyond typical "UPSERT" functionality (aka MERGE etc etc) that almost every other DB engine also happens to implement (just using different name and syntax)? That is, ability to either modify (UPdate) existing row, or if none exists, to add (inSERT) one.

Re:From the article....

[DragonWriter]

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.

The pre-SQL:2008 ANSI standard SQL way to do it is with an UPDATE and INSERT pair; every MySQL INSERT...ON DUPLICATE KEY UPDATE statement can be trivially mapped to an UPDATE/INSERT sequence.

SQL:2008 introduced the MERGE INTO command to do things in a single command. Several DBs have implemented it, PostgreSQL hasn't yet.

Re:From the article....

[DragonWriter]

Please someone patch PostgreSQL to handle multiple user accounts so ISPs can switch?

What is this supposed to mean? PostgreSQL obviously handles multiple user accounts.

Re:From the article....

[GooberToo]

I going to make some assumptions about your DB workloads, but one of the things you said made me think of this.

One of the reasons why MySQL is frequently very fast for simple, read-only workloads, is because it can frequently satisfy queries by only consulting its indexes. PostgreSQL can't do that, but is an upcoming feature.

While that sounds great for MySQL, and for some workloads it is, what many users don't realize is that as their needs grow, suddenly pure index scans are no longer possible and MySQL's less than optimal query optimizer results in lackluster performance. This stands in stark contrast to PostgreSQL's implementation which has a very optimized query optimizer and optimized fast paths for non-indexed table access.

This are but only a few reasons why MySQL seems fast for single user and simple queries but quickly stalls and ultimately fails to perform and scale for most real world applications when compared to other databases such as PostgreSQL and Oracle.

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.

Re:From the article....

[tomhudson]

Not all applications require 100% ACID compliance.

Plan for things to fail, and when they do, you won't be in such a panic.

As for:

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.

The open group disagrees

The pthread_detach() function shall indicate to the implementation that storage for the thread thread can be reclaimed when that thread terminates. If thread has not terminated, pthread_detach() shall not cause it to terminate. The effect of multiple pthread_detach() calls on the same target thread is unspecified.

So does the Comp Sci department at Temple U pthread_detatch

You can mark for deletion and reclaim the storage and other resources associated with a thread (of course, after it has terminated executing) with the command:

#include

int pthread_detach(pthread_t thread);

This command will not terminate a thread that is executing, only indicating that we want to reclaim automatically its storage when it terminates execution. Other ways of reclaiming the resources of a thread are:

• If the thread was created with attribute set to PTHREAD_CREATE_DETACHED, or
• If this thread is waited for with a pthread_join call.

So does the Lawrence Livermore National Laboratory pthread_exit() is the way to claim thread-local data.

Regardless of the method of thread termination, any cancellation
cleanup handlers that have been pushed and not yet popped are executed,
and the destructors for any existing thread-specific data are executed.

Normally, you also write clean-up routines for closing file handles, freeing up any manualy malloc'd memory and returning it to the arena, etc.

And Apple here

Because POSIX creates threads as joinable by default, this example changes the thread’s attributes to create a detached thread. Marking the thread as detached gives the system a chance to reclaim the resources for that thread immediately when it exits.

and even the Aussies at Cardiff U agree pthread_destroy() that you can free up all memory allocated, so as long as you clean up the stuff YOU allocated, and allow the library to free up the stuff allocated at thread creation and initialization.

So, what relevant platforms don't support pthreads?

Re:From the article....

[Billly Gates]

An ISP can not easily setup PostgreSQL to handle many different user accounts with a root account for each user.

With MySQL an ISP can use CPanel to create another root MySQL with sub users for each account when a user signs up.

PostgreSQL can not do this. There is one root account or you have to manually configure it for each user. For this reason MySQL is the only option for a shared host.

Re:From the article....

[DragonWriter]

For this reason MySQL is the only option for a shared host.

This can be empirically shown to be false as there are shared hosts that provide PostgreSQL (as well as other non-MySQL databases), proving that MySQL is not the "only option for a shared host."

Re:From the article....

[rubycodez]

nope, the corrupt data was replicated by the async SAN replication host, same thing would have happened with rsync.

That's a common misconception of those hwo replication will always save them, truth is when buggy software starts writing crap, the crap gets copied

Re:From the article....

[badkarmadayaccount]

Quite reasonable, as long your architecture is fitted to your specific needs, or in the general case, is with a simple enough semantic. Btw, you do realize that using KVM can save you the complexities of booting and drivers.

Re:From the article....

[tomhudson]

Not my fault if you're a sloppy coder.

"complementary"...

[Anonymous Coward]

In the sense of the price is being brought in line with Oracle's traditional products (MySQL starts at $2000 a server now).

https://shop.oracle.com/pls/ostore/f?p=ostore:2:0::NO:RP,2:PROD_HIER_ID:58095029061520477171389

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.

[tsalmark]

Planning ahead: If Oracle does something evil: a. stop upgrading. b. either fork and modify or support someone who does.

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.

[Anonymous Coward]

Well sparky, with this release, they got rid of GNU autotools. Where you used to have a ./configure with a long line of parameters and magic and wonder built in, now you have a generic box. Hope it does what you want it to! Next, (ok this one wasn't that hard to follow), Support for the IBMDB2I storage engine has been removed (from the horses mouth). MariaDB was looking better before. Now its looking better and better. The MariaDB team doesn't have Oracles mega bux, but on the other hand, they aren't trying to kill anything either. I've been down this road before. With a team, I built a database application for a client. They didn't have a lot of money, but FoxSoft had a nice database at the time, and we built what they were looking for. 3 months after delivery, Microsoft acquired FoxSoft. They wouldn't kill it in favor of MSSQL would they? YOU BET! Instead of being able to access 2 billion records, the new microsoft version was suddenly only good for 75000. And it was slow. And half the functionality was stripped out. I'm glad the fork has already happened. 5.1.53 is the last version of Mysql that I use. Oracle has already started screwing it over (and us). Its true, I'm not paying them any money. Its also true that I'm not going to use any of their products again.

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 ."

Re:The thing is, Oracle still owns it.

[diegocg]

Mariadb, Drizzle...there are already enought mysql forks.

Re:The thing is, Oracle still owns it.

[jjohnson]

Isn't the MariaDB team the original MySQL team that sold out to Sun in the first place, ultimately putting it in the hands of Oracle? If MariaDB replaces MySQL as the OSS db of choice, why shouldn't I be worried that they'll just sell out again?

Re:The thing is, Oracle still owns it.

[Zontar The Mindless]

...CMake accomplishes the same stuff, including most parameters you need, in a much cleaner way. ...

We also grew rather weary of maintaining multiple (and sometimes radically different) sets of configure and build scripts for different platforms and compilers and dealing with the resultant platform- and compiler-specific bugs. (Look at the zoo that inhabits the BUILD directory of the 5.1 and earlier trees to see what I mean.) Not much fun having to stop everything to deal with those when you're trying to get release builds out the door.

CMake lets us handle most if not all of those issues transparently.

It's also worth mentioning that CMake is Open Source.

OpenSolaris?

[Anonymous Coward]

Don't believe anything Oracle says about open source support.

They killed OpenSolaris this year. I run zfs boxes in various setups, yes the path to OpenIndiana is clear, but its not fully up yet which creates a bug fix issue today. Oracle killed OpenSolaris after people waited 1 year for the next stable release which was delayed and delayed and delay.

Oracle will slowly kill mySql now, just wait. So start to look into migration options today.

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.

Possible to emulate via temporary tables

[Steeltoe]

You can create a temporary table, fill it up with rows of data and:
1) INSERT rows not existing from temporary table
2) UPDATE from temporary table unless INSERT affected all rows
Ensure you drop temporary table at last.

If you suspect UPDATE is necessary, you may do #2 first to save on the number of updated rows.
If you supect UPDATE is not necessary, do #1 first like shown above. If you're paranoid, you may raise exception if UPDATE becomes necessary.
You may find variations which may be more efficient or simpler, but this works for me at least.

It may not be native support, and not fully optimized regarding the last update in some situations.
However, it's incredibly fast because it's using memory to cache the processing, and then sending everything off to the DB in bulk, saving on I/O and locking mechanisms.
I've got performance from this comparable to the most aggressive nosql database solutions, with the benefits of RDBMS intact.

I've switched to Postgres and am not looking back at mysql. The default install even failed the second time, which made me go to Postgres and be done with it.

Temporary tables give alot of possibilities to speed up and perform bulk-processing directly with the DB.
I'm surprised it's not used very much. Postgres has been a pleasant surprise as well, coming from an Oracle-laden background.

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.

Re:Possible to emulate via temporary tables

[Steeltoe]

I can't see I critized anything much. I may have mentioned the mysql-install failed on me at the second attempt, and made me ditch it.

But thanks for standing up anyways :)

Re:Possible to emulate via temporary tables

[Steeltoe]

"Oh don't use mysql Oracle is evil blah blah blah do it this way instead even if it takes 4x as much code".

Nice bunch of strawmen you've got there, but I fail to see I wrote those words you're putting into my mouth.

4x the code? I assume you've heard of classes and methods? Having extended ActiveRecord in Ruby, mass updating in this fashion is a tiny one-liner, just sending an array off to a function-call, and the data is merged into the DB very efficiently, regardless of column names and wether each row should be inserted or updated. I must admit, there are rare occations where that is really necessary, but it really came in handy in my latest project.

Using ActiveRecord, I don't really care much what database I'm using. Can switch to Oracle, Mysql and a bunch of others with almost no change in code. If mysql had installed properly, I would probably have used that, since that's what I'm most familiar with.

If you haven't used ActiveRecord, and coding SQLs by hand, I'd say you're missing out. My latest project would've been an endless spagetthi of SQLs if not for ActiveRecord in Ruby. It has saved me so much time and simplified my code tremendously.

Other than that, I don't care much about where Oracle is going with mysql. It will have to continue on its own merits. If mysql fits your bill, please continue to use it. One more choice is always good.

Please take my words for how they are meant: A solution to the UPDATE OR INSERT-issue on Postgres, and any database supporting temporary tables, including mysql. It's a solution that can speed up bulk updates by an order of magnitude or two. Especially rather than doing individual updates and inserts.

For smaller projects though, maybe this will be overkill, or maybe someone will release the code for everyone, even smallies, to benefit. I could also do that, but would rather not maintain a more universal version. It's quite easy to implement in ie. Activerecord anyways. There'some similar code online to start from in Ruby already published on some blog.

I've been working for this project for over a year, so for me this has been of great value and help to me. So I wished to share, that's all.

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:Possible to emulate via temporary tables

[Kjella]

Unfortunately yes, because despite ANSI making SQL standards the actual common feature set is extremely minimal. It's not a strength nor a feature, of course if you want that last bit of performance you will optimize for a specific database. However, there are many applications between trivial and "pedal to the metal" that ought to be possible to write in a database-independent way, but that you can't because of syntactical sugar. Operations on date and time for example are a genuine pain in the butt and doesn't work the same at all. A lot of the basic operators aren't the same, like if you ever use "||" as concatenation as per the SQL standard your code is broken on MSSQL and MySQL. And even if you need the most trivial of triggers, good luck writing one that's valid T-SQL, pl/SQL, pg/SQL and whatever MySQL has, even if it's just basic SQL statements in a wrapper. Even for what I'd call a basic application - not a trivial one but one step up - you're likely to be tied to a specific database unless you use some sort of meta-SQL wrapper which has tons of issues on its own.

Re:Possible to emulate via temporary tables

[Steeltoe]

Well, my needs are dumping and updating tens of thousands of records in bulk every minute or so. Using individual SQLs was painfully slow. Using transactions unnecessarily locked the DB and gave worse performance because of that. So how to do bulk operations on the DB?

My solution was using temporary tables, and I'm betting I'm getting near peak performance, since temporary tables are residing in client-side memory (my assumption for an optimal implementation of it anyways). Two lines of sql dumps everything to the database in terms of insert or update, often just one of them.

Another method is to build a huge insert with multiple rows. This is also fast, but for some unknown reason I'm getting better results with temporary tables. Maybe because I'm not sending over the huge sql-syntax over I/O, but using a native implementation of the temporary tables.

It may or may not be as efficient as a native implementation of "insert or update" in the DB, but it's damn fast and versatile. Can be used for many types of processing, although I suspect most projects don't need that flexibility to work with the DB directly.

As for ActiveRecord in Ruby, it has saved me hundreds of hours and thousands of lines of useless code pampering to the database-layer.

For me, less code is more, it makes me able to extend and refactor my project faster, as well as structure my ideas to achieve more detailed and more real-life results. Since my requirements are not fixed, this makes for very agile development and results.

Of course, since I'm using Ruby, ease of coding, simplistic structure and rapid development is more important to me than raw performance. However, in my experience, alot of the slowness can be identified and remedied. The parts that is not crucial for performance, do not have to run at peak performance. Often, some Googling or trial and error can reveal why some parts of code is slow. For me, this is more cost effective.

If performance becomes an issue in the future, I might consider making C-extensions to Ruby to pamper to my specific project. In my experience, higher-level languages frees the programmer to think of higher things, and achieve more. But it depends what kind of project and architecture is required too of course.

Why do you say database-independent applications are _always_ a mistake though? It's saved me so much work. I'm using fast bulk-processing, with some Postgresql-specific code to speed up the most crucial parts. ActiveRecord makes it possible to use raw sql, db-specific stuff or generate sqls dynamically in a different and more optimal manner than the default. So it's quite flexible. Profiling can reveal hogs and are usually fixable. Anyways, the real hogs seem to be more I/O-related in my project, than what's going on in memory.

I didn't plan to be database-independent, it's just that ActiveRecord in Ruby makes a damn good job at it by default, releasing me of DB-dependent syntax and rules. Sure, there may be some extra SQLs, often in non-crucial parts, but I am not here to work for a computer, but having computers work for me. Hand-coding the SQLs ActiveRecord generates for me dynamically would be madness, and probably stopped my progress for a considerable time, maybe even aborted the project if it was too much. In short, DB-independece hasn't been a hassle, using ActiveRecord, it's saved me work and made my program better. DB-independence has been a bonus feature of ActiveRecord to me, an enhancement to the beauty of Ruby.

Not having to think of SQL for the most time, has made me achieve both higher-level design and results of my application, as well as fast refactoring when required.

Keep in mind: Higher-level optimizations often lead to radical performance improvements, but is hard to do if you're stuck at a lower level. So it may be that one should find a balance between resources and how low level you're willing to go, for each specific project.

I've reviewed several nosql solutions. But with Ruby, ActiveRecord and Postgresql,

Re:Possible to emulate via temporary tables

[Steeltoe]

Unfortunately yes, because despite ANSI making SQL standards the actual common feature set is extremely minimal. It's not a strength nor a feature, of course if you want that last bit of performance you will optimize for a specific database. However, there are many applications between trivial and "pedal to the metal" that ought to be possible to write in a database-independent way, but that you can't because of syntactical sugar.

Agreed

Operations on date and time for example are a genuine pain in the butt and doesn't work the same at all.

No problem with Ruby and ActiveRecord. Just dump the Ruby datatypes into the appropriate ActiveRecord fields.

A lot of the basic operators aren't the same, like if you ever use "||" as concatenation as per the SQL standard your code is broken on MSSQL and MySQL. And even if you need the most trivial of triggers, good luck writing one that's valid T-SQL, pl/SQL, pg/SQL and whatever MySQL has, even if it's just basic SQL statements in a wrapper. Even for what I'd call a basic application - not a trivial one but one step up - you're likely to be tied to a specific database unless you use some sort of meta-SQL wrapper which has tons of issues on its own.

I guess I'm lucky to have found such a wrapper in ActiveRecord that works very well for me, and doesn't handcuff me from writing DB-specific code when required.

Drawbacks of ActiveRecord is that the default objects generate a bit of overhead. However, it's possible to use arrays within arrays instead of arrays of objects or direct sql to speed things up. For me the overhead has had minimal impact.

Other than that, I'm having trouble finding drawbacks of ActiveRecord, because in most areas it has made me more effective and clearer, rather than hand-crafting SQL or stored procedures.

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?

[rschmitz2010]

The reason MySQL is so popular is that it is supported in almost every "open source application" that needs a database on the backend. Whenever I come across a product that requires a DB it is usually mysql > then PostgreSQL > then Oracle > then whatever. Look at Drupal, OTRS, moodle, alfresco, Nuxeo or other CMSes, CRM, etc. Look at the install requirements. They usual mention the DB support in this order.

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.

Re:Why not Firebird?

[afabbro]

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.

Ecosystem.

That's really the answer...so many FOSS apps are coded and developed primarily with MySQL in mind that it's the path of least resistance at this point for FOSS apps. It really has nothing to do with the quality of the code per se...as long as MySQL is "good enough" it will continue to be used.

Re:Why not Firebird?

[Bill, Shooter of Bul]

I've actually looked at using Firebird before. It seems to be caught up in the Postgres trap. Postgres is a great RDBMS: Arguablly better than Mysql.

Question: How many people actually use Mysql as a RDBMS in such a way that it could benifit from the additional features of the more featureful systems?

Answer: not many.

Question: How many people are using Mysql because the lack of the features allows it to be faster?

Answer: All of the large users of mysql: facebook, flickr, google, yahoo, ect.

If you imagine two end of the spectrum between a full RDBMS on one end, and a NoSQL db on the other, Mysql sits in a sweet spot that many people appreciate.

Its also the easiest to set up and configure replication on, which gives it some level of backups, scalability, and availability.

Re:Why not Firebird?

[ceeam]

a) It's less unpopular than you think.

b) And being "unpopular" is actually a nice feature.

c) Historical documentation problems. Less of an issue now, but it used to be "lore-based".

Also, the stricter RDBMS is the more unpopular it will be. You *can't* be as sloppy with it as you can with MySQL (or even Postgres). For starters - because transactions everywhere and case-sensitivity.

Re:Why not Firebird?

[mAriuZ]

I did mentioned in another long artcle , please vote it or resubmit-it to slashdot

http://slashdot.org/submission/1391002/Can-Firebird-gain-against-MySQL

Re:Why not Firebird?

[2phar]

What Firebird does, it does well. The thing is, if you have a choice for a backend server, PostgreSQL really delivers all the same functionality as Firebird, but a whole lot more. Some of the gaps with Firebird are: No inherent replication solution, no GIS support (like PostGIS), more limited range of SQL functions, less language extensibility options (functions in Firebird can be added, but only through writing platform-dependent DLLs), no XML support (dunno if PostgreSQL is much better on XML).

Re:Why not Firebird?

[solaraddict]

DELETE FROM yourtable;

Care to explain how replication is a backup for that? IIRC, it will faithfully replicate the delete on the slaves. Repeat after me: replication...is...not...backup.

Re:Why not Firebird?

[BigJClark]

We use a firebird DBMS at work, and it is an fairly decent flat file solution, but its not on the level of MySQL.

It can be used to serve multiple clients, I've read into people storing massive amounts of data in it for testing purposes, and it does have some cool features (Instead-Of triggers on views), but I think MySQL is the more "mature" solution.

Re:Why not Firebird?

[Bill, Shooter of Bul]

True that. I did not mean that. I meant that replication can make backups easier. IE, you take the backup from the slave as to not interrupt the master that's handing the live requests from the app. But, none the less, I must make it up for leading some people to believing I was preaching unsafe practices.

So,let me be clear ...

Replication is not back up.
Replication is not back up.
Replication is not back up.
Replication is not back up.
Replication is not back up.
Replication is not back up.
Replication is not back up.
Replication is not back up.
Replication is not back up.
Replication is not back up.
Replication is not back up.
Replication is not back up.

Re:Why not Firebird?

[solaraddict]

Ah, I see what you were saying; that makes sense now. Thank you for the clarification.

Yeah right

[sletraBydnaR]

Trust me, says the devil.

speechless

[unity100]

noone will be able to confess anything after your mind-stunning confession about feeling the urge to polish your porpoise in in appropriate locations due to windows logo

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:Windows kernel-mode code signing

[josath]

It's not that hard to get a certificate from a commercial certificate authority. Sure it costs some money, but then so does buying a SSL certificate, or a Java code signing certificate, etc.

You can get them from Verisign, Equifax, GlobalTrust, etc. Then you avoid the 'Test Mode', and you also have the advantage of being able to sign your application itself, which gives you a nicer warning dialog than the default 'This application has no digital signature' popup you get when trying to open a downloaded EXE (which I'm sure nobody even reads anymore, so it's a moot point).

That whole controversy about "omg windows will only allow approved drivers!11!" is really just a joke, I'm surprised people still believe in it.

Shared web hosting

[tepples]

And a big reason that MySQL is supported by more web applications than PostgreSQL is because more web hosting companies offer MySQL than PostgreSQL. A lot of hosting companies, such as Go Daddy, require customers who want PostgreSQL to upgrade from shared hosting to a more expensive virtual dedicated server.

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:Shared web hosting

[Luke has no name]

[citation needed]

I think it's a cycle, if your assertion even holds. I could theorize that, being more popular, more tools and features were put on top of MySQL to make it more friendly.

Re:Shared web hosting

[n_are_q]

As someone who has used both, I don't really understand where this sentiment is coming from. PGAdmin is a way better GUI tool than anything that comes with myqsql, and at no point did I ever run into something that wasn't clear and easily accomplished with the GUI for the basic stuff you'd use mysql for. Of course outside of the ease of use argument mysql is a joke compared to postgres too :).

Re:Shared web hosting

[mAriuZ]

These days it's easy to build a simple FLAPS Firebird+ Linux+ Apache+ Php+ SSL style or FUNP Firebird + Ubuntu+Nginx+Php/Python/Rails virtual server

https://docs.google.com/present/view?id=ddzwj4jw_112ddwrd52h

You can buy a simple vps and install what you want there (Firebird php , rails ,
django ...)
I give you some options but there are more to choose from
http://www.linode.com/
http://www.hetzner.de/en/hosting/produktmatrix_vserver/vserver-produktmatrix/

It's quite easy to install and start on ubuntu for example
https://help.ubuntu.com/community/Firebird2.5

(i didn't included howto connect and howto secure the server)

Re:Shared web hosting

[tepples]

You can buy a simple vps

That's the problem. Hosts such as Go Daddy charge more for a VPS package than for a shared hosting package.

Re:Shared web hosting

[TheRaven64]

PGAdmin is relatively new. The 'MySQL is easy' attitude is a meme that's been around for over a decade. It's now about as easy to install and administer either, but people who learned to run MySQL back because they heard that Postgres was hard haven't bothered to learn that this isn't the case anymore.

I am reminded of the wise words

[GoochOwnsYou]

Its a trap!
- Admiral Ackbar

Re:Its a trap

[zero0ne]

[citation needed]

So, what you're saying is ...

[Pax the Evil]

... that MySQL is the "Microsoft Access" of the FOSS world?

Re:So, what you're saying is ...

[mAriuZ]

That is a good one : mysql brings msaccess crapiness to the FLoss world
also with oracle price tag included

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.

Missing tag

[erixm]

How can this not be tagged itsatrap?

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

Re:Its a trap

[Anonymous Coward]

For years I heard the MySQL is released under the GPL and is free. Its [sic] open source, so long as I don't modify MySQL I won't have to pay for it if I want to use it as the database for any applications I write. Not true.

Indeed. Even if you modify MySQL, you won't have to pay for it. However, due to trademark law you may not be able to call your modifications "MySQL".

A few years back I contacted MySQL with some questions about using it as a DB backend for a small invoicing program I wanted to sell for 300 per install. MySQL's representatives informed me that even if I don't include MySQL in the installer, I am liable for $650 per license.

Did you tell the representative whether you intended to supply your source code to your customers?

I asked, "Isn't MySQL free under the GPL". "No", they informed me, "not if you want to make a profit"

I find that hard to believe. Were you talking to a lawyer or a sales representative?

Now that Oracle owns MySQL, and Oracle has a habit of suing companies for (TomorrowNow / SAP) using their products, every piece of code I have the uses MySQL is quickly being ported away.

That's a sane decision, I think. I have the same sentiment towards Berkeley DB (bdb), although that seems to contradict the track record Oracle is alleged to have.

MariaDB

[Pharago]

It's doing just fine, thank you very much. http://mariadb.org/

Re:Its a trap

[Doug Neal]

This is sort of true, although it's a really bad way of putting it.

MySQL the server, is GPL. You don't need to buy a license for it. There are no restrictions on what you use it for. Same as any other GPL software, the only thing you are restricted from doing is distributing non-GPL'd modifications to it. All standard stuff.

The way they get you is via the client library, which is also GPL, and not LGPL, which is very important: In order to use the server you need to link your code against the client library. This means that in GPL land, your code is classed as a derivative work of the client library and must also be released under the GPL. If that's not compatible with your aims, you need to pay for a license of the client library that will allow you to link it as you please.

There is of course nothing to stop you writing your own client library, but really, who's going to bother for a commercial project? It's going to be less risky, and probably cheaper, to just buy the license.

It's a simple but effective way of making sure that FOSS software projects use it under FOSS terms while proprietary projects use it under commercial terms. Fair enough, IMO.

Already been using 5.5 beta...

[js_sebastian]

..for a few months on one installation where I needed partitioning. Did not have any crashes/trouble with the beta, but I was running only like 10 different queries in total on this server so it's by no means a comprehensive beta test. Good to see a real release.

The sad state ofthe American education system

[tomhudson]

The original quote:

switched to Postgres because MySQL lacks deferred foreign key constraints. Real world example: Model a city<-->state relationship where every city must have a state. Now, require that every state have a capital city. Now, enable foreign key constraints. Oops, we just broke MySQL.

What's the matter, did you fail geography? The example given was just plain wrong. Not every American city has a state, and not every capital has a state, not even in the Lower 48.

Looks like Canadians know more about American geography than Americans.

-- Barbie

the future?

[mu51c10rd]

...that they see it as a complementary technology to their proprietary Oracle database.

They forgot to add..

...for now.

Re:GPL linking

[Bill, Shooter of Bul]

Ah yes. I think I deleted the rest of my post last night that went into this. Its tricky. The definition of "derived work" is ambiguous. But, In my own non lawyer sensibilities, I think it would be a bit ridiculous to call something that just used mysql specific sql statements, but didn't link against anything prohibited a derivative of Mysql.

Anyone care to hack in all the mysql-isims via clean room reverse engineering to Sqllite, just to remove this possibility?

When the standard isn't implemented

[tepples]

When there is a known standard to use

...then you have to either A. wait for the standard to get implemented, B. implement it yourself (which requires skills that your employees don't necessarily happen to have), or C. work around it. Case in point: the SQL 2008 MERGE statement, designed to replace things like the proprietary INSERT INTO ... ON DUPLICATE KEY UPDATE statement that MySQL had used, isn't implemented by the major players yet to my knowledge. Until PostgreSQL and MySQL both implement the standard, applications designed to run on both the good DBMS and the preinstalled DBMS have to use quirks to work around the deficiencies.

TLS cert is free; Authenticode cert isn't.

[tepples]

It's not that hard to get a certificate from a commercial certificate authority. Sure it costs some money, but then so does buying a SSL certificate

A certificate for SSL/TLS is free from StartCom CA. The primary expense in SSL/TLS is getting a dedicated IPv4 address for incoming connections so that your HTTPS server can communicate on port 443 to Windows XP and other clients whose SSL stack can't SNI. An Authenticode certificate, on the other hand, cost $199 per year the last time I researched it, which was twice that of an iPhone certificate, and one had to have an established business to qualify for one.

MySQL Workbench and Open Office Base

[jtnix]

While you are largely correct at this point in time, I suspect a combination of OpenOffice 'Base' the Access equivalent (recently acquired by Oracle) and MySQL Workbench, a consolidation of several open source MySQL tools from Sun which has, since acquisition, been on a solid 2 week release schedule. Gee, I wonder if Oracle management had anything to do with that.. I suspect both Base and Workbench to be continually developed and marketed to fill the open source, whiz-bang Access gap to further erode M$.

And then Look Out, because we'll have an order of magnitude more crazy DB driven apps that 'just work' developed by Ubuntu outfitted mom-and-pops and non-profits the world wide. And that's good business for me, because it will be a hell of a lot easier to optimize those apps given it's MySQL underpinnings than any Access abomination.

Re:MySQL Workbench and Open Office Base

[jimicus]

That actually makes a lot of sense - it would mean that Oracle customers would have an alternative to Access they can roll out to desktops which offers a clear upgrade path to a proper client-server database app. And they can sell consultancy services when it becomes apparent that what works fine on one person's desktop doesn't translate so well to the client-server database app.

Re:The sad state ofthe American education system

[tomhudson]

The criteria were:

1. A city that is not in a state
2. A capital that is not in a state

Washington, DC, fits both.

Additionally, every city in Puerto Rico qualifies as a US-owned city that is not in a state. (Puerto Rico is one of several unincorporated US territories).

Since 1917, people born in Puerto Rico have been given U.S. citizenship. United States citizens residing in Puerto Rico, whether born there or not, are not residents of a state or the District of Columbia and, therefore, do not qualify to vote, personally or through an absentee ballot, in federal elections

There are also other U.S .territories, many with cities or towns, and some with capitals, that are not part of a state.

Sure, people tend to overlook the territories, but Washington?