Ask Slashdot: Which OSS Database Project To Help?

DoofusOfDeath writes "I've done a good bit of SQL development / tuning in the past. After being away from the database world for a while to finish grad school, I'm about ready to get back in the game. I want to start contributing to some OSS database project, both for fun and perhaps to help my employment prospects in western Europe. My problem is choosing which OSS DB to help with. MySQL is the most popular, so getting involved with it would be most helpful to my employment prospects. But its list of fundamental design flaws (video) seems so severe that I can't respect it as a database. I'm attracted to the robust correctness requirements of PostgreSQL, but there don't seem to be many prospective employers using it. So while I'd enjoy working on it, I don't think it would be very helpful to my employment prospects. Any suggestions?"

Postgres

[Anonymous Coward]

It's seeing a constant rise in usage. Also many projects (spacewalk!) have it as the only viable alternative to Oracle.
Small companies with small to mid sized applications use it (see Jira or Fisheye, at Atlassian) as their main development platform.
Also you shouldn't use your USA'ish perspective and only do something because it will benefit your job or future employer. OSS is about sharing, fun, knowlege and getting better. Getting better at your job is a welcome side effect.

MariaDB

[jakimfett]

You might want to take a look at MariaDB [mariadb.org], it's a continuation of the MySQL project by the original author of MySQL.

MariaDB (fork of MySQL)

[Lordrashmi]

https://kb.askmonty.org/en/community-contributing-to-the-mariadb-project/ [askmonty.org]

We (yes, I work for the project) are always looking for new contributors. There are lots of exciting things happening right now.

Re:If "employment prospects" Are All That Matter .

[vlm]

I recommend setting yourself about fixing some of that long list of fundamental flaws in MySQL.

Traditionally, especially in 2012, this amounts to listing stuff like "doesn't have transactions" which was fixed back in Bush the Second's first term.
Shoveling thru obsolete FUD to find the truth is a harder job than you'd think, which also shows "good little worker bee" stick-to-it-ive-ness

Re:Find better prospects?

[Anonymous Coward]

+1

You don't see lots of people saying they use PostgreSQL online, because, no one has to bitch about it. It works, it works great, and its documentation is astounding.

Everyone uses it, you just don't realize it, again, because no one bitches about it.

I'll never touch MySQL after having used it for a product, what a POS

Re:Thinly veiled stab at MySQL

[DoofusOfDeath]

Actually I wasn't. I figured the /. crowd might have some knowledge about the relative acceptance and prevalence of the two databases in European business settings, and where things are moving.

For example, if the consensus was that PostgreSQL was so rarely used that it was a dead-end, then I'd suck it up and work on MySQL despite my misgivings.

But as long as PostgreSQL is showing some signs of life in a business setting, I'll perhaps try to pitch in on that.

I also figured that maybe there was some other up-and-coming database out there that I should take a look at. The /. community is good at bringing alternatives like this to light.

