Slashdot Mirror
MySQL to Get Injection of Google Code
inkslinger77 writes to mention that MySQL has published their software roadmap out through 2009 and it includes an injection of code from Google. Google remains relatively secretive about how their systems work but they are one of the largest users of MySQL. Earlier this year Google signed a Contributor License Agreement which provides a framework for them to contribute code to MySQL. "The search company has done a lot of work customizing MySQL to meet its special needs, which include better database replication, and tools to monitor a high volume of database instances, Axmark said in an interview at MySQL's user conference in Paris. MySQL will include some of those capabilities in future versions of its database, probably in point upgrades to MySQL 6.0, which is scheduled for general availability in late 2008, Axmark said."
Probably because it's a decently-performing ISAM engine with builtin replication. It's not terribly safe (index file integrity is terribly brittle) or smart (it only recently learned there isn't such a date as Feb 30), but you can still at least write ad hoc queries to your tabular data. I doubt Google is using it for HR or CRM.
Done with slashdot, done with nerds, getting a life.
I prefer PostgreSQL but MySQL isn't crappy.
For years MySQL offered better write a few read a lot databases than PostgreSQL. It may still offer better performance for those types of operations. That is the way most websites used MySQL. It is a good tool for some applications. Slashdot is one of them.
Yes I think PostgreSQL is better but MySQL isn't crappy.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
We don't distribute it, so we aren't required to submit the changes back.
We of course, try to contribute back all the changes we possibly can.
If you look around, you'll see we just don't publicize all the changes we contribute back (and we in fact, didn't publicize this one ourselves).
Access isn't "competing" in the same area as MySQL though, SQL Server Express is. MS Access would be more competing with SQLite i beleive (which I never used, so don't quote me, but I beleive that is a less server-centric open source DB?).
JET (Access' database engine) is more of a data storage engine with SQL support than an RDBMS, which MySQL is (which could have been debatable until v.5 I guess, hehehe )
you just like to be contrarian. If postgres were successful you'd be a mysql man
I prefer Postgres to MySQL.
Good for you. Of course, your applications may very well be of a different class, and so perhaps Postgres is a better solution. But remember, if you're doing mostly reads, and not a ton of writes, mysql will blow the socks off virtually any other solution. And, coincidentally, that pretty well describes most web applications in general, and probably Google in particular.
Access is more than just the database. It is a compact tool with little bit of reporting and application development. As a matter of fact, you can have Access connecting to other database engines via ODBC (though the performance sucks in my experience).
I have a site with 3GB of database, updated once daily, in bulk; the rest of the day it's doing several reads per second over the whole thing (indexed so that it can jump to the right parts for each query; but each query tends to hit a different 5-10% of the rows, so all the data is "active"). I found switching from mysql to postgres gave quite a noticable performance increase -- the whole server was no longer crying in pain and grinding to a halt under heavy load~
Note that the DB server only has 512MB RAM -- while the database was smaller than that, mysql was indeed the faster :3
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
I'd say that OpenOffice Base competes with Access. As does Filemaker Pro (do they still sell that?). Most other databases do not because they are just storage engines, and don't really offer much in terms of a user interface for creating data entry forms, or displaying reports.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Here's a simple DB Abstraction layer for Postgres. Just stored procedures, so there's zero possibility for SQL Injection.
// Business Functions
<?php
class Biz
{
// Internal Database Functions
static private $cs;
static function SetConnString($connstring)
{
Biz::$cs = $connstring;
}
static private function SendQuery($q)
{
$db = pg_connect(Biz::$cs);
$r = pg_send_query($db, $q);
return;
}
static private function SendParamQuery($q, $args)
{
$db = pg_connect(Biz::$cs);
$r = pg_send_query_params($db, $q, $args);
return;
}
static private function QueryForRow($q)
{
$db = pg_connect(Biz::$cs);
$r = pg_query($db, $q);
$a = pg_fetch_all($r);
return $a[0];
}
static private function ParamQueryForRow($q, $args)
{
$db = pg_connect(Biz::$cs);
$r = pg_query_params($db, $q, $args);
$a = pg_fetch_all($r);
return $a[0];
}
static private function QueryForRows($q)
{
$db = pg_connect(Biz::$cs);
$r = pg_query($db, $q);
$a = pg_fetch_all($r);
return $a;
}
static private function ParamQueryForRows($q, $args)
{
$db = pg_connect(Biz::$cs);
$r = pg_query_params($db, $q, $args);
$a = pg_fetch_all($r);
return $a;
}
static function AddJournalEntry($PersonID, $EntryTitle, $EntryDetails, $EntryDate)
{
$JournalEntry = Biz::ParamQueryForRow('SELECT * FROM addjournalentry($1, $2, $3, $4);', array($PersonID, $EntryTitle, $EntryDetails, $EntryDate) );
$JournalEntryID = $JournalEntry['addjournalentry'];
return $JournalEntryID;
}
static function GetJournalEntry($EntryID)
{
return Biz::ParamQueryForRow('SELECT * FROM getjournalentry($1);', array($EntryID) );
}
static function GetPersonJournalEntries($PersonID, $PageSize = 20, $PageNumber = 1)
{
return Biz::ParamQueryForRows('SELECT * FROM getpersonjournalentries($1, $2, $3);', array($PersonID, $PageSize, $PageNumber));
}
}
?>
-1 Uncomfortable Truth
MySQL cannot enforce foreign keys constraints on MyISAM tables. It 'kinda' can on Innodb tables.
Having them and enforcing them so they are actually useful are 2 different things.
And if you'd bother to RTFA, you would see that MySQL is moving to away from Innodb to 'falcon'. "but some InnoDB features, like foreign key support and full-text indexing, won't be supported until MySQL 6.1.".
So MySQL is moving away from the only table types that can actually 'kinda' enforce the use foreign keys at all.
I think that would make you the douche.
It's not terribly safe (index file integrity is terribly brittle) or smart (it only recently learned there isn't such a date as Feb 30)
http://en.wikipedia.org/wiki/February_30
Yep Standard is quite different to Enterprise Edition but you can't seriously be comparing MySQL with Oracle Enterprise Edition!
I can't think of anything that is in MySQL that Standard Edition doesn't deliver. And if your looking at EE then really for $40k per CPU you'd be running
something that'd be using the EE features like Label Security or some of the Partitioning / OLAP stuff.
Admittedly as an OCP I might be biased but I wouldn't go near MySQL when there are things like PostgreSQL around, something about wanting my Data Integrity...
Postgres compares nicely to Standard Edition (well once you factor in the costs its pretty neat for the smaller / lower end stuff) but really EE is only competing with
DB2 and even then only DB2 on zOS (which rocks!)
- Anything Microsoft has tried to give to the FLOSS community has had strings attached.
- Just take a look at any of their OS's, particularly ME and Vista.
- Take a look at OOXML.
- Take a look at their "open" license and note that it isn't very open.
- Even Solitaire has a EULA!
Okay, so I made that last one up. I'd provide links, but I'm lazy. I'd also try and look up a eula for solitaire, but I should be doing the work I'm actually paid for, heh.It's a non-server public domain database library. Yes, really public domain. Its databases live in files and there's no server component whatsoever; it's intended for use by a single application (although it supports file locking so that multiple processes can access the same database).
I use it in one of my apps. It's awesome. It's tiny (about 300kB), it's simple (no messing about with starting servers), it's blazing fast (for some tasks, it's up to an order of magnitude faster than PostgreSQL or MySQL --- for others, it's slower, though: benchmarks). More and more programs are starting to use it simply as a document store. It's great.
If you find yourself wanting to use SQL in a situation where only a small number of apps at a time are going to want access, or even if you just want to teach yourself SQL (it's got an excellent command line shell), do check it out.
MySQL has many 'gotchas'. Google around for many sites with lists of them. They are slowly cleaning them up, they have a very bad track record of not keeping data clean. Even their latest 'strict' rules still aren't all that strict. The gotchas have traditionally contained plenty of broken foreign key problems.
The latest versions of Innodb are much better, (earlier versions didn't do any of what you said very well) but now they are going to be moving away from even that.
I do use SQL Server, and Oracle, and Postgresql. Firebird looks interesting, but I haven't had time to play with it. I've had the unfortunate experience of having to work with some MySQL databases, but I refuse to work with that anymore. I prefer mature databases with a full set of database features. Broken databases written by folks who say idiotic things like 'You don't need transactions' don't interest me.