×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

MySQL to Get Injection of Google Code

ScuttleMonkey posted more than 6 years ago | from the who-to-trust-on-replication dept.

Databases 195

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

195 comments

MySQL? (-1, Flamebait)

Nicopa (87617) | more than 6 years ago | (#21101545)

Why did Google choose such a crappy database? Is there any secret reason?

Re:MySQL? (0, Redundant)

moogied (1175879) | more than 6 years ago | (#21101559)

My guess? Because its insanely popular and works really well. I.E. There is a huge community behind it.

Re:MySQL? (3, Informative)

nuzak (959558) | more than 6 years ago | (#21101629)

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.

Re:MySQL? (5, Informative)

LWATCDR (28044) | more than 6 years ago | (#21101631)

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.

Re:MySQL? (1, Interesting)

Anonymous Coward | more than 6 years ago | (#21102071)

The comment in the article that foreign keys won't be supported until 6.1 speaks for itself. It might not be *crappy* to some but to me this alone makes it quite useless and this admission is only the tip of the iceburg. I sincerly hope that one day MySQL will graduate from the realm of being a toy DB.. That said toy DB's are quite useful for a number of applications, just not any I personally care about.

Wake me up when even a single financial institution uses it for transaction processing.

Re:MySQL? (1)

LWATCDR (28044) | more than 6 years ago | (#21103377)

"That said toy DB's are quite useful for a number of applications, just not any I personally care about."
Like the one you are using right now?

Re:MySQL? (3, Insightful)

marcansoft (727665) | more than 6 years ago | (#21103607)

That's like saying PCs are toys, because banks use mainframes to handle your credit card transactions.

That a device or program isn't suited for a certain task doesn't mean it's a toy.

Re:MySQL? (4, Funny)

Frosty Piss (770223) | more than 6 years ago | (#21101675)

Why did Google choose such a crappy database?
Clearly they know something you don't.

Re:MySQL? (1)

torchdragon (816357) | more than 6 years ago | (#21102399)

No no no, obviously the parent knows far more than a multi-billion dollar company that only specializes in high impact, ridiculous performance databases.

Duh.

Linus > Every Linux User. Ever.
Jobs > Everyone. Ever. We mean it. Seriously.
Ballmer > Duck! Incoming chair!
Bush > All you stupid smart people.

See? Now we can keep growing the list.

Re:MySQL? (1)

LurkerXXX (667952) | more than 6 years ago | (#21102711)

They know for their particular application, if they only return 47,000 hits, instead of 49,500, it's really no big deal. If they return some pages that aren't really relevant, also not a big deal.

That's kind of a rare use of a database.

When most of use use databases we need real exact numbers from it. Foreign key enforcement is a must. 'Strict' is not an option.

That's why they can use a crappy database, because their answers don't have to be complete or entirely correct. Crappy is 'good enough'

Re:MySQL? (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21102893)

Clearly you have your head up your ass. Stop masturbating while dreaming of your mom, and get out of the basement.

Re:MySQL? (1)

corifornia2 (1158503) | more than 6 years ago | (#21103029)

WTF are you guys talking about MySQL has foreign keys you douche bags.

Re:MySQL? (4, Informative)

LurkerXXX (667952) | more than 6 years ago | (#21103129)

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.

yes (-1, Troll)

Anonymous Coward | more than 6 years ago | (#21101777)

the secret is...

They aren't blindly biased and actually examine their options.

But you didn't hear it from me!

Injection? (5, Funny)

Tetsujin (103070) | more than 6 years ago | (#21101589)

Somehow when I put "SQL" and "injection" together, I don't like the result...

Well, except for when it involves Little Bobby Tables [xkcd.com]...

Re:Injection? (2, Insightful)

Phroggy (441) | more than 6 years ago | (#21101753)

Yeah, I was about to post the same thing. Can we use some different terminology when talking about helpfully contributing code to a database project?

But... (0)

Anonymous Coward | more than 6 years ago | (#21102035)

SQL injection is useful! That's how I got my first million.

Re:Injection? (-1, Troll)

MarsDefenseMinister (738128) | more than 6 years ago | (#21103191)

For Pete's sake, do liberals have to put their political correctness into EVERY thing they see? Quit forcing other people make a hash out the language just to protect your sensitive little brains and the conclusions they jump to.

Re:Injection? (1)

fishbowl (7759) | more than 6 years ago | (#21103733)

Liberals? Are you one of those people who blames everything on an ideology because it's popular among your peers?

Re:Injection? (5, Insightful)

necro2607 (771790) | more than 6 years ago | (#21102579)

Yeah, who writes these headlines? It's like, let's throw together the most fucking sensationalist possible combination of words to evoke certain responses in peoples' minds when they read this headline. Instead of just writing something constructive like "MySQL adds code from Google", it has to be some sensationalistic crap so as to make people go "OMG SQL injection?!? Sum1 haxed MySQL??" and immediately read the article. What is this, FOX News or something? :P

Hells yeah (5, Insightful)

rsborg (111459) | more than 6 years ago | (#21101597)

Eat that, Oracle.
Seriously the database layer is being commoditized, and MySQL and PostgreSQL are leading the way.

My only question, was Google required to disclose these changes, or are they just doing the right thing (again)?

Re:Hells yeah (4, Informative)

Dan Berlin (682091) | more than 6 years ago | (#21101749)

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

Re:Hells yeah (0)

Anonymous Coward | more than 6 years ago | (#21102899)

Thanks

Re:Hells yeah (1)

Bodrius (191265) | more than 6 years ago | (#21101791)

Maybe they're doing the selfish for-profit thing, which can very well be 'the right thing' for everyone else.

By putting their code back into the main branch, they do not have to carry the perpetual maintenance cost of the fork and get to distribute the development cost across the rest of the mysql devs/users.

Re:Hells yeah (0, Flamebait)

Tony Hoyle (11698) | more than 6 years ago | (#21102217)

Insightful? Fine for a web server perhaps.

Look in the corporate space. Oracle is everywhere. SQLServer is around (not popular in my experience). Mysql is nowhere.

Mysql has a long way to go to justify its $200 per client cost (the GPL version being pretty useless for deployment - mysql consider releasing an application that is even compatible with their client as 'distribution' of Mysql (check their site.. it's amazing to read their interpretation of the GPL) and unless you're 100% GPL you're liable for the client cost for every single user).

Re:Hells yeah (1)

lib3rtarian (1050840) | more than 6 years ago | (#21103405)

Maybe I'm missing your point, but $200 is a pittance. The last I checked, which was yesterday, Oracle came with a price of $40,000 just to enter the game!

Umm No... (2, Insightful)

cmdrbuzz (681767) | more than 6 years ago | (#21103765)

You'd be wrong then. Have a look at the Oracle Store and you can get Standard One for $149 per user (5 User minimum @$745.00)
Or you could get unlimited users for $4995 per CPU....

Oracle is expensive, its just not that ridiculously expensive.

Re:Umm No... (1)

lib3rtarian (1050840) | more than 6 years ago | (#21104719)

Umm, Oracle Standard is a lot different than Oracle Enterprise, something you may or may not realize. I was comparing the associated points for Enterprise Level.

Re:Umm No... (2, Informative)

cmdrbuzz (681767) | more than 6 years ago | (#21105011)

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!)

Re:Hells yeah (2, Insightful)

Daniel Dvorkin (106857) | more than 6 years ago | (#21103695)

Look in the corporate space. Oracle is everywhere. SQLServer is around (not popular in my experience). Mysql is nowhere.

Define "coprorate space." Big companies tend to be Oracle or SQL Server shops, true; really big companies tend to be Oracle or DB2. But there are a lot of small and medium-sized businesses using MySQL -- and because there a lot more SMBs than there are megacorporations, and because DBA demand doesn't scale linearly (a 10,000-employee corporation doesn't need a hundred times as many DBAs as a hundred-employee corporation) there's plenty of MySQL work out there. Postgres, unfortunately, not so much.

Re:Hells yeah (1)

Chapter80 (926879) | more than 6 years ago | (#21102989)

MySQL leading the way? I don't think so. Take a close look at their client licensing.

The one who led the way toward a free database was HP, with their Image product, and later, their SQL version. Image had been free (as in beer) as early as 1975, which is one of the reasons HP gained so much mini-computer market share: Cheap Value-Added-Resellers and Software shops could package their custom software with a database for a reasonable price.

Win over the developers with cheap price and good tools (ahem, Facebook, Yahoo, Google). Same strategy is repeated year after year. Standing on stage yelling "Developers! Developers! Developers!" doesn't cut it.

Re:Hells yeah (1)

CodeBuster (516420) | more than 6 years ago | (#21103211)

Seriously the database layer is being commoditized

It has been commoditized for some time now, the concept of database was simply too valuable and generic to remain a franchise. Oracle especially and Microsoft more recently have realized this and are now offering their basic packages free of charge. The remaining franchises are in high end clustering and other advanced large scale data performance enhancements which only come into play in very large data centers with large and complex databases. The vast majority of everyday database applications are now well served by the free versions.

My only question, was Google required to disclose these changes, or are they just doing the right thing (again)?

As per the GPL, one is only required to disclose changes (and provide source) if the program is distributed. If you modify the program and decide that you do not want to distribute, but use it only for your own personal or internal company use then that is allowed. You could even operate a website off of your modified version and generate profits without being forced to release the code to your modifications. However, the modified program can never be sold or even given away to any external party without triggering the requirement to distribute the source code to all modifications along with it to anyone who asks.

Very Niiiice (1)

bostons1337 (1025584) | more than 6 years ago | (#21101635)

Sounds like a win win situation for everyone. I've always like MySQL better than Access, not just because its an M$ product. I don't know about all of you but I can't wait to download this and see these new updates. Hopefully it won't just be in the enterprise edition.

Re:Very Niiiice (1)

ThirdPrize (938147) | more than 6 years ago | (#21101817)

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

makes me think it will be.

Re:Very Niiiice (4, Insightful)

Chineseyes (691744) | more than 6 years ago | (#21101827)

Why on earth would you compare MySQL with Access? I'm more of a Postgres guy myself but even Mysql deserves better than that.

Re:Very Niiiice (3, Informative)

Shados (741919) | more than 6 years ago | (#21101849)

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 )

Re:Very Niiiice (1)

Abcd1234 (188840) | more than 6 years ago | (#21102083)

To provide a more accurate comparison, JET is probably more akin to SQLite [sqlite.org], which, BTW, is frickin' awesome.

Re:Very Niiiice (2, Informative)

jack_csk (644290) | more than 6 years ago | (#21102087)

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

Re:Very Niiiice (1)

LurkerXXX (667952) | more than 6 years ago | (#21102435)

True, but it does make for fast prototyping of forms/reports you might then do in another language.

Re:Very Niiiice (1)

Shados (741919) | more than 6 years ago | (#21102543)

It is, but usually when people are comparing Access to other stuff, they refer to JET, not the MS Access application itself.

Re:Very Niiiice (2, Informative)

CastrTroy (595695) | more than 6 years ago | (#21102595)

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.

Re:Very Niiiice (1)

Shados (741919) | more than 6 years ago | (#21104627)

Correct. Thank you for finding much better examples :) Don't know why I didn't think of those.

Re:Very Niiiice (1)

sootman (158191) | more than 6 years ago | (#21104183)

MS Access is a database but it's also a complete program with a nice GUI front-end and lots of other stuff. You can make a whole form-based application with Access. MySQL itself is just a raw DB with nothing but a command-line interface out-of-the-box--in that sense, MySQL is roughly comparable to JET. (Scalability, stability, etc. issues aside.) SQLite is a great little thing but it's really just a step up from a flat text file--it responds to SQL syntax but it's not strict at all. You can put arbitrary length strings into integer columns, floating point numbers in boolean columns, or dates in character columns. [sqlite.org] Overall, the three are not really directly comparable. For some things, you could use any one of the three and not notice the difference. For anything else, only one might do.

Waiting... (0)

Anonymous Coward | more than 6 years ago | (#21101727)

I love MySQL and use it for my site but i'm still waiting for some bugs/request features that has been in the tracker for years, like "limit has to be a constant and can't be parameterized" which is very annoying if you're using a stored procedure to fetch a page of results...

Will it ever be solved?

Transplant to Postgres? (5, Interesting)

Doc Ruby (173196) | more than 6 years ago | (#21101803)

I prefer Postgres to MySQL. I wonder whether these MySQL revisions will be generic enough to use to improve Postgres.

I also wish these two databases interoperated more. I'd like to use a MySQL proxy to my Postgres server, so apps depending on MySQL could still work, but use Postgres to actually process the data (or just serve as a master DB for replication). Porting apps between DBs, and huge projects to join across different apps' tables in different types of DB servers should be ancient history. Mixed DB-type clusters might not be high performance, but they'd get the iterative development started, after which performance could be just an optimization, which is the right way to do it anyway.

Re:Transplant to Postgres? (1, Informative)

Anonymous Coward | more than 6 years ago | (#21101907)

you just like to be contrarian. If postgres were successful you'd be a mysql man

Re:Transplant to Postgres? (0)

Anonymous Coward | more than 6 years ago | (#21102673)

That's just typical /. behaviour.

Re:Transplant to Postgres? (1)

Doc Ruby (173196) | more than 6 years ago | (#21102719)

I do a lot of writes. It works better than MySQL, and was especially so when I started some of these apps and referential integrity and fuller SQL semantics were supported better by Postgres than by MySQL.

Google had to upgrade MySQL quite a lot for its use because MySQL needed a lot of improvement. Postgres was a lot closer to what I need right from the start, without having Google's development resources.

But then, you're an Anonymous Coward. You just like to criticize what you don't understand. If you had a well-founded criticism, you'd post with a consistent username.

Re:Transplant to Postgres? (2, Informative)

Abcd1234 (188840) | more than 6 years ago | (#21102049)

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.

Re:Transplant to Postgres? (1)

Doc Ruby (173196) | more than 6 years ago | (#21102423)

They are different. My apps mostly replace the filesystem with DB records, and do a lot of logging for analysis/reporting.

Of course, the different scenarios we're discussing mean that MySQL would be best as a datamart frontend to Postgres. I'd love to write everything to a Postgres API, then deploy it with a script that ports the Postgres schema to a MySQL, which MySQL just replicates to the Postgres, and presents the MySQL interface to web apps. While the Postgres retains the master data, and presents an interface to apps which do a lot more writes.

Re:Transplant to Postgres? (2, Informative)

shish (588640) | more than 6 years ago | (#21102443)

if you're doing mostly reads, and not a ton of writes, mysql will blow the socks off virtually any other solution.

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

Re:Transplant to Postgres? (1)

Mex (191941) | more than 6 years ago | (#21104553)

What the hell is that last emoticon? ":3"

Is it the elephant man? Is it two eyes and two testicles right below it? Is it the emoticon for "Teabag"?

I just can't keep up with the internet these days.

Re:Transplant to Postgres? (1)

LurkerXXX (667952) | more than 6 years ago | (#21102533)

Only if you are using MyISAM tables, which can't enforce foreign key constraints. (meaning you can have junk data and the database won't tell let you input garbage rather than require valid data).

Personally I prefer the right answer a tenth of a second slower, rather than a wrong answer fast.

If you use Innodb tables, you have no speed gain over postgresql, and you can't handle the number of concurrent users you could with postgresql.

Re:Transplant to Postgres? (1)

Abcd1234 (188840) | more than 6 years ago | (#21103987)

Personally I prefer the right answer a tenth of a second slower, rather than a wrong answer fast.

No, you prefer that the DB give you more guarantees about consistency (yes, you can get by without FK constraints), at the expense of performance. And a tenth of a second would be a *significant* performance improvement for extremely large volume sites.

Again, it very much depends on the application involved. Pick the right tool for the right job. Sometimes, that's mysql.

Re:Transplant to Postgres? (1)

jimicus (737525) | more than 6 years ago | (#21102395)

Postgres is completely different under the hood, so I don't think that's terribly likely.

Bit of a shame in many ways, because while there are commercial addons to Postgres which give decent clustering support - either for HA or performance - AFAICT the free Postgres server can offer very little in the way of clustering.

Re:Transplant to Postgres? (1)

laffer1 (701823) | more than 6 years ago | (#21102509)

Isn't there a licensing issue by transplanting to postgres. I was under the impression it was BSDL and MySQL is GPL. Obviously one could use general ideas and implement them again for postgres.

I'm hoping that MySQL 6 is faster on other operating systems than previous versions. The current design makes many assumptions based on Linux. MySQL is running on many operating systems now and shouldn't be so OS centric. You can get binaries for Windows, Mac OS, Solaris, and many of the BSDs. Some of the FreeBSD 7 benchmarks show a serious improvement with postgres, but terrible MySQL performance.

Before anyone is critical of my comments, remember that I use MySQL at work and home.

Re:Transplant to Postgres? (1)

Doc Ruby (173196) | more than 6 years ago | (#21102667)

Postgres is under the BSD license [freshmeat.net]. I wonder whether a developer could port the MySQL GPL code directly to Postgres, and release the Postgres diff as patch, under the GPL. Does the GPL prohibit using a GPL patch on a BSD app?

Re:Transplant to Postgres? (1)

CastrTroy (595695) | more than 6 years ago | (#21102665)

Applications requiring one database or another should be ancient history. However, whenever you look up a how to access MySQL from PHP, you'll find stuff that recommends using all the mysql_* functions. This is the quick way to creating an app that absolutely depends on MySQL. Really people should be using PDO [php.net], instead of mysql_ or pgsql_. Of course the real solution is to use a database abstraction layer, but I've never found a good way to create an n-tier web appliction in PHP.

Re:Transplant to Postgres? (1)

mysqlrocks (783488) | more than 6 years ago | (#21102861)

Really people should be using PDO, instead of mysql_ or pgsql_. Of course the real solution is to use a database abstraction layer, but I've never found a good way to create an n-tier web appliction in PHP.

Well not strictly n-tier [wikipedia.org], you can get pretty darn close with Zend_Db [zend.com] (which contains adapters to PDO), Zend_View [zend.com], and Zend_Controller [zend.com].

Re:Transplant to Postgres? (1)

ShieldW0lf (601553) | more than 6 years ago | (#21103287)

Man, are you on glue?

If it has a browser on one end, a database on the other and a web server in the middle, it's an n-tier application. It doesn't even matter if the database is on the same physical server, it's still an n-tier application because the browser isn't directly connecting to the database.

What you're describing is an application with an MVC architecture running as an n-tier application.

Hell, if you'd read the link you posted, you'd know that.

Re:Transplant to Postgres? (1)

mysqlrocks (783488) | more than 6 years ago | (#21103831)

Is rudeness a badge of honor on slashdot (queue the you must be new here jokes)?

If it has a browser on one end, a database on the other and a web server in the middle, it's an n-tier application. It doesn't even matter if the database is on the same physical server, it's still an n-tier application because the browser isn't directly connecting to the database.

You've zoomed the focus out a level - we were talking about the application architecture and database abstraction layers. Yes, of course the web itself is n-tier if you're dealing with anything other than a server with static content. That's not what we were talking about. I think pretty much everyone here has some idea how the web works, we were talking about the details of the application architecture.

FTA that I linked to:

Conceptually the three-tier architecture is linear. However, the MVC architecture is triangular: the View sends updates to the Controller, the Controller updates the Model, and the View gets updated directly from the Model.

MVC is technically not n-tier since there is no middleware tier that data must pass through. With MVC, the View can read data directly from the Model. Personally, I like working with MVC and don't find it lacking anything that a "true" n-tier architecture could provide. But, that's just me.

Re:Transplant to Postgres? (1)

flooey (695860) | more than 6 years ago | (#21104669)

Is rudeness a badge of honor on slashdot (queue the you must be new here jokes)?

I'm not really sure, I'm new here.

Re:Transplant to Postgres? (2, Informative)

ShieldW0lf (601553) | more than 6 years ago | (#21103039)

Here's a simple DB Abstraction layer for Postgres.  Just stored procedures, so there's zero possibility for SQL Injection.

<?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;
    }

    // Business Functions
    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));
    }

}
?>

Re:Transplant to Postgres? (2, Insightful)

CastrTroy (595695) | more than 6 years ago | (#21104027)

See, that model falls apart once you have a database with 50 tables. Because you have to load and parse a lot of script for every page load. I'm not sure how much (if anything) is cached by PHP, and how much recompiling has to be done on each load. Also, if you want to break you stuff up into a lot of different classes, with each class in a different file, then it quickly becomes a large mess of stuff to include in each page. I find that this is one of the major advantages of having a compiled language.

Re:Transplant to Postgres? (2)

dfetter (2035) | more than 6 years ago | (#21104785)

Applications requiring one database or another should be ancient history.
Why on earth would that be? Modern DBMSs aren't just data buckets. They're full-on application servers that happen to have a really killer storage subsystem. In the Free Software space, there's only one that's really modern in that sense, and it's not MySQL ;)

However, whenever you look up a how to access MySQL from PHP, you'll find stuff that recommends using all the mysql_* functions. This is the quick way to creating an app that absolutely depends on MySQL.
That's only a problem because of MySQL's limitations, not because it maxes out MySQL's capabilities.

Really people should be using PDO, instead of mysql_ or pgsql_. Of course the real solution is to use a database abstraction layer, but I've never found a good way to create an n-tier web appliction in PHP.
I've never seen an automatic database abstraction layer that was worth a plugged nickel over the long haul. Other kinds--the kind where you create a database-interaction library and mandate that all database calls go through it--can scale out quite huge. The aforementioned approach has the added bonus of real OO design, which makes it *much* easier to maintain. :)

Re:Transplant to Postgres? (1)

ShieldW0lf (601553) | more than 6 years ago | (#21102707)

Personally, I don't trust MySQL to anything more significant than forum software. Referential integrity is important, strong typing is important, enforcement of declared constraints is important. MySQL can't be trusted with any of these things.

For a long time, the MySQL team put forth that good design practices were not important. They never did accomplish the task of designing a good table manager. They hobbled along into enterprise space after InnoDB was written by someone else. Now it belongs to Oracle.

If you trust this database software with anything where accuracy is important, you're asking for trouble. Great for Google, sure. How the hell are we supposed to confirm that it dropped a few pages that might have been more relevant?

I'll stick with PostgreSQL for my OSS DB needs, thanks. If it's not fast enough, I'll use technologies like memcached.

Re:Transplant to Postgres? (1)

Doc Ruby (173196) | more than 6 years ago | (#21102845)

Me too.

Do you have a way to make Postgres clustering work as well/easily as MySQL clustering?

Re:Transplant to Postgres? (1)

ShieldW0lf (601553) | more than 6 years ago | (#21103495)

I couldn't comment about making it work as well as MySQL clustering, but I haven't had any problems with using Slony-I. It can be kind of complicated though. I'm expecting that my latest project is going to need some horizontally partitioned materialized views on the slaves to allow it to scale up effectively.

Re:Transplant to Postgres? (1)

dfetter (2035) | more than 6 years ago | (#21104981)

Do you have a way to make Postgres clustering work as well/easily as MySQL clustering?
Although "clustering" is big in Buzzwordia these days, it's not clear what that term means. Are you talking about high availability? Failover? Read scaling? Write scaling?

A single-image Postgres box will beat the pants off a MySQL cluster on write-intensive loads. See http://forums.mysql.com/read.php?25,93181,93181 [mysql.com] for an example.

Re:Transplant to Postgres? (1)

MobyDisk (75490) | more than 6 years ago | (#21102757)

I think that is nearly impossible. If you want an app to work with multiple databases, then it needs to go against a standard like ODBC and be as close to the ANSI SQL standard as possible.

Re:Transplant to Postgres? (1)

Seumas (6865) | more than 6 years ago | (#21102871)

I do all of my projects in postgres, because postgres did transactions long before MySQL ever got around to it. It would take a significant bundle of improvements above and beyond anything postgres offers for MySQL to sway me over to their system.

Re:Transplant to Postgres? (1)

CodeBuster (516420) | more than 6 years ago | (#21103041)

I also wish these two databases interoperated more.

This can be a sticky issue in software design (i.e. how much support for external systems to include directly in the system). However, it has been my experience that it is better, from a design perspective, to create a standard interface for communications, or use one that has already been defined (W3C Web Services [w3.org] come to mind, but other types are possible) whereby adapters [wikipedia.org] can be built to mediate and facilitate communications between pairs of systems. The use of the adapter pattern creates services which are decoupled from their clients allowing both to vary independently behind their respective interfaces and isolating any changes in the specific adapter(s). This is desirable from a design standpoint, even if it costs some performance (performance alone is almost never a good reason to violate abstraction), because it increases cohesion between components while at the same time reducing and minimizing coupling.

6.0 in 2008? (3, Insightful)

JumboMessiah (316083) | more than 6 years ago | (#21101977)

Mysql 5.1 has been in preproduction since November 2005 and still isn't available as a GA release (aka don't use it in production). Are they sure they can get a 6.0 GA release out by next fall?

This is really good of Google to contribute this back, I'm just wondering how long it will be before we all can utilize their changes. I hate to see the code stay stuck in the devel cycle for three years when Goggle is using it to their advantage right now at this very moment.

I wonder... (1)

dfdashh (1060546) | more than 6 years ago | (#21101987)

They are the changes mentioned here [slashdot.org], I think. I guess the changes [google.com] will be ported to MySQL 6 (if any porting needs to be done at all...who knows at this point).

Their grubby little hands (0, Troll)

C_Kode (102755) | more than 6 years ago | (#21102039)

Damnit, Google is just like Microsoft. They always have to get their grubby little hands on everyone elses good stuff. Forkit, I'm forking it! :)

Google needs to add an SQL function (5, Funny)

LiquidCoooled (634315) | more than 6 years ago | (#21102447)

They need to add a GOOGLE function to allow queries to be searched nicer.

SELECT * FROM articles WHERE GOOGLE('boobies');

something similar might be available but it is a PITA to list the fields to search and specify the operators etc

Re:Google needs to add an SQL function (2)

RoloDMonkey (605266) | more than 6 years ago | (#21104241)

I know your just trying to be funny, but what you are describing already exists in MySQL. It's called FULLTEXT [mysql.com].

Re:Google needs to add an SQL function (1)

LiquidCoooled (634315) | more than 6 years ago | (#21104421)

Actually I wasn't and that FULLTEXT indexing method looks really interesting and just the kind of thing I was thinking about.

Looking at it, they even give an articles table as an example :)

mysql> CREATE TABLE articles (
        -> id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
        -> title VARCHAR(200),
        -> body TEXT,
        -> FULLTEXT (title,body)
        -> );

Thanks for the link.

Re:Google needs to add an SQL function (2, Funny)

j. andrew rogers (774820) | more than 6 years ago | (#21104691)

"They need to add a GOOGLE function to allow queries to be searched nicer.

SELECT * FROM articles WHERE GOOGLE('boobies');"


I don't know about MySQL, but you can pretty trivially write extensions to PostgreSQL that do exactly this kind of thing. In fact, I've written a number of such extensions to PostgreSQL that make Google resources seem like local resources in a PostgreSQL database. (This kind of deep and easy customizability is one of the things I find to be a killer feature of PostgreSQL relative to many/most other databases.)

okay great (0)

Anonymous Coward | more than 6 years ago | (#21102565)

Now when is somebody going to actually improve the DATA management aspects of MySQL, rather than the SERVER management? How about making more views updateable? Or at least allowing triggers on views? So I can refactor my databases? Nah, I guess that would require somebody who actually cracked open a book on database theory once.

In Soviet Russia... (0)

Anonymous Coward | more than 6 years ago | (#21102773)

SQL has Google injections?

Good stuff coming out of google (4, Interesting)

shmert (258705) | more than 6 years ago | (#21104763)

For the Java coders out there, Google is also releasing google collections [google.com], which looks quite nice. There's a new interview here [javalobby.org] with the authors. It's fun stuff to poke around in, and appears to be extremely well-written code.

Once this stabilizes, I'll probably be using it. It's nice to see such a direct impact on my work from their contributions. Thanks guys!

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...