As far as flames, I should have been clearer about what I meant by "design flaws". I realize that it's somewhat subjective. What I should have said is that MySQL's behavior strikes me as a lot more surprising in some cases than does PostgreSQL's, and I didn't think that was going to chance. (Probably in a similar vein, I like strongly typed programming languages and compile-time correctness checks. I think it's a mindset kind of thing.)

Post is troll for a video

[Animats]

The post is basically a troll for a video. The video is based on an old list of MySQL 4.x gotchas, [sql-info.de] many of which were fixed in the 5.x series. Most of them involve things like the semantics of NULL in special cases, truncation of indexed strings with trailing spaces, and similar stuff that an application shouldn't be relying on. There's a comparable list of PostGreSQL gotchas [sql-info.de] from the same source.

MySQL has political problems, because Oracle owns it and would prefer users buy their commercial products. The future of the free version is uncertain. The problems in the video aren't the ones to worry about.

Re:Post is troll for a video

[Anonymous Coward]

There's a comparable list of PostGreSQL gotchas [sql-info.de] from the same source.

Only if "comparable" is code for "far shorter and less severe, with a greater percentage having been fixed in current versions".

Video is FUD?

[maitai]

Pretty much all the test cases from that video fail on MySQL if the sql-mode is set to traditional. MySQL will throw an error when data would be truncated, throws an error when you try to insert a NULL value in a NOT NULL column, refuses to alter a table if the existing data would be truncated, throws an error on an invalid date, on select only returns a warning for division by 0 but throws an error on an insert of division by 0, throws an error if you try to insert a string into a numeric column and so on.

I understand of course that the strict modes aren't enabled by default but they're easy enough to enable if you choose to. Via my.cnf, the command line when mysqld is started up or while connected to the mysql server itself (for just that session, or globally for all sessions).

I didn't run through all their examples, but mostly because I got bored and all their examples that I did try were throwing errors (except the select 1/0 one, which issued a warning) with the sql-mode set to traditional on MySQL (postgresql is also a sql-mode option but I didn't play with that one since I've never used it before).

Re:use mysql

[gmack]

If only they were actually edge cases(look carefully they mentioned one was a common Ruby on Rails mistake). MySQL's habit of pretending everything is alright when it's not has burned more than one of my previous employers.

But they missed the real WTFs like mysqldump creating dumps that need to be hand edited before MySQL will restore them or my all time favorite: mysql user authentication simply does a "SELECT * from mysql.users" and if the fields get reordered by a new MySQL release then logins will simply fail. The best part is that the officially documented way to fix that is a mysqldump followed by a restore which... deletes the table and puts the fields in the wrong order again. The last major MySQL upgrade of my employer's systems involved me starting the new install from an empty DB, restoring everything except the mysql.users table and recreating the accounts using a script.

Please don't pretend it's not a crap database. Those of us who have to deal with it every day know better.

MSSQL and PostreSQL use transactions

[Anonymous Coward]

With SQL Server, you set your transaction isolation level that you care about and then you begin a transaction - SQL Server will guarentee consistency in that transaction even if you're just doing multiple selects. And, SQL Server will not let you do a 'select for update'.

For example:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN TRANSACTION;
SELECT TOP 100 * FROM MyTable

-- Rows in MyTable are now locked

Locks are released when the transaction is commited.

Re:postgresql

[SplashMyBandit]

Absolute rubbish. Postgesql handles massive data sets and can scale down to run on modest hardware (with a multitude of choices in *free as in beer* operating systems). So I wonder what evidence you have to support your counter-factual statements?

Re:Video

[Fallingcow]

Most of what's shitty about it is the MyISAM storage engine, which does approximately dick-all for enforcing integrity. It doesn't even have foreign key constraints. IIRC it can't do transactions either. The trade off is that it's slightly faster for some operations *eyeroll*

If MyISAM is good enough for your application then you may as well—no exaggeration—just use MongoDB or something.

InnoDB is much better. It's got some of the same not-confidence-inspiring quirks shown in the video but at least it supports transactions and foreign key constraints.

Biggest remaining differences off the top of my head are that Postgres supports a shitload more data types and data operations (many through plugins) like stuff related to geographic data and key-value stores (hey, you got NoSQL in my SQL!), and that Postgres has real separate databases, not just separate schema like MySQL, the difference there being strict separation of the data, so you can't, say, do a SELECT across two databases or even tell that there are other databases if you've only got a user account on one of them.

Lots of other under-the-hood stuff, I'm sure, but those are the main ones I can think of from a user's perspective.

Postgres is way, way more powerful, MySQL is (slightly) more widely supported and (IMO) the free tools, both command line and GUI, for working with it are easier to learn and generally friendlier.

MySQL's a completely miserable excuse for a relational database if you use MyISAM; it's only a mostly miserable excuse for a relational database with InnoDB.

Re: MSSQL and PostreSQL use transactions

[Anonymous Coward]

IF you don't understand what isolation level serialable is then how the hell can you expect them to know why it can have such serious scalability issues. Ignorance is not a blessing, understanding what it does and why you don't want to use it is worth far more.