Slashdot Mirror
MySQL Founders Reunite To Form SkySQL
mikejuk writes "The founders of the original MySQL, the open-source database, are getting back together in a merger between Monty Program and SkySQL. SkySQL was created by around two dozen former MySQL executives and investors after Oracle bought MySQL from Sun. Widenius started Monty Program AB and created the MariaDB database from some of MySQL's open source code. The merger will provide a stronger rival to MySQL, so reassuring users who are worried about Oracle's future plans for the database."
Anything that takes Oracle out of the way of MySQL gets my vote!
...Hasta la vista, Baby!
Table-ized A.I.
If I understand the release correctly, this will mean that MariaDB will continue with organizational support from SkySQL. Sounds like they are well on the road to being the top MySQL "distribution" which is good reassurance for making the switch.
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
But Monty doesn't have a daughter named Sky?!
All generalizations are false
Monty needs to stop crying about what Oracle is / will do with MySQL. He sold MySQl walkng away with almost A BILLION DOLLARS! If he cared that much, he wouldn't have sold.
The majority of the internet would disagree with you. I'm not a big DB person but I do use MySQL on my hosted website. I'd happily go to Postgresql if my provider offered it though.
"general absence of programmers, engineers fails to deter C-levels from merging two companies in an effort to become a more robust alternative to databases that still arent hadoop, couch or hypertable"
Good people go to bed earlier.
The majority of the internet would disagree with you. I'm not a big DB person but I do use MySQL on my hosted website. I'd happily go to Postgresql if my provider offered it though.
So many people (99%-ish?) use MySQL as a multi-user sqlite, to organize a few thousand rows for personal sites. And that's great, Mysql is well understood and lived long enough as a fully open source project to be a good choice. But people who use databases for *serious* work (not to devalue anyone's blog, but serious here means many tables of 1M+ rows) there is a vacuum in the open source space since the innovation that used to happen at MySQL is now kept private.
Understood, but as far as I am aware, MySQL never pretended to be that. I've been aware of MySQL for over a decade and used it off and on. I'm not a DB admin so take what I'm saying with a grain of salt. But MySQL was always the "Use it for your website!" DB package. Facebook seems to get a lot of use from it, granted they use a patched version.
Postgresql was supposed to be the heavy lifter if I remember right. Is this not the case?
There are several good open source/free to use database engines. MySQL is not one of them.
That depends on what kind of user base you want. If you develop a web application for installation on hobbyist web sites, something comparable to WordPress or phpBB or MediaWiki, you need to make it compatible with MySQL because so many budget web hosts provide only MySQL (and possibly SQLite).
The majority of the internet would disagree with you.
The majority of Internet users use web applications as a user, not as a server administrator, and definitely not as a developer.
I'd happily go to Postgresql if my provider offered it though.
Have you considered SQLite? Some MySQL haters would claim that some of SQLite's features are better even if the concurrency is worse, and if your site is on a plan smaller than a VPS, it probably isn't popular enough to need heavy concurrency yet.
Let's all back these guys so that they can sell us out a second time later down the road, when the community makes them successful again.
Facebook at 13M queries per second would like to say "hi".
If you aren't part of the solution, then there is good money to be made prolonging the problem
There are several good open source/free to use database engines. MySQL is not one of them.
On the other hand, it's the only concurrent DB I would consider to be a perfect match for PHP. ;)
Install windows on my workstation? You crazy? Got any idea how much I paid for the damn thing?
I was just coming around to the idea I might explore MariaDB next time I needed to do something, where normally I've been turning to MySQL. Is SkySQL replacing that, now?
Also, do any of the large, inexpensive web hosts (hostgator, dreamhost, servint, etc.) provide either of these alternatives yet? Because frankly I'm not going to do a lot of personal configuration or pay a lot extra just for the novelty.
The Quirkz Handbook of Self-Improvement for People Who Are Already Pretty Okay
Whilst I agree with you (having sweated blood over fixing corrupted MySQL tables more times than I'd care to mention), and wish there was more support for more robust databases, it seems most of the world hasn't caught up with this idea yet.
Not only do most webhosts only support/provide MySQL (IIRC due to Postgres and others not having quota support), but there's a vast swathe of projects out there that don't have support for anything other than MySQL. Heck, I was looking into upgrading my home install of Gallery only to find out that support for Postgres (or even SQLite) was dropped completely:
http://codex.galleryproject.org/Gallery3:Requirements
A similarly disheartening thread from Piwigo can be read here:
http://piwigo.org/forum/viewtopic.php?id=18008
Sadly, for a bewildering array of software it's MySQL or nothing. It's partly this monoculture that has, IMHO, contributed to much of the animosity against MySQL, since users are unable to even contemplate trying out something else.
£0.02
Moderation Total: -1 Troll, +3 Goat
1. Create a popular but flawed FLOSS product (MySQL).
2. Build a business atop flawed FLOSS product (MySQL AB).
3. Ca$h out by selling your baby to formerly glorious tech company on the ropes (FGTCOTR, aka SUN).
4. Profit!
5. Leave FGTCOTR after a tasteful waiting period to start your own company DOING THE SAME THING YOU JUST SOLD because you can fork the OSS codebase you just sold.
6. Take public potshots at EVIL Corp (who very predictably acquired FGTCOTR) for mismanaging the baby you sold (because EVIL), while flogging your fork of the product you sold as a viable alternative (FLOSS, to cloak yourself in the veneer of legitimacy because you can live off of steps 3 and 4).
7. Reunite to form company that does the same thing the company you sold for big $$$ did, to compete with the product you willingly relinquished control over.
8. GOTO #1?
I can't decide whether to admire Monty for successfully gaming the system, or condemn him as an amoral manipulator who wasted no time screwing over the very people he sold out to at the earliest possible opportunity.
Grudgingly, I lean toward admiration. Nicely done, sir.
That said, I avoid MySQL as the half-baked relational DB pretender that it is and use PostgreSQL whenever possible. Better technology without the drama. I have never regretted PgSQL once, MySQL many times.
Ok honestly, what has Oracle done with MySQL that has been so bad? They've been pretty good stewards. MySQL 5.6 came out and even included full text search for InnoDB. I'm pleased with the product and it's progress.
This smells like the Jenkins/Hudson gayness... All these projects are forking because of big bad Oracle, before Oracle has even done anything. Good god, the open source community is LUCKY to have a corporation that is willing to sink dollars into an open source project. If that means giving up a little control, I'm cool with that. If they try some bullshit, we can fork it. Stop the friggen whining until then. You cry wolf enough times and the community isn't going to be there when you really do need them.
So I have a brilliant friggen plan. How about the circle jerk of founders in the SkySQL project go to Oracle and offer and olive branch? There would be rainbows and unicorns and one code base. Wouldn't that be best for the community?
"The merger will provide a stronger rival to MySQL, so reassuring users who are worried about Oracle's future plans for the database"
Aren't they the same guys that sold MySQL the first time? How will the new alliance be any more reassuring?
But MySQL was always the "Use it for your website!" DB package.
Hell, it's one quarter of the popular LAMP combo.
/* No Comment */
MySQL (or MariaDB, or SkySQL) are not suitable for use in banking, but the vast majority of database applications don't have the same requirements of banks. Banks have extremely high data integrity, retention and security requirements. Armoured cars have extremely high security and cargo integrity and retention requirements. But vast majority of transportation applications don't require armoured cars.
MySQL is demonstrably scaleable and is secure and robust enough for the vast majority of applications. It is used extensively in health care - which has fairly high privacy and data retention requirements. It's a matter of using the right tool for the right application. Sledge hammers are useful for breaking concrete, not so much for framing. Statements like "because banks don't use MySQL, you shouldn't either" are just ignorant.
If you aren't part of the solution, then there is good money to be made prolonging the problem
This soap opera is getting way too confusing. Way too much money, way too many project names. In the end, whatever they come up with to circumvent Oracle, they will just sell to the next highest bidder for another billion, then rinse and repeat.
It seems the only way for us to circumvent all this BS is not to use anything affiliated with Oracle, MySQL, or its creators.
To be fair, I think if Facebook were starting over today with a clean codebase, and know they were going to grow into such a massive enterprise, they might have made different design choices. As it is, they are committed to MySQL and have tuned, optimized and tweaked the hell out of it to suite their requirements.
If you aren't part of the solution, then there is good money to be made prolonging the problem
SkySQL is a sequel to MySQL. Whose sequel? Your sequel? My sequel? SkySQL.
MySQL was sold to *Sun*, who were good stewards of the code and community. Then Sun was taken over by Oracle.
Diarrhea that sprays all over the toilet bowl at high speed is still shit.
bad ... good ... pleased ... smells like ... gayness... because ... bad ... Good ... LUCKY ... willing ... means ... little ... cool ... try ... bullshit ... can ... whining ... cry ... community ... really ... need ... brilliant ... circle jerk ... offer ... rainbows ... unicorns ... best ... community?
Well, that's like, your opinion, man.
I think the FOSS community would probably have been fine if MySQL had remained with an independent (and profitable) Sun. But Oracle is not Sun. For me, personally, the Oracle v. Google lawsuit pretty much gave notice that Oracle would go scorched earth on anyone who used "their" open source properties in ways they didn't approve of.
If you aren't part of the solution, then there is good money to be made prolonging the problem
Because the people who came up with MySQL shouldn't be touching PostgreSQL code.
SELECT Name, Date, Time, Lat, Long, Photo FROM humans WHERE Name = "Sarah Connor"
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
But it's high speed!
There are two types of people in the world: Those who crave closure
To be fair, I think if Facebook were starting over today with a clean codebase, and know they were going to grow into such a massive enterprise, they might have made different design choices. As it is, they are committed to MySQL and have tuned, optimized and tweaked the hell out of it to suite their requirements.
I believe a Facebook engineer once stated exactly what you suggest. I'm sure they would have gone another direction but just the fact that Facebook is able to use it like it does seems to imply it's a pretty capable open source project, despite its flaws.
In reality, MySQL is sort of a poster child for open source software. It's a case where a company started using it to keep expenses down. Out grew it but because they had the source they were able to modify it for their use and contributed it back to the community. I can't think of a better example really.
Understood, but as far as I am aware, MySQL never pretended to be that.
Monty has long made excuses for MySQL's inadequacies (most notably the pre-INNODB argument that foreign key constraints weren't really that important and you could just enforce such constraints in software). So there *were* attempts to pretend that MySQL was a "serious" database equivalent to better alternatives. Many of the shortcuts MySQL uses (or used - some of this is historical) apply to edge cases that aren't apparent to "I'm not a DBA" developers creating simple LAMP applications. But when you *do* run into one of those edge cases, then you quickly feel the pain and realize that it could have all been avoided.
Here's a good read: http://grimoire.ca/mysql/choose-something-else
Facebook at 13M queries per second would like to say "hi".
Facebook gets that throughput from the sharding system that they wrote - the individual MySQL databases aren't doing anything particularly impressive.
Socialism: a lie told by totalitarians and believed by fools.
That shit scales horizontally, it must be web-scale.
Facebook uses hundreds of MySQL "servers" and dumb nodes in a load-balanced name-value pair object database.
Think of using a relation database like a NoSQL DB.
I normally mod down both trolls *and* the people stupid enough- or with too little self-control- to be lured into replying to them.
However, given that at least three ****wits have already modded you "informative" for this post, I feel obliged to point out that the original comment is more than likely a Joe job (as well as a troll), and pretty obvious one.
Matter of fact, I wouldn't discount the possibility that "your" comment was made by the same person as the original, but the fact it was modded up shows that at least some people believe otherwise.
Seriously, I can't believe that there are Slashdotters stupid enough to take this crap at face value.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
Ulf Michael "Monty" Widenius, is the main author of the original version of the open-source MySQL database and a founding member of the MySQL AB company.
Thanks for the link
Yeah, Wikipedia ain't serious enough.
You're confused. The problem is not MySQL, rather, it's tying an application to ANY specific database. No two databases implement all of the features of a modern relational database in the same way. Transactions, concurrency, prepared statements, stored procedures, referential integrity, mem caching, connection pooling, etc, are all implemented differently and in some cases not at all, and imply database specific limitations on the application. DB Abstraction layers, Object Relational Mapping, code generation/scaffolding, etc. all help, but don't entirely remove the need for regression testing, optimization and even kludges for each different database.
However there are good reasons to design for a single database. If, as in the case of Facebook, your application will only EVER be hosted in a single environment, it makes no sense to support multiple environments. Facebook doesn't sell an application to the public to be downloaded and hosted at your favourite ISP, they offer a service that is hosted on their own infrastructure.
If the performance requirements are such that regardless of which database you choose, it would require extensive tuning of both the database and the application, it makes little sense to do this for multiple databases.
If you aren't part of the solution, then there is good money to be made prolonging the problem
Regardless of what database they used, to achieve the scale and performance they require would require similar clustering, memchaching, partitioning, sharding, load balancing, etc. There simply isn't an out-of-the-box database that can scale to this level without resorting to the kind of complexity that facebook has implemented.
If you aren't part of the solution, then there is good money to be made prolonging the problem
We're on a mission from God.
I don't think that's quite true - Hadoop works just fine for the analysis backend at Facebook, which stays just as busy. The problem lies with legacy systems written for a RDBMS that could just as easily have been written for a NoSQL DB. If you were starting from scratch today, NoSQL makes a whole lot of sense and scales out-of-the-box quite well - but that's useless to the existing code base.
All of the major cloud providers have their own version of scale-by-sharding systems for RDBMS, but they're mostly kept internal for now. Give them time to mature and they'll be available as products.
Socialism: a lie told by totalitarians and believed by fools.
He's been posting these emails in almost every thread for the last few days. He's the "my fast pc" spammer for some unknown Linux website. If you check his Contact page [linuxadvocates.com] you'll see I am not him as he doesn't like his email address displayed in a scrape-able way
Are you really that dim? I already linked "joe job" and you still managed to miss the entire point.
Let me explain it in *very* *simple* *words*. The person that posted the original "spam" above is probably *not* "Dieter T. Schmitz" as they claim, but someone else who is (a) trying to make him look bad (b) trolling, and/or (c) stirring up trouble by pretending to post spam under his identity.
Your logic is circular- you're already assuming that "he" posted the original comment, when in fact "he" probably didn't and "he" isn't the same person.
Good grief...
He's the "my fast pc" spammer for some unknown Linux website.
This *does* explain a lot... about you. If you're one of the idiots that genuinely believed the "My Clean PC" comments were spam- even long after anyone with half a brain could see it was being kept going by trolls- then you're even more gullible and blinkered than I thought you were.
Anyway, I only posted my original comment as a heads up to those so lacking in common sense that they might have planned on harassing the alleged "spammer".
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
Facebook has been profitable since 2009.
If you could get rid of MySQL and PHP, LAMP would be nearly as disappointing.
Seriously if PHP and MySQL are your flagship products you don't have any clue how disappointing your offering is. If you did, you wouldln't be bragging about them.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Memcached would like to tell you that MySQL isn't doing shit you think it is doing. Memcached also says 'please to be getting a clue'
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
There are multiple that will do that very thing and in fact have been.
Facebook is a popular website. Thats where it ends.
There are multiple out of the box solutions that will in fact work as well as MySQL did 'out of the box' Since they are in no way using Out of the Box MySQL your entire statement is retarded and pointless. You're trying to compare a custom version of some software to an off the shelf generic version and pretend its a fair comparison.
Its not.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Its not. Wikipedia's database load is rather low. Serving mostly static content from memcached can be done with any number of databases just as easily.
Its cute how you guys point out websites with a lot of traffic as if they indicate database load in some direct way.
Why VISA starts using MySQL for transactions, then you can start talking about it being serious.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
MySQL is only good enough to keep unimportant information.
Did you not see this line?
Facebook IS loosing quite a bit of money.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Yes, we know PHP is crap too.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
With any decent database you can write ANSI SQL for 99% of the work and never have to touch it again (unless you are going to use a POS like MySQL later).
There is a world of difference between the changes needed to go from SQL server to Oracle (as you say, stored procedures and other supersets of the ANSI spec) vs going to/from an incompetent implementation like MySQL.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
You have no idea what the term scorched earth means. It in no way applies to what they've done. Stop using words you don't understand just because you heard someone else say it and it sound scary evil to you.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Thats what they did isn't it? They sold out, then took their toys and left, and are going to do it again.
Congratulations, you have illustrated to every business in the world who's paying attention why it would be absolutely fucking stupid to invest any money in a GPL project. Your greed has effectively manipulated the concept of FOSS into something more evil than even what Oracle does.
Oracle is up front about stabbing you in the back. They'll tell you they are going to do it. This prick is just a two faced fuck who will never get support from anyone other than GPL fanboys.
Anyone with any intelligence is already distancing themselves from this guy, he says one thing while his actions show his intentions are completely different than his words.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
You could also call it the poster child for closed source software: a company chose open source because it was cheaper in the short term, and now that they've outgrown it they're stuck devoting countless engineering hours to make the solution work anyway. A closed source system might have cost (a lot) more up front, but may also have required (a lot) fewer engineering resources long term.
Not that I'm saying this definitively true for the Facebook case study. Rather, my point is we just don't know. Calling this case a poster child for anything is nuts, because we just don't have near enough information. It's funny that everyone keeps bringing Facebook into this at all, being so far from the typical deployment.
That out of the way, there's really no good reason to use MySQL or it's derivatives any more. Ever. Postgre is superior in pretty much every way. Sure, MySQL is good enough for some things, but that's like saying you'd choose a CRT monitor for your computer when you have a perfectly good LCD right there ready to go. Sure, CRTs still work just fine, but no one in their right mind would choose one over an LCD unless they have some really exotic requirements.
Okay, we'll rework it, but will "asshat" be okay with you?
Table-ized A.I.
Why does it sound like a Russian word for "diarrhea" when the 3 merge? It would just invite too many "In Soviet Russia" jokes.
BUT, we need a whackjob name to compete with "Postgresql". In the FOSS world, sounding squishy, green, and crippled is "street cred" (gimp, grep, gnu, lisp, etc.)
Table-ized A.I.
My pleasure.
Well, you're half right....it isn't 2001.
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
Depend on how you define "best". But if market followed the technical best we all would be using. don't know, maybe OS/2 and programming in Ada. As we aren't in that idillic world, we have to deal with what is in use this one. Sometimes you have to live with "good enough for most simple uses", even if are used in environments/ways that are beyond its capacity.
Maybe this could give you a hint. Looks like a small factor, but is critical for validating whatever you want to do with the code. If is the start of a trend, better to be in a safe zone, i.e. elsewhere.
Oracle has been good stewards of MySQL. But it's like saying MS has made commendable effort to embrace open standards. Something doesn't feel right. Even at a superficial level, I dunno if it's Larry's desire to own a Hawaiian island while having the look of a Bond villain, or Ballmer -- just being himself -- the mistrust seems justifiable.
As for SkySQL, I just wish the original band members would go away. I mean, what happened to their billion dollar buyout? Hookers?
I've heard this a lot - this idea that PostgreSQL has better transactional integrity than MySQL, but most applications don't need it, and so they are fine using MySQL instead.
That's a good reason to not rule out MySQL, but it's not a reason to choose MySQL over PostgreSQL. What exactly are the reasons for choosing
MySQL/MariaDB/SkySQL over PostgreSQL? I don't know enough about databases to answer this myself, but every time I read about this question, all I hear is "most people don't need PostgreSQL so therefore they shouldn't use it", without much explanation about why PostgreSQL would be worse in any given situation.
If an armored car had no drawbacks to a normal car, there'd be no reason not to use one for commuting to work. But obviously the drawbacks of armored cars are that they are heavier and use more fuel; what are the drawbacks of using PostgreSQL?
The real drawbacks of using PostgreSQL: your hosting may not support it, the application you want to use may only support MySQL.
In the olden days, MySQL was synonymous with using the MyISAM storage engine, which was not very reliable but was faster than the alternatives (the InnoDB storage engine for MySQL or PostgreSQL.
MySQL+MyISAM was also far easier to setup and configure than MySQL+InnoDB or PostgreSQL.
And the logic was that for most websites, speed was more important than reliability. There are, however, two problems with that logic.
Problem 1: Your website may not need full ACID compliance level reliability, but it needs some. It's mighty inconvenient when then system crashes and boots to a corrupted database. It's like when Windows used FAT32 instead of NTFS.
Problem 2: Nowadays, MyISAM is actually only good at simple, read only, workloads. Complicated queries or writes tend to bog it down. And even simple websites have growing amounts of both.
Nowadays, InnoDB has improved to the point it is, in general, faster than MyISAM while providing better reliability (and it's finally been made the default MySQL storage).
PostgreSQL also improved a lot in performance. In particular, it tends to be better at handling complicated queries and at scaling better in multi-CPU systems.
Shopping around is fine when establishing a new web site or if the installation of a new application requiring PostgreSQL coincides with the annual renewal of one's hosting plan. For users looking to add your application to an existing web site on a MySQL-only plan, your PostgreSQL-only application is going to lose out to a competitor's application that supports the hosting plan that the site operator has already paid for.
That out of the way, there's really no good reason to use MySQL or it's derivatives any more. Ever. Postgre is superior in pretty much every way.
Other than that PostgreSQL isn't part of the plan that a lot of shared web hosting customers have already bought. Hosting companies tend to consider PostgreSQL itself exotic.
Sure, CRTs still work just fine, but no one in their right mind would choose one over an LCD unless they have some really exotic requirements.
Light guns are "exotic". Zero lag in games is "exotic". Shared web hosting is also "exotic".
I actually expect it to be better or at least the same as pg otherwise why not just switch over to pg?
If you're not starting from scratch, MySQL or whatever it becomes is better because migrating your existing MySQL based application is easier.
Sorry, but Oracle and MySQL are playing to different audiences. The number of Oracle database customers is a lot smaller than the number of MySQL users, but I doubt that you could justly claim that less money is involved, and it's the money that Oracle (the company) cares about.
That said, though the MySQL community has the largest number of users, that's not at all the same as the largest number of active database program developers. I'd need some evidence for any claim that the MySQL project has more active developers than any particular other project (and I doubt that the evidence is publicly available). OTOH, I will agree that the number of active developers is less significant than the quality of those developers, and the quality of the management of those developers. Perhaps this article is evidence of an attempt to improve the MySQL project's management of the developers. (I'm not convinced that it's evidence of movement in the direction of improvement, but it may well be evidence of an attempt at movement in the direction of improvement.)
I think we've pushed this "anyone can grow up to be president" thing too far.
PostgreSQL has a secure by default stance that can be frustrating the first time you use it. When you start a server, it won't be open to the world and ready to serve queries. You'll have to configure exactly how much access you allow instead. If your only criteria is "which system can I get up and running with the least work?", and a lot of developers fall into that category, you will probably find the strictness of PostgreSQL forces you to do more work. There is a similar strictness with what data can and can't be inserted into the database. If you're using PostgreSQL, you better be ready to distinguish between an empty string and a null value for example. That detail will be important and one you have to manage the implications of. And MySQL will make assumptions to quietly convert data to another type so that your code runs, in many situations where PostgreSQL will force you to eliminate the ambiguity with direct type casting.
MySQL apps get built faster, but on a non-trivial database you're likely to spend the application's entire lifetime occasionally shaking out weird bugs due to invalid data. PostgreSQL has few easy "let me ignore this right now" shortcuts. You do things by what's considered the right way to the PostgreSQL contributors, which relies on things like the SQL standards for guidance, and that is your only option. If you only care about getting things done now by the quickest and easiest choice, with no regard to the future, you'll use MySQL. To return to the car analogy, are you the sort of person who likes to buy an expensive car now that will likely be reliable for a few years? Or do you want something that costs less up front, but you'll have to pay for service regularly? Some people want to get out the door and driving today with no money down, and that's a MySQL car.
In addition to integrity issue being likely to introduce bugs, the other downside to always taking the easy way out is that if your application's standards for data integrity go up later, you have nowhere to go. There's a long list of nasty MySQL limitations that are unlikely to ever be resolved. The learning curve for PostgreSQL is something you pay for once, and then benefit from forever.
MySQL (or MariaDB, or SkySQL) are not suitable for use in banking, but the vast majority of database applications don't have the same requirements of banks. [..] MySQL is demonstrably scaleable and is secure and robust enough for the vast majority of applications. It is used extensively in health care - which has fairly high privacy and data retention requirements.
From what I've seen of healthcare software, it's nowhere near the level of quality you'd expect for such a field. Kind of bizarre that you or anybody else would accept less integrity for healthcare data than a bank.
Did Postgres finally join every other database and implement cross-database queries? Call me when they join the new century. My experience with Postgres was that their management interfaces were toe-to-toe as bad as MySql's, no cross database queries, and things like sharding and master-slave had to be implemented in your software.
. Define sqrt(x) as something really evil like (x / rand()), and bury it deep. Watch your coworkers go nuts.
MySQL (or MariaDB, or SkySQL) are not suitable for use in banking, but the vast majority of database applications don't have the same requirements of banks. Banks have extremely high data integrity, retention and security requirements.
Most people who don't think they don't have all those requirements simply haven't thought of what could happen in the absence of those requirements. It isn't unlike every time I see a poster asking for collections to help out victims of some apartment fire - apartment insurance is fairly cheap and yet many people don't even think about it, despite shelling out almost as much for cable TV as insurance would cost them for a year. People just don't think they need insurance until they do, and then it is too late.
Think about some database that has been collecting data for years. Now imagine that somebody does some data extraction from it and notices that some of the data looks inconsistent. You investigate and it turns out that under heavy load some records weren't getting stored by your database, or when some application error happens rarely that data is left in an inconsistent intermediate state. This has been happening for years undetected. Presumably if you're storing data for years it has some value, and now that value has been reduced. You might spend hundreds of hours coming up with ways to detect the problematic data and cleaning it up. Now, consider that if you had simply used an ACID-compliant FOSS RDBMS the problem would not have happened at all. Then when you investigate you find that using that database wouldn't have cost you anything more - the programmers simply used what they were more familiar with.
I'm sure there are cases where performance is more important than data integrity, but the latter should always be considered the priority as a default. Most people just expect computer systems to regurgitate the data that is input into them without error, and they don't think through the consequences of what could go wrong if this doesn't happen.
Right now I'm frustrated by the lack of Postgres support by FOSS projects. It is really annoying to be stuck with MySQL simply because the average college-age FOSS contributor doesn't understand the value of a database. The whole world runs on databases, and the typical CS program doesn't even talk about them. Sure, I grok the difference between CS and software engineering, but at least a theoretical treatment of the problems that databases solve would imbue graduates with a MUCH better appreciation for their importance.
I won't pretend to know exactly how Wikipedia load is distributed, but I'm guessing they have a non-trivial amount of updates, and surely their database isn't small. Sure you can cache everything, but that only solves the static pages served to viewing-only users.
And if only VISA level is serious, the world must be totally fucking hilarious to you!
Scorched earth means to destroy (burn) the land to deny your opponent the ability to sustain his army in the field. I used the term exactly as I intended; to suggest that Oracle is more than willing to destroy Java (or at the very least chill independent innovation) in order to win a hopeless IP battle against Google.
If you aren't part of the solution, then there is good money to be made prolonging the problem
Let me spell it out for the learning impaired. Scorched earth means to destroy the environment to win a battle by denying an opponent the environment needed to sustain his army. It's a strategy that has been used notably by Russia vs Napoleon and by the Soviets vs.Germany. You could also categorize the US Agent Orange tactics in Vietnam / Cambodia as scorched earth.
By attempting to exert patents and copyright protections to not only Sun/Oracle's Java implementation but to the language itself (interface specifications) Oracle was more than willing to destroy the community that made Java successful in order to win a battle with Google. In the end they lost the battle and, at the very least, made the Java community even more wary.
If you aren't part of the solution, then there is good money to be made prolonging the problem
You can think of the database load at Wikipedia as only being generated by editors. And they have a VERY high ratio of non-editor traffic to actual editor traffic (even counting all the goddamn spam edits). Casually browsing Wikipedia shows you a stream of pages from cache, it is very unlikely that any of your requests actually even touch the database. If "good enough" distributed database systems are all we need then hell, seal up the Mysql code base and call it a day. But Wikipedia (or whatever great, world-changing project comes after it) can't survive for long on stale technology.