[LA.pm] Anthony Curtis presents Perl Stored Procedures for MySQL

[Aran Deltac]

> -----Original Message-----
> From: losangeles-pm-bounces+adeltac=valueclick.com at pm.org
> [mailto:losangeles-pm-bounces+adeltac=valueclick.com at pm.org] On Behalf
> Of David Fetter
> Sent: Tuesday, August 18, 2009 8:01 PM
> To: Ask Bjørn Hansen
> Cc: losangeles-pm at pm.org
> Subject: Re: [LA.pm] Anthony Curtis presents Perl Stored Procedures for
> MySQL
> 
> On Wed, Aug 19, 2009 at 10:35:36AM +0800, Ask Bjørn Hansen wrote:
> >
> > On Aug 19, 2009, at 4:24, David Fetter wrote:
> >
> >> So MySQL is starting to catch up to where PostgreSQL was,
> >> <http://www.postgresql.org/docs/current/static/release-7-0.html>
> >> almost ten years ago?
> >
> > I love how indignant pgsql users often are that anyone would use
> > something else; all the while "modern" implementations are moving
> > away  from having or using any sort of fancy features in the storage
> > layer.  :-)
> 
> Here's how it goes, over and over and over again: when MySQL doesn't
> have it, it's fluff and nobody could possibly want such frippery, let
> alone need it.  When they get some kind of nonstandard, buggy,
> hemipygian implementation, it's suddenly the greatest thing and you
> can't live without it.
> 
> As to this, "storage layer" business, that's what we call the stuff at
> the other end of the SCSI (alternate spelling: SAS) cable, or if
> you're unlucky, the network cable.
> 
> Jim Gray
> <http://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist%29>
> measured this back in 2003, and those metrics have moved even further
> toward his conclusion, which was essentially, "do all the processing
> you can as close to where the data lives as you can arrange it."
> 
> http://research.microsoft.com/apps/pubs/default.aspx?id=70001

Good info, thanks.

But, I have to agree, the less you do *in* the database, and the more you can shrug off processing to other parts of the system, the better.  I like to treat my database as a very fast flat file storage engine that does very little processing for me.  If I need complex processing, I'll normally create aggregate tables, which are then simple tables that are accessed with simple queries.  Now, this doesn't necessarily contradict the idea of doing data processing as close to where the data lives as possible.  It just rules out the database itself - there are other ways to get close to the DB.  And, of course, there is no one-ring-to-rule them all - sometimes you just have to do it in the database.

This is what Facebook and others do (including my $employer), as much as possible.

Maybe there is truth in your statement that everyone hims-and-haws about how useless features are, and then when MySQL supports it people can't live without it.  But, you should be aware that there is a movement to not do a lot of complex processing within the database itself.  Ignoring that and just assuming that people are being MySQL Zealots isn't going to help anyone.

My 2 cents of opinion.

Aran

> Cheers,
> David.
> --
> David Fetter <david at fetter.org> http://fetter.org/
> Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
> Skype: davidfetter      XMPP: david.fetter at gmail.com
> 
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
> _______________________________________________
> Losangeles-pm mailing list
> Losangeles-pm at pm.org
> http://mail.pm.org/mailman/listinfo/losangeles-pm




This email and any files included with it may contain privileged,
proprietary and/or confidential information that is for the sole use
of the intended recipient(s).  Any disclosure, copying, distribution,
posting, or use of the information contained in or attached to this
email is prohibited unless permitted by the sender.  If you have
received this email in error, please immediately notify the sender
via return email, telephone, or fax and destroy this original transmission
and its included files without reading or saving it in any manner.
Thank you.