There Is No Reason At All To Use MySQL: MariaDB, MySQL Founder Michael Widenius

sfcrazy writes "In this exclusive interview MySQL founder Michael Widenius talks about the reasons of decline of MySQL, what Oracle is doing wrong and how MariaDB is fast replacing it. There are quite some interesting information in this interview. The take out of this interview is '...there is no reason at all to use MySQL 5.5 instead of MariaDB 5.5. The same will be true for the next generation.'" Of course, he has an economic interest in getting people to use MariaDB. Hard to argue that Oracle isn't evil though.

Comments

Postgres

[Anonymous Brave Guy]

...there is no reason at all to use MySQL 5.5 instead of MariaDB 5.5

Or Postgres, which is better than MySQL in numerous objective/technical ways and has been for years.

Re:Postgres

[Anonymous Coward]

I've heard that for years, but is Postgres better than MariaDB?

Re:Postgres

[Anonymous Coward]

...there is no reason at all to use MySQL 5.5 instead of MariaDB 5.5

Someone needs to tell him that the MySQL install base is significant, and changing to MarinaDB just for the sake of changing is going to cost a lot of small websites a lot of money for basically no measurable difference.

Re:Postgres

[kbolino]

The entire point of MariaDB is that it is a fork of MySQL which retains compatibility. It is, for the most part, a drop-in replacement.

Re:Postgres

[Trepidity]

True, but that's a bigger change. MariaDB is a drop-in replacement for MySQL, because it is just a forked/renamed MySQL. To switch to Postgres typically requires some porting.

Re:Postgres

[Bill, Shooter of Bul]

Postges seemed positioned to be an oracle replacement, while Mysql always seemed to be Web OLTP focused. I haven't seen a real useful comparison in years. So much has changed performance wise in Mysql, that it would be worth another look. One of the new features which really speeds up Mysql under heavy load is the thread pool, which isn't available in the free version oracle gives out. I think Maria DB has an alternative written by the same guy who now works for Maria.

Despite all of the Postgres users saying its much better, I'm not aware of any large websites using it as a backend at scale.

Re:Postgres

[Anonymous Coward]

Despite all of the Postgres users saying its much better, I'm not aware of any large websites using it as a backend at scale.

Why the fuck would you expect to know that? Most websites don't go round bragging about what database they use because it's of absolutely no interest to their users. You could be using huge Postgres-backed sites every day and never know it.

Re:Postgres

[chris.alex.thomas]

I'm confused, on my debian vps, another debian dedicated server and a further centos server, I could just apt-get the new software.

since it's 100% compatible and most small websites are not even going to touch the potential problem areas, how would this cost a "lot of money" ?

I could upgrade my database in the time it takes to download the packages, hardly a lot of money and even less of time.

Re:Postgres

[datavirtue]

In other news...Oracle is slated to release a new entry-level, free DB competitor named LarryDB.

Re:Postgres

[Anonymous Coward]

The entire point of MariaDB is that it is a fork of MySQL which retains compatibility. It is, for the most part, a drop-in replacement.

Sometimes that 2-3% difference will fuck you up.

Re:Postgres

[Anonymous Coward]

As far as I know, .org's backend has been postgres. It's conderiably harder to run a GTLD than a website, but according to your criteria, it's uninsteresting.

Re:Postgres

[Anonymous Brave Guy]

Postgres works just fine for backing web sites. I've built some of them myself, and so have plenty of other people I know. It has basically all the same advantages that MySQL used to have, plus numerous technical improvements on every level from everyday query support right up to heavyweight architectural tools.

As for your final points, well, popularity is not the same thing as quality, which is why MySQL has done as well as it has for so long, and just because you didn't bother spending ten seconds on Google before posting, that doesn't mean no-one operating a substantial web site runs Postgres underneath it.

Re:Postgres

[nitehawk214]

I've heard that for years, but is Postgres better than MariaDB?

MariaDB is a fork of MySQL. So the answer is a resounding yes, in every way, no matter what your target platform is.

Re:Postgres

[king neckbeard]

True, but in regards to the existing customer base, I wouldn't be terribly surprised if MariaDB has better compatibility. If you are migrating to a new version, there might be less trouble with MariaDB.

Re:Postgres

[Anonymous Coward]

...there is no reason at all to use MySQL 5.5 instead of MariaDB 5.5

Or Postgres, which is better than MySQL in numerous objective/technical ways and has been for years.

Once again, you miss a big piece of the picture. Maria is feature and syntax compatible for millions of existing applications. If you want to volunteer to rewrite those apps, or come up with some other migration scheme, have at it. Otherwise, the only thing you are talking about is people starting new applications, and that don't have to rely on what the hosting platform provides.

Re:Postgres

[hairyfeet]

But you gotta give the dude credit as he managed to sell a product and keep it at the same time, walking away with the code, the customers AND a big fat check. How he managed to get those fools to buy it without making him sign a non compete I don't know but he pulled it off, hell you might as play the WB "sucker" music when you talk about Oracle and MySQL.

So lets here it for old Monty, his balls are big and plentiful.

Re:Postgres

[AdamWill]

I'm pretty sure that Monty knows the size of the MySQL install base.

Re:Postgres

[Freultwah]

Good luck getting Wordpress to run with Postgres, at least without horrible hacks.

Re:Postgres

[Anonymous Coward]

Postgres was technically inferior in that it failed to include native replication for a long, long time. This alone shut it out of a lot of projects.

Re:Postgres

[Bill, Shooter of Bul]

Because many do write articles about their architecture and the tools they use. Twitter, facebook, google, yahoo, flickr, and other smaller ones have talked about their architecture and the tools they use. I've never come across one that mentioned postgres.

Re:Postgres

[Anonymous Coward]

True, but in regards to the existing customer base, I wouldn't be terribly surprised if MariaDB has better compatibility. If you are migrating to a new version, there might be less trouble with MariaDB.

OK, logically, riddle me this: how does a replacement possibly have "better compatibility" than the very thing for which it is a "drop-in replacement"? You see, it makes no sense. At most, it could only achieve equal compatibility, otherwise any substantial differences render it other than a drop-in replacement.

What was your point again?

Re:Postgres

[w_dragon]

I recently made the change on a firmware product. It took me 1 week of dedicated time, and about a week of test time. The big time waste for me was that we use mysql++ so I had to get that to link against the maria c libs, then build rpm's for everything. Other than that it was a drop-in replacement and a search-and-replace on the library to link against.

Re:Postgres

[Billly Gates]

As with superior technology like Windows 7, Linux, Chrome/Firefox, Python 3, it is always ignored due to legacy issues for people needing XP, Solaris/SCO, IE 6 - 8, python 2 etc.

As long as CPanel only supports MySQL and all the tools and code support mysql then postgresql doesn't have a prayer. Does PostgreSQL allow multiple user accounts like mysql yet? ISPs are in a catch 22 as well where customers do nto demand it because they do not support it, they do not support it as customers do not require it.

Re:Postgres

[pwizard2]

How well does MariaDB work with Qt 4.x? I haven't had a chance to test it for myself yet.

Re:Postgres

[Billly Gates]

How many api's and frameworks and apps that will freak if they do a string search for "Mysql" and just throw an exception??

Shit like this is why we still use IE 6/8 at work. If you are an ISP with 10,000 customers you will piss at least someone off, probably hundreds where they will seek a competitor if you did such a thing and cost them money. Maybe even sue you back to recoup the losses etc.

There is a lot of shitty software at there and that signature is not a characteristic of such the proprietary software world. Many customers use obsolete software because it if aint broke why fix it?

Re:Postgres

[Billly Gates]

None of the ones you described use Mysql anyway. Most use nosql for their backbone for webscale.

Re:Postgres

[Anonymous Brave Guy]

In many ways, WordPress : CMS :: MySQL : Database.

Both WordPress and MySQL are great success stories in terms of popularity and to some extent creating an ecosystem as a result. That doesn't make either of them particularly good technically. The way that WordPress was basically hard-coded to use a specific database is not any other database's fault. It's just another symptom of the questionable architectural decisions underlying it.

Re:Postgres

[Anonymous Brave Guy]

Postgres was technically inferior in that it failed to include native replication for a long, long time.

And that hasn't been the case since Postgres 9.0, which has been out for several years.

Also, I notice how you sneaked the word "native" in there, conveniently excluding all the external solutions that existed before.

Re:Postgres

[Anonymous Brave Guy]

Well, that statement was just damning enough to sound convincing while still being vague enough that it doesn't really say anything.

I believe the expected response at this point is now: [citation needed].

Re:Postgres

[gmuslera]

One reason to not go to postgres just yet is legacy code/apps/data that uses MySQL. If you put MariaDB instead of MySQL even the same binary data files should work, and you should get better performance and have room to do further improvements gradually (i.e. taking advantage of other storage engines) while all the rest keeps working.

If you will to start from zero in a new project/code, or have margin to reestructure everything that is db specific to Postgres, then could be a better option (or not, meatware also matters, and that includes programmers, admins and support with familiarity with one environment and not with the other).

Re:Postgres

[Anonymous Brave Guy]

As long as CPanel only supports MySQL and all the tools and code support mysql then postgresql doesn't have a prayer.

A prayer of what? If we're restricting the discussion to MySQL's stronghold, which notwithstanding some very large users I would argue is mostly cheap shared-hosting services, then neither Postgres nor MariaDB seems likely to get widely adopted any time in the near future. If we're talking more widely, about projects with a free choice about their hardware, software and hosting arrangements, then I don't think cPanel is particularly important in the big picture.

Re:Postgres

[gmuslera]

Facebook,Twitter and Flickr seem to disagree with you.

Re:Postgres

[i.r.id10t]

Of course, same can be said about Windows

Re:Postgres

[Anonymous Brave Guy]

Please notice that I only advocated for Postgres on objective/technical grounds. There are always questions beyond pure technical merit when choosing which technologies to use, and things like non-standard behaviour/vendor lock-in are just as damaging in MySQL's case as they can be in any closed/proprietary system.

I suppose in this case, the question is for how long MariaDB really will be a foolproof switch from MySQL, given the direction Oracle seem to be taking MySQL in these days. Your wetware and incremental change points are all fair and valid, but I suspect in time they will naturally weaken.

Re:Postgres

[Billly Gates]

But Yahoo, Redit, and the discuss commenting on websites all use PostgreSQL and Facebook uses No-SQL for its web front end. Hoopla stack if I recall and Yahoo uses no-SQL as well when latency is important.

Re:Postgres

[Miamicanes]

It depends. MySQL's championship role has always been lightning-fast reads from tables that change rarely and don't need much in the way of concurrency protection. I believe it was also the first free database to have a concept of partitioning.

The main problem with MySQL lately (past 5 years or so) has been the fact that it's really easy to get an inflated impression of its more "hardcore" abilities, and not discover until it's too late that MySQL's ability to handle things like failover, replication, partitions, and materialized views(*) aren't quite as capable as someone who's used to Oracle & reads MySQL's docs might initially think they are. I fell into that trap myself ~3 years ago, and got bitten pretty *hard* by harsh reality not living up to first impressions.

(*)'it's been a couple of years, but from what I remember, MySQL had a huge 'gotcha' with materialized views that rendered them mostly useless for me at the time... I think it involved having a function in the select statement that was a LOT more restrictive than the rules Oracle imposed at the time. I vaguely remember it was something like "Oracle couldn't index a MV if you had a function in the select clause, but MySQL didn't allow you to have a function *anywhere* in the select, even if it was merely transforming one value directly and deterministically into another." -- or something to that effect. I know that the whole matter of function-based indices is a problem in general, but I just remember thinking, "Oh, cool... MySQL supports them now!", then discovering later that MySQL's rules were much, much more rigid about what was and wasn't allowed than Oracle's (and Oracle's were pretty anal to begin with).

Re:Postgres

[Anonymous Coward]

But they do not webscale!

Re:Postgres

[Freultwah]

I did not imply that it's in any way PostgreSQL's fault, just that some very popular software projects/products are (stupidly, methinks) hardcoded to use a specific database, which kind of limits one's options somewhat and hinders choice. You'd go with the better system, but you're stuck with whatever database system is forced upon you. WordPress is not the only culprit. DAViCal, for instance, only runs on top of PostgreSQL.

Re:Postgres

[Anonymous Coward]

I have Percona on my machine and all the directories and binaries are still named "mysql".

And you're right, shitloads of buildscripts and so on would explode if they renamed any of this.

Re:Postgres

[Anonymous Brave Guy]

OK, it sounds like we probably agree on most of this then.

Re:Postgres

[kernelpanicked]

Umm cPanel does support PostgreSQL. I don't particularly care for it as I'm a MySQL guy, but I've done many a Postgres install on cPanel servers and enabled it in WHM/cpanel.

Re:Postgres

[goffster]

except if there was not that silly concept of requiring periodic
"vacuuming". This drives me up the freaking wall!

Re:Postgres

[SuperAlgae]

I think he is saying that upgrading to a newer version of MySQL could possibly be more difficult than going to MariaDB. If MariaDB forcuses more backwards compatibility than MySQL (I don't know whether it does), then that would not be too surprising. Of course, if you are not otherwise planning to upgrade your DB version, then doing nothing will be easier than changing.

Re:Postgres

[Anonymous Coward]

Disqus uses Postgres for storing comments and they get a ridiculous amount of traffic.

Re:Postgres

[Anonymous Coward]

I think the proper response is to assume that he is an untutored idiot and move on, at least until he can preperly [sic] present his argument.

Re:Postgres

[larry bagina]

I think he's referring to upgrades. What if Oracle releases MySQL 7.0 Enterprise Edition SE and 2013-02-31 is no longer a valid date? Meanwhile, MariaDB starts recognizing SLECT, SELCT, SLCT, INSRT, etc as keywords so shitty PHP programmers don't have to worry about writing valid SQL queries.

Re:Postgres

[Anonymous Coward]

openstreetmap.org I think uses PostgreSQL.

Re:Postgres

[cdh]

Except that auto-vacuuming has been in place since 8.4 or so, which came out years ago. You don't have to vacuum by hand unless you want to (and most of the time you don't need to).

Re:Postgres

[Anonymous Coward]

Or Postgres, which is better than MySQL in numerous objective/technical ways and has been for years.
No. That's not true. Not at all. Now go find that other guy that uses Postgress and go back to the uncharted island.

Re:Postgres

[Bill, Shooter of Bul]

I stand corrected. Reddit and Discus do use Posgress in a capacity I thought only Mysql was used. Yahoo, it should be noted, also has a large mysql presence.

Thanks for the info.

Re:Postgres

[king neckbeard]

It's a fork, so it had the exact same code at one point in time. It looks like the fork started with 5.1, so for anyone using 5.1 or earlier, they are on equal footing for compatibility. The advantage would go to whoever broke less in progressing to later versions, and I would not be surprised if that happened to be MariaDB.

Re:Postgres

[Slashdot Parent]

Or Postgres, which is better than MySQL in numerous objective/technical ways and has been for years.

It's been a while since I've checked, but Postgres lacked native replication for many years, and when it finally got it, it was still pretty rough around the edges.

I can make a mysql cluster that will have roughly zero downtime (obviously we can never say "zero" because that's impossible). As of the last time I checked, that was not possible with postgres. Upgrades meant downtime. Major version upgrades meant export/import of data.

Anyway, I'm well aware of the technical deficiencies of MySQL. Like anything else in life, when you choose something, it's a trade-off. Do you care more about minimizing downtime or well-known out-of-spec behaviors? There's no right or wrong answer to that. It's all in what you can live with for any given application.

Re:Postgres

[Anonymous Coward]

except if there was not that silly concept of requiring periodic
"vacuuming". This drives me up the freaking wall!

You prefer the MySQL alternative, where you try to kill a session that's changing lots of data, holding locks and blocking all other activity, only to find that despite having a status of "Killed" it sticks around for several minutes longer while MySQL rolls back all the updates it already made?

Re:Postgres

[Anonymous Coward]

where $plentiful >1 and 3 hopefully

Re:Postgres

[Anonymous Coward]

self-fail

I meant .lt. 3

Re:Postgres

[X0563511]

I don't understand what a GUI toolkit has to do with a DBMS.

Re:Postgres

[CAIMLAS]

You're both absolutely wrong. There are very good reasons for using MySQL; namely:

* It is distribution supported. That probably means shit to most developers, who will usually write code on top of any hot new steaming pile of shit (whether a database, an application, or a framework), but to people who have to work with these things for a living, this is significant.
* A lot of 3rd party frameworks and applications not only work preferentially with MySQL, many also require it. We're talking about things like, oh, MediaWiki, which may or may not also have a number of add-ons and other things which modify the MySQL database.
* Much of the documentation still targets MySQL specifically.
* Many of the tools for db administration target MySQL.

Yeah, I know: there are many reasons why people would want to use Postgres or MariaDB. But this is not an invalid list.

Re:Postgres

[CAIMLAS]

Incorrect. Here is one good reason (which expounds to several good reasons) why Mariadb is not better, regardless. (You're thinking like a developer, not someone who looks at the broader picture, like a sysadmin).

$ aptitude search mariadb
$ echo $?
0

Re:Postgres

[K. S. Kyosuke]

I don't understand what a GUI toolkit has to do with a DBMS.

Perhaps it has something to do with the fact that some GUI toolkits, such as Qt or wxWidgets, have their own database drivers (because, you know, when you have your precious DB app with a data grid built, you might actually want to connect it to a database).

Re:Postgres

[K. S. Kyosuke]

except if there was not that silly concept of requiring periodic "vacuuming". This drives me up the freaking wall!

Well, if you're one of those rare guys who can write large apps with malloc() and with no memory leaks at all, I bow to you. If, however, you're using a GC'd language such as C#, Java, Python or Ruby, you're a hypocrite.

Re:Postgres

[Hognoxious]

No. Postgres is not webscale because it uses joins. MariaDB is webscale.

Re:Postgres

[goffster]

not sure quite how that applies here.
vacuuming applies to unused portions of the disk,
not memory allocated by malloc.

I can see similarities, but since postgres *knows* what
space can be reclaimed, and what can not, then it has
all the benefits of a GC'ed language, and could benefit
by applying GC prinicples used by other languages that
do GC well (i.e. java)

Re:Postgres

[K. S. Kyosuke]

not sure quite how that applies here. vacuuming applies to unused portions of the disk, not memory allocated by malloc.

And what exactly is the difference? You take garbage cells and reclaim them by putting them into allocator's free list again.

and could benefit by applying GC prinicples used by other languages that do GC well (i.e. java)

Well, hardly. The nature of the data is quite different. In Java, the data liveness is implicit - defined by transitive closure over the graph of objects, going from the roots in registers and stack frames of all the running threads. In PostgreSQL and Firebird, the liveness of data rows (or more accurately, data row versions) is explicit - you don't have to actually perform any marking, only sweeping. The rows are marked for processing by the relation of their version ID to the global transaction state of the server (OIT, OAT in case of Firebird, I'm not sure what the respective parameters ale called in case of PostgreSQL).

Re:Postgres

[Anonymous Coward]

* It is distribution supported.

Assuming you mean Linux distributions, I believe there might be one or two that have Postgres as well.

* A lot of 3rd party frameworks and applications not only work preferentially with MySQL, many also require it.

Well if you have to use third-party code that needs MySQL then you have my sympathies. Preferably, a requirement for MySQL should be enough to disqualify a package from consideration, but if someone else has decided otherwise then that's a reasonable enough argument.

* Much of the documentation still targets MySQL specifically.

"The" documentation? The documentation for what?

* Many of the tools for db administration target MySQL.

Again, "the" tools?

Re:Postgres

[nitehawk214]

Because a sysadmin should be choosing how an application is built, and not architects and software engineers?.... and because postgres isn't available from repositories?....

Re:Postgres

[nitehawk214]

Err, wait you said not better, sorry about the flame. So mariadb is not better because it is in a repository? (honestly I cant be arsed to check on a debian machine) Crappy old version of postgres are available from the default repositories that people stick with for stupid reasons too. Now I am totally confused.

Re:Postgres

[pwizard2]

Yes, that's what I meant. Sorry, I should have been more clear.

Re:Postgres

[hawk]

And which of these don't apply doubly or triply to Windows?

hawk

Re:Postgres

[chris.alex.thomas]

I can imagine in your scenario it'd be a bit more complex cause it's a firmware product and not some desktop or server someplace.

but in general, with run of the mill software...

Monty is a stooge

[Anonymous Coward]

The Maria builds have not been particularly special, and its hard to take anything he says about MySQL seriously. So much doublespeak. Stop posting his rants as relevant or news. This is little more than an ad for his support/consulting org.

That's funny

[Anonymous Coward]

It's also what Postres fans have been saying for years. Maybe they're right about other things?

Re:That's funny

[Anonymous Coward]

Of course there's a reason to use MySQL: because your code is using some of those special MySQL extensions like INSERT ... ON DUPLICATE KEY UPDATE .... I expect MariaDB as a fork allows this little bit of vendor lock-in h8fulness too.

Re:That's funny

[Anonymous Coward]

It's also what Postres fans have been saying for years. Maybe they're right about other things?

All three of them?

Re:That's funny

[Anonymous Coward]

That's a nice convenience method. In PostgreSQL we handle it with PL/pgSQL.

update table...;

if found then
    return;
end if;

insert...;

or sqlite

[mattdm]

As a general rule of thumb, if you need something lightweight, SQLite is the way to go. If you need something more powerful or sophisticated than that, PostgreSQL.

MySQL and spinoffs all occupy an uncomfortable middle ground. 99% of the small web sites which are built around MySQL don't need it.

Re:or sqlite

[Anonymous Brave Guy]

MySQL and spinoffs all occupy an uncomfortable middle ground.

Indeed. As well as SQLite, there is also a new generation of "NoSQL" databases that might serve some projects better. Any way you look at it, MySQL and MariaDB are stuck in a kind of limbo now. They could survive for years on nothing but inertia, but it's hard to see how they would be a good choice for any new project today.

Re:or sqlite

[Anonymous Coward]

As a general rule of thumb, if you need something lightweight, SQLite is the way to go. If you need something more powerful or sophisticated than that, PostgreSQL.

MySQL and spinoffs all occupy an uncomfortable middle ground. 99% of the small web sites which are built around MySQL don't need it.

Whoa.. for a rule of thumb that's a way too big for a jump from SQLite straight to the big and bulky PostgreSQL. You do know there are good databases outside PostgreSQL right?

- Need a key-value storage? Use tdb (or any dbm-like that you can find).
- Need a lightweight SQL-using database? Use SQLite.
- Need a lightweight and reliable database? Use Firebird.
- Need a database for your project(s) that might take off, raking millions of dollars and the one you want to rely as the backbone of your next company? Then .. use PostgreSQL.

Other than that I use whatever available. For example need a database for web applications that is likely to be found on a $5-dolar-a-month "webhosting"? Well looks like we'll use MySQL today.

Re:or sqlite

[wmac1]

Most people and websites do not agree with you. Ask facebook , wikipedia and thousands of others (if not millions).

SQLite is not scalable. MySQL is lightweight and scalable.

PostgreSQL has not been successful in penetrating cheap shared hosting providers. There is no web based tool comparable to phpMyAdmin and there are more reasons why PostgreSQL has not been successful despite its technical advantages.

Re:or sqlite

[jamesh]

- Need a key-value storage? Use tdb (or any dbm-like that you can find). - Need a lightweight SQL-using database? Use SQLite. - Need a lightweight and reliable database? Use Firebird. - Need a database for your project(s) that might take off, raking millions of dollars and the one you want to rely as the backbone of your next company? Then .. use PostgreSQL.

A Mysqlite, Mariadblite, or postresqlite database would be really nice. Something that requires similar installation to sqlite (eg not much at all) and not a lot of tuning for a tiny database but that can scale up to the full thing as required. Most applications i've used have a compatibility layer that means you can choose from sqlite, mysql, or postgresql at installation time, but choosing sqlite initially because it's easy doesn't necessarily mean there is a straightforward migration path when you outgrow it.

Re:or sqlite

[CastrTroy]

I use MySQL for a lot of personal projects on a shared host. However, I don't have any idea how anyone uses PHPMyAdmin. It gets the job done in a pinch, but it really doesn't work as well as MySQL workbench. You should be able to set up an SSH tunnel so you can use MySQL workbench. I imagine the same could be done for whatever tool is popular for PostgreSQL. Using a web based tool doesn't make any sense in either case.

Re:or sqlite

[gagol]

The command sucks. I uses a led and a switch connected to my fiber to send commands.

Re:or sqlite

[BitZtream]

Just for reference, 'NoSQL' is not new. We've all be using variations for years ... since that would include all berkley db databases.

Please don't throw around meaningless buzzwords like you know what they mean.

Re:or sqlite

[S.O.B.]

PostgreSQL has not been successful in penetrating cheap shared hosting providers. There is no web based tool comparable to phpMyAdmin and there are more reasons why PostgreSQL has not been successful despite its technical advantages.

Ask and ye shall receive:

http://phppgadmin.sourceforge.net/

Re:or sqlite

[Anonymous Brave Guy]

I didn't say NoSQL was new. I said there was a new generation of NoSQL databases that might serve some projects better, which is true, and even then I was only citing them as another example of alternatives that leave MySQL/MariaDB in limbo where they are unlikely to be a good choice for any new project today, which is the fundamental point that you didn't address at all. Your flamebait post contributes nothing of value to this discussion.

Re:or sqlite

[Anonymous Coward]

I openly admit that I donâ(TM)t know either, but isn't Berkeley DB / GDBM just a key/value store, while NoSQL means a semantic triplet store?

If not, then IMO it should be that way!

Re:or sqlite

[larry bagina]

Wikipedia, harbinger of truth, claims NoSQL means a document database, a graph database, or a key/value database (like Berkeley, GDBM, etc). Of course, you can use a key/value store where the value is JSON or xml data, i.e. a document.

Re:or sqlite

[Trailer Trash]

I don't get it. I've used postgresql for years and I've never bothered tuning it. It's always worked fine out of the box for tiny databases and fairly large ones. I use Ubuntu for most server stuff, so "setting it up" involves "apt-get install postgresql" or whatever. After that I create a user, create a db, and get to work. It's about 4 statements that I have to type in. MySQL is no more work, but I'm not sure why anybody would use it given that postgresql is as easy to set up and does far more with no effort.

Re:or sqlite

[Anonymous Coward]

phppgadmin is not comparable to phpmyadmin. It's a poor copy of myadmin.

Re:or sqlite

[AaronLS]

"99% of the small web sites which are built around MySQL don't need it."

Likely they are running on a virtual share, and as such as using the cheapest thing available that also supports the web apps they want to use.

If the web app happened to support SQLite, it would still be a better choice to use the hosting provider's MySQL server since it is already configured for backups and likely runs on a separate piece of hardware from the virtual web server. Additionally they are probably using multiple tools, CMS+blog+wiki+forum or some such, and better to just offload all that to the database server.

Even if all these apps supported sqlite, the hosting provider still has to hire a programmer to write code that somehow iterates through all the virtual hosts, finds all the apps running SQLite, and perform backups through the backup API. With MySQL, having all the databases in a central location and a nice community of tools that already handles this sort of thing with a bit of configuration is cheaper.

On the other hand it would be easier on the setup side of the web apps to use SQLite, because no longer will you need to deal with creating the database+permissions+connection strings. Probably the easiest solution is some sort of easily discoverable network service that provides a central backup service, that the host would have for all the SQLite applications to discover and perform backups to.

Just my opinion, but I wouldn't suggest SQLite as the DB of choice for small websites.

Re:or sqlite

[Anonymous Coward]

Most people and websites do not agree with you.

Most people and website developers have no fucking idea what they're doing. Why the fuck do we care if they agree or not?

Ask facebook , wikipedia

Horrible example. Facebook uses a very heavily modified version of MySQL, and Wikipedia has the staff to apply custom patches and get work done on the DB engine to optimize it.

and thousands of others (if not millions).

Millions of people used to think Earth was flat. They were all wrong and dumb. Stop using this nonsensical argument.

SQLite is not scalable.

He never said it was. Learn to read.

As a general rule of thumb, if you need something lightweight, SQLite is the way to go

MySQL is lightweight and scalable.

Are you fucking kidding me? You obviously never used a VPS with 512MB of RAM. MySQL runs a heap of shit compared to postgres. It also uses way, way more memory by default. postgres can at least tune itself.

PostgreSQL has not been successful in penetrating cheap shared hosting providers.

"cheap" providers are fucking horrible and do not aim for quality, they aim for quantity and cheapness.

There is no web based tool comparable to phpMyAdmin

There we go, I knew you were talking out of your ass like an idiot.

and there are more reasons why PostgreSQL has not been successful despite its technical advantages.

And I'm sure these imaginary reasons that you haven't wrote down (because they don't exist) are just as good as your previous ones.

Re:or sqlite

[VortexCortex]

The gui managers all suck. You have to use the command line.

The command sucks. I uses a led and a switch connected to my fiber to send commands.

You realize that all of this was part of my plan when I created the initial conditions for this Universe, to populate my database, right?

Re:or sqlite

[VortexCortex]

phppgadmin is not comparable to phpmyadmin. It's a poor copy of myadmin.

Proving once again, the "no true Scotsman" argument can be applied to anything.

Re:or sqlite

[shutdown -p now]

Firebird is trivially embedded with almost zero configuration requirements, yet scales up well and is pretty feature rich. It's a very good option when you think Postgres is overkill.

Re:or sqlite

[StandardDeviant]

The default configs for postgres are set for a fairly small memory usage profile (*), which is fine if that's what you need (e.g. tiny vm or something that makes it a huge production to raise things like max shm size), but if you have sufficient ram, you can crank a hell of a lot more performance out of the engine by making the configs less conservative. This page is a good start: http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

Not that it's a priori *wrong* to run with the defaults, it'll still work just fine, but once you start having significant traffic or complicated queries you'll be happier if it more fully uses the system resources available.

(*) It's been a good while since I last had to take a pg instance from stock and tune it, but I very vaguely recall the default settings were on the order of a eight megabytes of ram usage.

Re:or sqlite

[Nemyst]

Many, many sites are still on low-cost shared hosting, where MySQL is often all there is. I'm not even sure you'll see a transition from MySQL to SkySQL or MariaDB anytime soon in that environment. It took them years to get to PHP5. MySQL is better than no SQL.

Re:or sqlite

[jampola]

This! Hell, using SQLite on most small web sites would be overkill and could quite easily grep text files all day long!

Re:or sqlite

[davester666]

Ewww. There's god-seed everywhere.

You couldn't at least have used a sock?

Re:or sqlite

[Anonymous Coward]

... I use Ubuntu for most server stuff ...

Nuff said. Please don't comment on things you don't understand and don't want to understand.

Re:or sqlite

[aztracker1]

+1 for Firebird.. you can start embedded, and grow into rdbms... it's great for small/mid sized projects... I wish more people knew about it. I once built a distributed system with each node running an embedded copy of FB and a network service to periodically sync new/changed records up/down the nodes.. worked fairly well... that said, if you're on a close/closed network in physical proximity, there are other practicalities of a centralized rdbms.

Re:or sqlite

[crutchy]

as much as i agree, to play devil's advocate, ubuntu is powered by raw debian awesomeness under the hood, and that alone gives it server cred (even if you have to hose away all the shit to get to it)

Re:or sqlite

[Anonymous Coward]

That's unusable junk.

Please don't link it if you actually don't have any experience with it.

Re:or sqlite

[Anonymous Coward]

phppgadmin anyone ?

phppgadmin.sourceforge.net

Also, phpMyAdmin is horrid.

Re:or sqlite

[rev0lt]

MySQL is lightweight and scalable.

Its neither lightweight or scalable, at least when compared to PostgreSQL. MySQL usually runs somewhat fine until you have databases bigger than the memory defined for buffer_pool_size. At that point, you'll start having odd performance issues (presumably due to I/O). Also, for small databases, it seems (by my empirical experience - never benchmarked this specifically) the sweet spot for buffer_pool_size is about twice the total size of the database in disk. PostgreSQL works quite well even with 256Mb of memory. Regarding scalability, well, this is a broad subject. At horizontal level, MySQL replication has a ton of issues and oddities (it is getting way better, but still there is a lot of work to be done). At a vertical level, well, if you start using it as a RDMS, you'll quickly find MySQL shortcomings: poor query planner, poor performance in complex join queries, shitty GIS support, no recursive transactions, _no_ "proper" stored procedure support (stored procedures are handled as macros and expanded inline in the queries). MySQL is great for some workloads, but not as a general RDBMS.

Re:or sqlite

[Anonymous Coward]

I wanted to try Firebird but didn't find good tutorials on how to get started, with either the embedded or regular versions, and how to work with it from VB.Net or Python instead of Delphi.

Are there good tutorials you would recommended for newbie to get up and running fast?

Re: or sqlite

[RyuuzakiTetsuya]

Hey, that's not a REAL no true Scotsman fallacy...

Re:or sqlite

[frisket]

99% of the small web sites which are built around MySQL don't need it.

I don't know about 99%, but there are certainly plenty of sites built by developers whose only knowledge of data storage is "database", and who therefore use one for everything, regardless.

Re:or sqlite

[frisket]

Does PostgreSQL have a command-line option similar to MySQL's -X which returns the data to stdout in XML format?

Re:or sqlite

[Trailer Trash]

Yep, Ubuntu makes Debian even easier to use and I get more up-to-date packages. I don't think I have to toot my own horn around here after Xmas of 1999, but I've been using Linux since 1995 starting with Slackware. Ubuntu is a great distribution, and that's largely because Debian is great.

Re:or sqlite

[Captain_Chaos]

Sometimes somebody really isn't a Scotsman though...

Re:or sqlite

[WuphonsReach]

Yes, you need to look at the XML functions. There are options ranging from outputting a single field as XML up to an entire table/query as XML.

Re:or sqlite

[geminidomino]

That's unusable junk.

Then it sounds pretty comparable to phpmyadmin, after all.

Re:or sqlite

[Rich0]

As a general rule of thumb, if you need something lightweight, SQLite is the way to go. If you need something more powerful or sophisticated than that, PostgreSQL.>

If I were ever writing something new I'd almost certainly use PostgreSQL instead of MySQL/MariaDB. The problem is that I end up using MySQL for almost everything anyway, because few FOSS projects actually support PostgreSQL If they did it would be a no-brainer.

Re:or sqlite

[pak9rabid]

There is no web based tool comparable to phpMyAdmin...

What's wrong with phppgadmin?

Re:or sqlite

[Anonymous Coward]

Is that frontend any good, it was a major piece of shit not too long ago.

Re:or sqlite

[Anonymous Coward]

It's not a "no true Scotsman" argument because he said /comparable to phpMyAdmin/; he did not say that 'there are no web based tools'... but I don't care either way, I just hate when people point out logical fallacies that aren't.

Re:or sqlite

[wmac1]

I have used phpgadmin but it does not cover all of the functionality of PostgreSQL and it has slower development pace. The UI is also outdated and less appealing.

Re:or sqlite

[Anonymous Coward]

It is comparable to phpmyadmin though. So it's a good example of the fallacy either way.

Re:or sqlite

[wmac1]

I have used a single instance of MySQL (on a dual quad server) for a 1.5 million members social network. The concurrent users sometimes reach around 8000 and the database still handles the job very well. Before migrating to this server we had 4 separate dual core servers (one master and 3 slaves).

From my experience MySQL (as explained above), it is both lightweight and scalable (replication and clustering distributed models and management tools, multi-core capabilities etc.).

I would definitely prefer PostgreSQL if it could handle the same load on the same hardware. Based on our tests, on the same hardware it could handle considerably lower number of users. We used professional tuning consultation for both scenarios.

Re:or sqlite

[dkleinsc]

An LED and a switch connected to my fiber sucks. I use butterflies.

Re:or sqlite

[Anonymous Coward]

Why the heck is this flaming answers be modded up while another similar and properly-worded answer is up there?

Re:or sqlite

[K. S. Kyosuke]

Simply buy The Firebird Book, Second Edition, and you probably won't need anything else for quite some time.

Re:or sqlite

[rev0lt]

I have used a single instance of MySQL (on a dual quad server) for a 1.5 million members social network

Is your total dataset size bigger than memory? Do you rely on JOINs? How many queries/s do you get from MySQL? Are queries scattered across your dataset, or focused on a single set of data (ie. recently used data)?

Based on our tests, on the same hardware it could handle considerably lower number of users.

You may be using MySQL on a specific application it excels at. Or you may just be benchmarking the wrong stuff - it is not clear if you are benchmarking application users or simultaneous connections. If the latter, I usually need 200-400 simultaneous connections (max) to handle the same reqs/s as a similar 3000-5000 connection MySQL database.
I have worked professionally with both PostgreSQL and MySQL (and unfortunely all my current projects are MySQL-based) and I routinely have peformance issues with MySQL in stuff any half-decent RDBMS handles without hiccups.

Re:or sqlite

[tobiasly]

...it's hard to see how they would be a good choice for any new project today.

MySQL is a good choice because I can log in to my Amazon Web Services account, provision a new RDS instance, and be done with it. I have no interest in managing an RDBMS and am willing to pay someone else to do it for me. Until AWS supports Postgres, I'll stick with MySQL.

Re:or sqlite

[gorzek]

99% of small web sites are using pre-made PHP scripts that demand MySQL and often support nothing else (or don't support anything else as well as they support MySQL.)

While I'm not sure how this started, I would assume it's because PHP initially supported MySQL before they supported anything else, and PHP quickly became the website hobbyist's language of choice. From there, it's just been inertia. If it's a PHP-based web application that requires a database, odds are it's just going to assume MySQL.

Re:or sqlite

[FictionPimp]

As if ubuntu can't be used for running large complicated data centers. I used to manage a datacenter that has over 100 ubuntu servers. It is just as rock solid as it's parents and has commercial support business requires.

Ubuntu server is a fine OS with a nice installer (I love the minimal for VM install) and has no tools (like yast) in the way to prevent you from doing any customization.

Re:or sqlite

[Anonymous Coward]

"properly worded" is relative to the reader. His post was insulting, sure. If you ask me I find someone who has no idea what he is talking about defending a bad database with terrible arguments even more insulting than that post.

Re:or sqlite

[wmac1]

The database size is near 0.7 TB, tables are spread into several files, we use joins very heavily (sometimes with up to 7-8 tables), we use stored procedures sometimes, some pages have more than 10-15 queries, we have 150+ million page views per month, the website has public pages and millions of pages (in different modules: groups, profiles, jobs, classifieds, message box, online shops, Q&A, website wide search, ledger based credit accounting for specific activities,... ) receive new users from search results.

I have used several databases (Oracle, MS-SQL, MySQL, PostgreSQL) and in my opinion MySQL does a good job for non-business critical applications.

For business applications (Core Banking) we were forced to use MS-SQL but it could not handle the job (billions of records) so we convinced the bank to back off and use Oracle. I would never go with either MySQL or PostgreSQL for that application (not even MS-SQL). They basically don't have the necessary tools and capabilities (hot backup, two way transactions, SAN clustering, ...) for the purpose. But for non-critical applications MySQL is just fine.

Re:or sqlite

[evilviper]

Most people and websites do not agree with you. Ask facebook , wikipedia and thousands of others (if not millions).

SQLite is not scalable. MySQL is lightweight and scalable.

Either neither is scalable, or both are scalable... Sites like Facebook can use MySQL because they shard the hell out of it... That works with SQLite, or any other DB just fine. But that's not what people mean when they talk about database scalability...

Postgres has always handled much higher numbers of complex queries per second. Oracle has long been able to cluster up to 16 (IIRC) servers in a multi-master setup. That's scalability...

And Facebook, Twitter, and other similar web services aren't good examples... They all only care to offer low-reliability services. They're happy to take the gamble that your settings might get lost once in a while, or that when a DB server goes out, the most recent "tweets" or "likes" of a few users get lost in the ether. That's a far cry from transaction processing or trading platforms, where losing one record could mean millions of dollars lost, and possibly legal liabilities of several times more.

Re:or sqlite

[Anonymous Coward]

No, you don't, unless you're too stupid to figure out workbench. Keep command line where it's useful - when the GUI doesn't do the job at displaying things nicely and making them easy to modify. What's stupid is opening a GUI just to create a new user when it's one line of SQL...

Re:or sqlite

[Darinbob]

I just yell at my system until it starts working.

Re:or sqlite

[gagol]

Hey boss, is that you?

Re:or sqlite

[Anonymous Coward]

Thanks for the pointer.

Re:or sqlite

[Anonymous Coward]

No matter what that sheep says!

Re:or sqlite

[Anonymous Coward]

LED? Switch? I use a thin piece of wire across the battery terminals. No switch, and when it gets hot it glows.

Re:or sqlite

[Anonymous Coward]

Pussy, real men use lens, cardboard and harness the power of the sun!

Re:or sqlite

[rev0lt]

we use joins very heavily (sometimes with up to 7-8 tables)

This is light join usage :) We actually had one MySQL application giving problems because of MySQL JOIN limit (63 or something like that).

some pages have more than 10-15 queries

That is not much - at all, assuming you are caching the output. As an example, the full rendering of the homepage of a specific store done in Magento (cache disabled) was around 140 queries. I have done CMS systems that perform 30-50 queries for high-traffic pages (cache disabled, PostgreSQL), and most OSS CMS platforms will usually generate between 10 and 40 queries just to render the homepage.

we have 150+ million page views per month, the website has public pages and millions of pages (in different modules: groups, profiles, jobs, classifieds, message box, online shops, Q&A, website wide search, ledger based credit accounting for specific activities,... ) receive new users from search results.

That is impressive. Are you handling search with MySQL or using an external system?

Re:or sqlite

[wmac1]

As I described in another post here, I would never use MySQL or even PostgreSQL for critical applications (Finance, healthcare, insurance etc.)

Neither of those have the necessary tools and capabilities for such applications.

As for the scalability, MySQL has clustering and replication. Does SQLite have them?

Re:or sqlite

[evilviper]

I would never go with either MySQL or PostgreSQL for that application (not even MS-SQL). They basically don't have the necessary tools and capabilities (hot backup, two way transactions, SAN clustering, ...) for the purpose.

and PostgreSQL can do all three of those. Sounds like your information is more than a decade out of date. IT skills sure do stagnate that way...

You'll also want to look up EnterpriseDB.

Re:or sqlite

[Anonymous Coward]

No , thanks. I don't want to bankrupt a whole financial company/Bank because of stupid interest in open source software.

Re:or sqlite

[evilviper]

Nice try... Troll all you want.

A number of large and important organizations are using PostgreSQL quite extensively for critical transaction processing:

http://www.postgresql.org/about/users/

And EnterpriseDB:

http://www.enterprisedb.com/success-stories/customers

It's not always the best fit, but it's very mature, and can handle most workloads you could want to use it for.

Sign of OSS maturity

[Gothmolly]

Most MySQL/MariaDB users wont care at all about this, because there are millions of them who are not Slashdot or Amazon or Facebook - this DB silently powers millions of Internet connected things, and it's just a given that it works, performs, has fit-for-purpose stability. It's a sign of how far OSS has come when people have the luxury of quibbling over WHICH free, capable DB they want to base their business model on.

Re:Sign of OSS maturity

[girlintraining]

It's a sign of how far OSS has come when people have the luxury of quibbling over WHICH free, capable DB they want to base their business model on.

I'm not aware of any reliable numbers on how many copies of those databases are actually in use. Unfortunately, the only numbers that there's any confidence in is based on sales figures, which, given that open source doesn't sell software licenses at anything but, uhh, $0, isn't representational. Oh I know, I'm going to burn in the eternal fires of hell for saying open source isn't the greatest thing since sliced bread, but you did use the phrase "business model."

If we're talking about a database that businesses depend on, then we need to start with the first question a manager's going to ask about: How much support can I get if this thing blows up? And the followup: How does the labor pool look? For example, it's not hard to find people with, say, Cisco hardware experience on their resume. But what about Acme Routers Inc.?

I'm not saying it isn't nice to have choices; nor am I saying that these aren't mature products that can fill the needs for many businesses. I'm just saying, from a management (not geek) perspective... what closes "the sale" is support and labor availability.

Remember: These people are willing to pay tens of thousands for a single server license. They're not doing that for shits and giggles. So if we want open source to spread, we need to do more than thump our bibles and quote the GPL before our morning bread... We need to make a business case. And no, a reply on slashdot with a link to someone's blog or a glowing personal review doesn't count.

Pretend I'm the CTO of a Fortune 500 company, and make your case for switching from, say, Oracle, to MariaDB. Back it up with case studies from other Fortune 500 businesses that have made the switch, and the costs and problems they encountered doing so. And I want to know about support -- if I want it, how long will it take to shove your engineers on a plane and get them to my headquarters to fix a snafu?

Re:Sign of OSS maturity

[petteyg359]

Your burger is the MySQL protocol. Your toppings are the implementation: MySQL, MariaDB, Percona Server, or any other. You want fries with that? Percona offers support contracts for any MySQL variant.

Re:Sign of OSS maturity

[girlintraining]

Your burger is the MySQL protocol. Your toppings are the implementation: MySQL, MariaDB, Percona Server, or any other. You want fries with that? Percona offers support contracts for any MySQL variant.

Error: Invalid object passed to function in line 1. Expected array of 'fact' but got 'handwave' instead.

Re:Sign of OSS maturity

[petteyg359]

I understand that you're in denial, but it will pass eventually.

Re:Sign of OSS maturity

[Billly Gates]

I read your posts for awhile.

Your enterprise is so backwards and has a fear of anything new. You praised IE 6 a few years ago because you didn't liek the new gui's of Firefox and IE 8 and Windows 7 at your place is still a slow process with people crying and kicking.

Have you considered working in a more forward thinking environment where you are not a cost, and people are so scared of change? I work in such an environment now and since I am a contractor already have something else lined up.

Re:Sign of OSS maturity

[Anonymous Coward]

Oh the projection! It's hilarious!

Re:Sign of OSS maturity

[kestasjk]

I'd say it's a big sign of a certain OSS developer's immaturity.

Re:Sign of OSS maturity

[mabhatter654]

Well mr 500. Plenty of companies DID choose to grow into paying for MySQL support INSTEAD of paying for expensive Oracle servers. Then Oracle bought MySql.
Personally, I think that the creator/owner of MySQL did right by selling to somebody that had the ability to actually FURTHER the product. And provide support to paying customers. Nobody else could afford to buy the size of company that MySQL had become... But at the same time it was still a "toy" database company. ID point out that Oracle was gradually cutting off MySql air supply. They were buying up other opensource projects.. Like Sleepy Cat that created SQLite and other pieces MySql needed. So Ellison was actively trying to corner the DB market on Linux.

The problem is that company was ORACLE. And many people stayed on puny MySQL EXPRESSLY NOT to give Ellison's ego more money. Monty and pals took a few years off MySQL but its obvious Oracle isn't moving the product forward.

The BIGGEST reason for using ANY spinoff is that Oracle is gradually making the distribution of "original MySQL" more onerous for Red Hat, Ubuntu, Zend etc. Oracle eats its partners more violent than Microsoft ever did. So it's just bad business to base YOUR BUSINESS on MySQL remaining on its "graceful" terms much longer.

Re:Sign of OSS maturity

[mabhatter654]

Mr 500 I'd point out that MySQL was never FOR Fortune 500 companies. MySQL was for a guy running a shop making parts for your suppliers. He's got one IT manager that doubles as bookkeeper and zero budget for $10k software licenses. Those people were NEVER going to buy Oracle, and probably not buy Microsoft SQL either. What happened is that in the decade of MySQL, those little shops got big enough to buy, and the 500 kids liked what they were doing on a budget of duct tape and peanuts so MySql got into the doors of companies that demand to pay for support. And MySQL AB became a billion dollar company... Which isn't really that big... But their product was FREE and people bought support anyway.

Re:Praise the lord

[Anonymous Coward]

JihaDB crashed my filesystem :(

Re:Uh, what?

[fnj]

What the heck? That's EXACTLY what OP said. Re-read the sentence you quoted.

Re:Praise the lord

[Anonymous Coward]

HitlerDB deleted all my financial software :(

Until you do support/enterprise

[dutchwhizzman]

If you want the "free" version, there isn't a significant difference for 95% of users, agreed. However, MariaDB support is miles better and cheaper than Oracle's "Enterprise MySQL" support is. Also, calling Monty names is cheap and rather unfounded.

Re:Until you do support/enterprise

[Anonymous Coward]

Percona offers better MySQL support than both, hands down. Who do you want consulting from, the MyIASM guys (Monty) or the InnoDB guys (Percona)...

Free migration then?

[dutchwhizzman]

Maybe Postgres is a better DB in a theoretical way. It could be that in a brand new design for an application, it will be better in practice as well. However, if you run existing code or use an "off the shelf" open source application, chances are, it will be tested and developed on MySQL/MariaDB and not on Postgres. Until the choice is just as easy to make as the choice for either MySQL or MariaDB, I doubt it's "better" for 90+% of all MariaDB/MySQL users. Those users have a choice for either something that works, or something that will need a lot of porting and testing done. It may seem small and insignificant to Postgres experts to do that, but to those 90+%, it ishttp://developers.slashdot.org/story/13/05/05/2050220/there-is-no-reason-at-all-to-use-mysql-mariadb-mysql-founder-michael-widenius?utm_source=rss1.0mainlinkanon&utm_medium=feed# most likely far beyond their capabilities, probably cost prohibitive and in a lot of cases just not an option at all.

Re:Free migration then?

[Anonymous Coward]

Those users have a choice for either something that works

You wouldn't be saying that about MySQL if you'd ever had the misfortune of actually using it.

Re:Free migration then?

[Anonymous Coward]

Those users have a choice for either something that works

You wouldn't be saying that about MySQL if you'd ever had the misfortune of actually using it.

I've been using MySQL for over a decade and never thought of it as a "misfortune". In fact, the few times I've had a chance to work with Postgres in any depth, "misforunte" is probably a pretty good summary of those experiences.

Re:Free migration then?

[Anonymous Coward]

I've used both, as a newb I find Postgres to be a horrible experience and MySQL not a horrible experience.

Re:Free migration then?

[Anonymous Coward]

Those users have a choice for either something that works, or something that will need a lot of porting and testing done.

You are aware that because of its messiness the latter is the description for MySQL/MariaDB, and the former describes the very clean and nice PostgreSQL, right?

Compare the documentations. E.g. on date processing, general emergence/elegance and on the more powerful SQL features. 'nuff said.

Re:Free migration then?

[rnturn]

``However, if you run existing code or use an "off the shelf" open source application, chances are, it will be tested and developed on MySQL/MariaDB and not on Postgres.''

That was my experience back when I was looking for web site software a few years ago. It's not so much that the "off the shelf" application hasn't been tested against PostgreSQL but it's almost certain that the developers only considered MySQL, taken advantage of non-standard SQL statements that are available in MySQL, and locked users into using only that database. I downloaded untold numbers of web site packages and found that most of them had used things like MySQL's "REPLACE" statement which meant they wouldn't be useful in my existing PostgreSQL environment without significant reworking. Standards, shmandards.

Ideally, it'd be nice if more developers would write their application to use some of the database abstraction layers that are out there (PEAR, ADOdb, etc.). At least then users would be able to merely use the database they may already have installed.

Re:Free migration then?

[Rich0]

Standards, shmandards.

Well, the problem with SQL is that the only universal standard is so old that it doesn't do half the stuff people want to do with it. That and laziness - there are things that could be done in ANSI SQL but the syntax ends up being arcane or verbose and people would rather write something short in a non-standard extension.

Ideally, it'd be nice if more developers would write their application to use some of the database abstraction layers that are out there (PEAR, ADOdb, etc.). At least then users would be able to merely use the database they may already have installed.

THAT I'll agree with. That is a real failing on Linux - on Windows developers were encouraged to use such frameworks from the start. In the FOSS world every was encouraged to link to some DB-specific library and use DB-specific syntax. One proprietary piece of software at work supports anything that supports ANSI SQL and ODBC - you could run it with just about any DB back-end you want. Java has JDBC. The exact framework doesn't matter as much as the fact that one gets used.

Re:Free migration then?

[Anonymous Coward]

I downloaded untold numbers of web site packages and found that most of them had used things like MySQL's "REPLACE" statement

There's another MySQL WTF: REPLACE does a DELETE on any existing conflicting rows followed by an INSERT, so if you have any foreign keys referencing the table with ON DELETE CASCADE, say goodbye to your data. Of course, most of the MySQL kiddies probably aren't smart enough to use foreign keys anyway, so once again the idiots can carry on, merrily oblivious to their idiocy, whereas the compentent people who are forced to suffer through someone else's decision to use MySQL get that suffering multiplied.

Re:Free migration then?

[Anonymous Coward]

There's another MySQL WTF: REPLACE does a DELETE on any existing conflicting rows followed by an INSERT, so if you have any foreign keys referencing the table with ON DELETE CASCADE, say goodbye to your data.

Almost forgot: also, if your new row conflicts with more than one existing row (possible if the table has more than one UNIQUE index) then they both get wiped, which is probably not what you had in mind....

Re:Free migration then?

[Anonymous Coward]

That is a real failing on Linux

No, it's a real failing of PHP (and even that has DB abstraction layers these days). Perl has had DBI forever, for example, it's just that somehow the idea got around that PHP and MySQL was The Way to do web development on Linux, and so all the idiots started using PHP with the nasty mysql_* functions.

Re:Uh, what?

[Anonymous Coward]

Reading comprehension: don't post without it.

What am I saying, this is Slashdot. Carry on.

Re:Praise the lord

[Anonymous Coward]

I've found JudasDB to be very reliable so far.

There Is No Reason At All To Use MySQL..

[JoeCommodore]

My reason is because there is no compelling reason right now for me to switch. Once it is in my next Ubuntu upgrade or my ISP switches to it then I'll do so as well.

Re:There Is No Reason At All To Use MySQL..

[Anonymous Coward]

I'm just in the process replacing our server and decided to give maria a try. Everything worked nicely, except when using SQL_CALC_FOUND_ROWS, ORDER BY is ignored in a subquery.

Re:There Is No Reason At All To Use MySQL..

[JoeCommodore]

I run Ubuntu at home and I don't know what my ISP is using - probably CentOS...

Re:There Is No Reason At All To Use MySQL..

[Osgeld]

there is no real reason when setting up a new database

oh oricle (what do they know about databases) has mysql now, but a bunch of people who were not valuable enough to keep made a whole new database that has exactly jack shit track record

thats fine for bobsdog.com, but I got shit to do and am too cheep to pay for MS

Re:There Is No Reason At All To Use MySQL..

[Anonymous Coward]

Lol you're a retard.

Re:First

[wmac1]

Michael Widenius has benefited from gathering millions of developers around his product and letting them down.

He cannot sell source code of MariaDB this time, but he still can sell the brand name and the community which has trusted him again to earn another fortune. Fool me once, full me twice...

There was never a rrason to use it

[siddesu]

Especially since sqlite came about. For no-setup, small-size databases, you use that. For more features, if you need em, there's Postgress.

Postgres has a poor toolset

[mveloso]

The main reason to stay away from PostgreSQL is its toolset. Specifically, it's almost impossible to find a tool that allows you to analyze and tune it's performance. I say 'almost' because there may be one out there that I haven't found...but I've looked on and off for years, with no results.

For mysql there's lots of tools, like jetprofiler. For oracle you can pay. For SQLite, well, who cares. For psql, it's (as one website put it) a black art. Do you really want that as your back end?

Re:Postgres has a poor toolset

[TrollstonButterbeans]

Thanks for that information. I have always wondered why PostgreSQL adoption isn't as high as MySQL.

Re:Postgres has a poor toolset

[ducomputergeek]

Have you not looked at the enterprise DB folks? A few years ago I was working on a project that started out using MySQL because MySQL was everywhere and initially it was for a single store. Then that became 50 and then 200 and we ran into some interesting problems with MySQL. Long story short, we ported the backend to PostgreSQL in a couple weeks and then ran for another three years processing tens of thousands of transactions a day without further hiccups from the database before we sold the company. The plan originally was to use PostgreSQL and then migrate to DB2 at some point once the revenue was coming in. Even when we reach that point PostgreSQL was handling everything we threw at it and we did hire Enterprise DB to come in and tune the database set up since we didn't have and couldn't afford to hire a DBA full-time at that point. IIRC they had a pretty decent toolset that we used there after, but it wasn't free as in beer or speech.

Re:Postgres has a poor toolset

[TheRealMindChild]

I'm calling liar. No one on purpose MOVES to db2

Re:Postgres has a poor toolset

[greg1104]

The performance analysis tools for PostgreSQL are still rough, but they're coming out stronger now than ever before. The old slow query profiling approach is based on database log files, and the pgbadger tool has gotten a lot of improvements in the last year to take the lead in that area. Some web app providers have added PostgreSQL data collection and visualization to the products recently, Datadog is a good example, they even run Postgres internally.

Last year's PostgreSQL 9.2 added a built-in query profiling feature via an improved pg_stat_statements module. That makes it relatively easy to see what queries are taking up time on the server, in a way that matches similar statements based on underlying their query plan. I wrote a sort of call to arms to suggest how the next generation of analysis tools can leverage that in Beyond Query Logging.

You are correct that no one has really grabbed ahold of this area and put together a really easy to use tool set around it. All of the hard to construct pieces needed are in place now, and my list of goals for this year's 9.3 development includes pushing the tuning methodology outlined in my High Performance PostgreSQL 9.0 book into some reference tool implementations. The idea that this is a "black art" is coming from consultants who want you to be intimidated. People who want to understand how things work can read my book, and then wander out to confidently build terabyte size databases. I talk with new people who have done just that every week now.

Re:Uh, what?

[BitZtream]

and being purely selfish with ZFS is just nauseating anymore.

Uhm, your saying that its Oracles fault Sun and many other people dont' like the viral nature of GPL and intentionally licensed the software in such a way that prevents your silly fanboy license from being able to leech it? You're saying that its okay for you to have software your way ... but not for anyone else to be free to have it their own way.

You're just another one of the freeloaders. Any talk about liberty is just bullshit your spewing to hide the truth.

My OS has been using ZFS for years without any problems, stop your whining, you got what you intended out of your license. GPL is incompatible with ZFS, not the other way around. Get a clue

Yada Yada Yada.. More of the same drivel.

[FlyingGuy]

98% of "web Programmers" wouldn't know a good database if it dragged them out of the parents basement and gave them a blow job.

I would not recommend using Oracle to run a simple web site. It is complete over kill. I would not recommend using MySQL / Maria to run the VISA processing center either.

99.9% of application builders do not even know the value of a good, much less great, DB engine and that is proven out time and time again when you look at their DB schema and all you see are tables. They all insist on doing EVERYTHING on the front end and never get , even when advised about, the amount of power that DB's like Oracle, PostGres, MS-SQL, DB2 and even MySQL have these days. One well written Stored Procedure ( Oracle Speak ). Package ( Oracle Speak ), function ( PostGres Speak ) or Procedure ( MySQL/ MS-SQL Speak ) can eliminate 1000's of lines of java, python, ruby, php ( pick your language ) front end code, and perform the function 1000x faster and more reliably.

Every tool has its use. When you need massive scaleibility, up time in the 5 9's category and support RIGHT FUCKING NOW WITH AN ACTUAL ENGINEER when you dial the toll free number 24/7/365 you get the big dogs like Oracle,MS-SQL or DB2. If those factors are less important then you have other choices like Postgres ( they REALLY need to fix the TXID issue ) which is very powerful but lacks the kind of SLA's that you can get with Oracle / Microsoft. If just getting feedback from the support community is fine the MySQL / Maria are fine choices.

I design VERY large databases that push DB's to their limits. Google had to design their own because nothing off the shelf or even from the FOOS community could handle their requirements but it takes a small army to deal with it and most companies don't have the resources or don't want to have that many people on their payroll.

The bottom line is use the DB that fits your requirements, fits your budget and has the support organization around it so when you have a problem your requirements are met, and it really does not matter who you get it from. Don't be religious about it. ALL of these companies are trying to build the best product to serve their market and that is the bottom line.

Michael Widenius is nothing but a little bitch. He sold his DB to sun for how much again? 1 BILLION dollars I think it was. Now shut the fuck up, go sit on your riches and do MariaDB if you want but stop bitching about what happened to MySQL because he YOU are the idiot who cashed in and sold out.

Is Wikipedia webscale?

[tepples]

None of the ones you described use Mysql anyway. Most use nosql

Wikipedia uses MySQL. But it also serves most anonymous hits out of a no-SQL cache.

webscale

Careful, lest two Animal Crossing rejects pop in to start talking about MongoDB.

I have one good reason...

[Anonymous Coward]

...my employer says so.

Structured Quota Language

[tepples]

It has basically all the same advantages that MySQL used to have

Except, of course, for the ability to scale down to shared web hosting. A lot of hosting providers appear to refuse to offer PostgreSQL. A comment to a previous story about SkySQL, which appears to be related to MariaDB, claims this is because PostgreSQL lacks per-user storage quotas.

Re:Structured Quota Language

[Anonymous Brave Guy]

OK, that's a fair point, though I'm not sure hosting providers are falling over themselves to offer MariaDB either if my own experience is at all representative. In that market, it's more about popularity and the established brand than anything else, and if you want anything other than a canned MySQL/WP/etc. set-up then you basically need to move up a tier and get yourself a shell account on a VPS or something.

Re: Structured Quota Language

[Anonymous Coward]

At a certain point in life, your time is far more valuable to you, and you just don't care why PGSQL won't allow network connections even when you've changed 3 different places in the config (all deprecated) and set up named pipes and it still won't work. Is it really too much to ask to write either a decent interface OR have updated documentation? I wouldn't dare ask for both, as I know that will just be laughed at.

This is what is known in the trade as "making shit up".

Re: Structured Quota Language

[Anonymous Coward]

A comment to a previous story about SkySQL, which appears to be related to MariaDB, claims this is because PostgreSQL lacks per-user storage quotas.

MySQL doesn't support that either according to what I can find on Google. Do you know differently?

Re: Structured Quota Language

[Anonymous Coward]

No, actually, that was my exact experience. It was a custom-compiled PGSQL instance running on a PPC Mac Mini, and it simply wouldn't accept connections from any other computer on the LAN, period. No amount of config tweaking would change that.

Granted, it was PGSQL 8.1, and I haven't tried again in the last 5 years or so. An OS update made the system unbootable without a wipe, so I never bothered to rebuild that database or the app that used it. I still have a backup somewhere, but it's too old to bother with now.

And as I stated earlier, SS2012 Dev Edition is cheap and way easier. Not to mention more powerful. (Dev edition is the same as the full-bells-and-whistles Enterprise edition, but without a license for production use. Perfectly acceptable for home use, which never leaves "dev" status.)

hasn't been any reason to use MySQL for 1 decade

[smash]

Postgresql is more feature complete, just as fast, and properly free software.

Speaking of economic interest...

[Locke2005]

Oracle has a HUGE economic interest in making sure MySQL sucks bad enough that customers buy Oracle databases instead.

Re:Speaking of economic interest...

[Anonymous Coward]

Oracle has a HUGE economic interest in making sure MySQL sucks bad enough that customers buy Oracle databases instead.

And Monty has an economic interest in making sure people need plenty of handholding and consulting to get MariaDB to do the job for them. When he was one of the ruling circle at MySQL AB I remember they played plenty of games to make sure that big users needed to buy a dual license for production deployments.

Sad to say, Microsoft and Amazon are the two companies whose business model depends on selling in volume, and trying to get customers to be productive out of the gate w/o extra support. OSS companies like Red Hat, as well as the big proprietary software vendors like Oracle, IBM, and SAP, make a lot of their money from expensive support contracts.

Re:Yada Yada Yada.. More of the same drivel.

[Anonymous Coward]

Big advice to anyone who ever gets the "bright" idea of trying to port a substantial application from MySQL to Oracle: don't. And if your boss tells you that you have to, start looking for a new job, because it's a fool's errand almost guaranteed to fail. Not even *Oracle* would ever recommend porting an app from MySQL to Oracle. The problem is that MySQL does well in many scenarios as long as you humor its quirks, but those quirks you've humored will come back and destroy your performance, or make it outright impossible to port the application to a database like Oracle at some later point in time. The problem is that MySQL has certain rules and constraints that you CAN work around to get acceptable performance, but those work-arounds are either frowned upon, or point-blank prohibited, by databases like Oracle. Rewriting your query to get good performance out of MySQL will almost certainly result in the same query causing Oracle to either reject it, fall flat on its face, ditch its indices, and/or do full table scans to satisfy you.

Re:hasn't been any reason to use MySQL for 1 decad

[Anonymous Coward]

Replication is inferior, tunability is inferior, enterprise support is inferior. That and InnoDB has come along way for speed.

Re:First

[Anonymous Coward]

Fool me once, full me twice...

...empty me the third time?

Or Windows

[Anonymous Coward]

There is no reason at all to use Microsoft Windows instead of

But people do.

There never was a reason, PostreSQL ftw

[Anonymous Coward]

There never was a reason to use MySQL. PostegreSQL was ACID compliant before MySQL was even learning what the acronym meant. PostgreSQL always was a higher quality database.

Re:There never was a reason, PostreSQL ftw

[Anonymous Coward]

this statement of fact from someone who's entire database experience is a PHP based CMS system with 8 users

Re:Praise the lord

[nateb]

Here, have 30 karma.

Re:Yada Yada Yada.. More of the same drivel.

[Anonymous Coward]

I wouldn't recommend running MySQL to run anything where you actually value referential integrity.

Re:hasn't been any reason to use MySQL for 1 decad

[Anonymous Coward]

More than a decade ago there were compelling reasons to not use MySQL: Stored Procedures, Triggers, and Transactions for example.

If you wanted these features, you had to look elsewhere because they did not exist at the time.

Re:First

[ThePromenader]

I hope he's not referring to schtupping.

No reason? Every reason...

[bradley13]

There is every reason to use MySQL: It is integrated in pre-configured LAMP stacks, it is ubiquitous, and it "just works". If MySQL isn't good enough, why would anyone change to MariaDB, which is - and will remain - 99% the same thing?

This appears to be a guy trying to take back a product he already sold. Regrets? Doesn't know what to do with his life? Whatever...

Re:First

[prionic6]

You meant to say:

fool me once, shame on
shame on you.
Fool me
you can't get fooled again

Re:Yada Yada Yada.. More of the same drivel.

[InsectOverlord]

That, and if you take a lot of business logic to DB level you REALLY have to know what you're doing, with triggers, constraints and other stuff creating race conditions and various other side effects and making the system harder to debug.

Not that you shouldn't use stored procs, etc but you shouldn't become obsessed over it either.

Re:First

[Anonymous Coward]

I think it was "Fool me once, shame on... shame on you. Fool me twice... uh... afoolmuhcan't get fooled again."

Re:Yada Yada Yada.. More of the same drivel.

[Anonymous Coward]

The reason most application builders do not seem to care much about their database and prefer to do most queries in code is because databases are boring, and 99% of applications do not need extreme performance.

So you just wrote a few stored procedures for those complex queries? That's great! Now suddenly we have TWO code bases we need to keep track of and which need to be version-controlled and compiled/uploaded separately. Not only that, but now you've vendor-locked the application into whatever flavour of the month database and query dialect we are using! Good job. We'll worry about porting the code and migrating the data later on when we'll actually need scalability.

If the database world would actually get their act together, maybe more programmers would be more interested in using databases as intended instead of glorified filesystems.

Re:Praise the lord

[Anonymous Coward]

And replaced it with a custom logistics package from IBM

Re:First

[JWSmythe]

Mr. Ex-President, is that you?

Amazon RDS

[Randyj70999]

It's not revelent until the AMAZON RDS adopts MariaDB over MySQL 5.5!

Re:Amazon RDS

[Slashdot Parent]

It's not revelent until the AMAZON RDS adopts MariaDB over MySQL 5.5!

Isn't most of the point of RDS that you don't really have to care what's under the hood?

Restricting the storage engine

[tepples]

Based on this first Google result for mysql quota I gather that MySQL quotas per database are easy to enforce using an external tool because of how MySQL storage engines map databases to files.

Re:Restricting the storage engine

[Anonymous Coward]

According to the comments MySQL is liable to get upset if it actually hits the quota. (And you can do pretty much the same thing with Postgres, although again it's unlikely to be happy if its writes actually start failing.)

Why?

[Anonymous Coward]

How is Oracle evil? I've heard this before, but I really don't get it.

Re:Uh, what?

[Captain_Chaos]

Here, these fell out of your post: ' e ' ' ' e. My pleasure.

Re:Yada Yada Yada.. More of the same drivel.

[Anonymous Coward]

> 98% of "web Programmers" wouldn't know a good database if it dragged them out of the parents basement and gave them a blow job.

But they would appreciate if it did...

Right Tool For The Job

[Anonymous Coward]

I use HitlerDB to categorize the Downfall parodies on YouTube.

Re:Yada Yada Yada.. More of the same drivel.

[Rich0]

Not that you shouldn't use stored procs, etc but you shouldn't become obsessed over it either.

THIS.

I'd go a step further and say simply never use stored procs. They really cement you into exactly one platform. If you write your code to be DB-agnostic then you're going to have a LOT more flexibility down the road. Oh, and that isn't just flexibility to change DB Vendors - even Oracle has been known to deprecate some of their stuff and if you relied on them that means a lot of rework. If you rely on ANSI SQL you can pretty-much guarantee that it will still work (if you use it right - like not assuming that an unordered query returns results in some particular order).

Some programmers just don't grok SQL either. I can't tell you how many queries I've seen that are implemented with either a wall of SQL, or even a stored procedure, that could be expressed as maybe 10 lines of well-indented SQL written properly. I've seen subqueries nested 10 levels deep that implement simple inner joins - they're worse than trying to read compiler output (especially when nobody bothers to format them). Hint, if your query contains the expression "WHERE 1" a dozen times you're probably doing something wrong.

Re:Yada Yada Yada.. More of the same drivel.

[Anonymous Coward]

When you need massive scaleibility, up time in the 5 9's category and support RIGHT FUCKING NOW WITH AN ACTUAL ENGINEER when you dial the toll free number 24/7/365 you get the big dogs like Oracle,MS-SQL or DB2. If those factors are less important then you have other choices like Postgres ( they REALLY need to fix the TXID issue ) which is very powerful but lacks the kind of SLA's that you can get with Oracle / Microsoft.

If you want to use Postgres and you're willing to pay for SLAs, there are plenty of companies who'll quite happily take your money.

Give credit where credit is due

[Anonymous Coward]

I attended Mark Callaghan's presentations at the OpenWest conference (http://www.openwest.org/) this past week where he talked about MySQL -- he's in charge of the MySQL operations at Facebook. It sounds like Oracle has done great things to improve MySQL over the years, especially with InnoDB, and MySQL has become much more robust under Oracle's care than it ever was before. Is MySQL perfect? No. But it's improving, in part, because the community holds Oracle's feet to the fire.

The MariaDB guys borrow Oracle's hard work, improve on it in some cases, and claim their db is better, and rarely give credit to Oracle where credit is due. Welcome to their reality distortion zone. Yes, they're smart, capable, and highly motivated. No, they don't like Oracle. Yes, they have a vested economic interest in marketing MariaDB, and it looks like they've been mostly successful with their message in the open source community.

Fedora includes MariaDB in its distribution, and other distributions include it as well. Thank you, Oracle, for improving MySQL. Thank you, MariaDB, SkySQL, FB and others for encouraging Oracle to improve MySQL.

Re:Yada Yada Yada.. More of the same drivel.

[Anonymous Coward]

Phew was reading that and I got worried about my own stored procedures until I saw that last part. I use real comparisons like "WHERE 1=1" so I'm good.

Re:Yada Yada Yada.. More of the same drivel.

[snadrus]

I think a great advantage of SQLite is no stored procedures.
I've seen stored procedures munge backup/restore operations and have all kinds of unintended consequences when a developer is over-aggressive with them.
Then they're difficult to scale versus up-scaling front-ends that run the logic.

As an ex-DB-Admin for ~100 developers, my rule was: no stored procedures.

Re:Yada Yada Yada.. More of the same drivel.

[bad-badtz-maru]

I'd like to note that using custom database-layer code makes it very difficult to migrate to a different database platform. As dissimilar as the sql syntax and type handling is across the various rdbms platforms, their "stored procedure" languages are even less compatible.

Re:First

[Faffe]

Fool me once, full me twice...

... Profit!

Re:Yada Yada Yada.. More of the same drivel.

[hardluck86]

I use PostgreSQL as my main DB of choice and have done so for years.
Yes there can be certain hangups with stored procedures when it comes to doing something on the back end (ie: NOT through your nicely programmed front end) but there is also the trade off in data integrity.

Two points:
1) I use stored procedures mostly to keep data integrity throughout the DB where a simple FK isn't enough.
I got the concept years ago - I think inspired from Joe Celko - to NEVER put data integrity in the front end. Or specifically, to never RELY on the front end to maintain data integrity. Front ends change, get updated, rewritten, etc.
The database is the last line of defense where your data is concerned. The DB is where you keep the data integrity.
Mostly that is correct table/relationship design and correct use of FKs but if that calls for stored procedures so be it.

2) Someone earlier made this point too but I agree - sometimes it just makes way more sense to use backend procedures for something. Once compiled they are far less overhead than doing it in a front end usually. Plus - again - if your front end changes or you have multiple interfaces that hit the same database then why write (and maintain) that functionality in separate areas when the single stored procedure will do it?
 

Re:Yada Yada Yada.. More of the same drivel.

[Rich0]

if your front end changes or you have multiple interfaces that hit the same database then why write (and maintain) that functionality in separate areas when the single stored procedure will do it?

Simple - you do that on the server, not on the database. If you have 14 front-ends, they all talk to a single (perhaps scaled in parallel) back-end which implements all application logic, and that talks to the database. The back-end also enforces data integrity (beyond FKs). I'd be interested in an example of what you consider "data integrity" other than a foreign key or unique/non-null constraint.

The front-end should never have access to the database anyway. Sure, give it some ability to do simple input validation to improve responsiveness, but that validation should be repeated on the back side (ideally you use a framework where the back-side just passes the validation rules to the front-side so you aren't coding them twice - I'm talking simple stuff like field lengths, field types, etc).

Business rules should be implemented on the back end as well - once per rule, not once per UI. If there are 14 ways to change the salary field, then there is only one validation rule that ensures the change was approved before being made effective, and so on.

I'm not entirely opposed to the concept of data integrity enforced by the DB, but I'm not quite sure how you're using this term. Every stored procedure that you write is going to make it harder to change database implementations in the future, and it will also make your DB that much harder to upgrade if your vendor changes something. I will say that applications should generally have a layer in-between the presentation layer and the database.

Re:Yada Yada Yada.. More of the same drivel.

[Common Joe]

I'd go a step further and say simply never use stored procs. They really cement you into exactly one platform.

Disagree. No matter what language you pick to do your dirty work, you're still having a certain amount of lock-in. Pick what is best for the problem. For me, 99% of the time it will involve stored procs. It is closer to the database so it is faster. Queries can be better optimized and visually easier to debug. There is less I/O involvement as the data gets shuffled around for processing.

Re:Yada Yada Yada.. More of the same drivel.

[Rich0]

Disagree. No matter what language you pick to do your dirty work, you're still having a certain amount of lock-in.

Yeah, but do you want your database server hosting databases for 2000 applications to be held back on an important upgrade because one of those applications uses a stored procedure that isn't ready for the next version? Virtualizing databases is usually a lot harder than virtualizing applications (well, if you want decent performance per dollar/etc). A build system that relies on GCC 3.0 is much less of a liability than an application that only runs on Oracle 8i.

Re:Yada Yada Yada.. More of the same drivel.

[Common Joe]

Yeah, but do you want your database server hosting databases for 2000 applications to be held back on an important upgrade because one of those applications uses a stored procedure that isn't ready for the next version? Virtualizing databases is usually a lot harder than virtualizing applications (well, if you want decent performance per dollar/etc). A build system that relies on GCC 3.0 is much less of a liability than an application that only runs on Oracle 8i.

If done right, this shouldn't be a concern. First off, no database should be housing 2000 applications. Secondly, every application should be able to be split apart from other applications on a database. When one database becomes overwhelmed, move some of your applications to a second database. (Hopefully, we're using the same definition of database. There are a couple of similar but different definitions from a technical point of view.) To upgrade, you can start a new database on a new machine and then migrate the different apps at different times. I've done that. I've also done the whole kit and kaboodle all at once. I prefer doing it piece meal because it is easier to migrate, but it requires more forethought -- something I've found most apps lacks. It's not harder to do and doesn't take longer... it just takes more forethought.

Re:Yada Yada Yada.. More of the same drivel.

[Rich0]

To upgrade, you can start a new database on a new machine and then migrate the different apps at different times. I've done that.

Sure, and that's exactly what we do at work as well. The problem is that until the last application is migrated you have a super-expensive database server that could be serving hundreds of applications serving a handful that haven't migrated yet. If the apps don't bundle stuff like stored procedures they migrate much more quickly, and hence your super-expensive DB servers are recycled quickly and not running Oracle 8i for the next decade with two apps on them (sure, you can probably recycle some of the RAM/CPUs/licenses, but it is still a cost sink).

I couldn't tell you exactly how many different databases get run on a server at work, but it certainly ranges from dozens to hundreds if not more. Many databases aren't all that busy, but that doesn't mean that they are no longer needed. Other databases strain the capabilities of the largest servers we can find for them and end up involving more exotic technologies to address. In my experience the ones that are hardest to migrate are the ones with business logic implemented in the database.

valentina studio

[Anonymous Coward]

You can check one more tool - Valentina Studio http://www.valentina-db.com/en/valentina-studio-overview 14 Feb 2013 in the 5.0 version added support of mySQL/mariaDB , as well as SQLite, PostgreSQL. It is FREE. Works on Mac, Win and Linux. Includes not only db management but powerfull reports that work again on 3 OS.

Re:Yada Yada Yada.. More of the same drivel.

[jwhitener]

http://www.postgresql.org/support/professional_support/northamerica/

None of the professional services companies above have good 24/7 support for Postgres?