NYCPHP Meetup

[Gary Mort]

On Wed, Nov 10, 2010 at 3:31 PM, Jerry B. Altzman <jbaltz at altzman.com>wrote:

> Hi all,
>
> Just a question for those of you out there dealing with the F/OSS RDBMS's
> out there:
>
> How many of you are using stored procedures (SPROCs) with any great
> regularity?
>
> I know that in the commercial database world use of stored procedures is
> The Way Things Are Pretty Much Done, but I've not seen it in my brief forays
> through the bulk of PHP code I've examined (and needless to say, written).
> Am I just out of it? Is it just not considered usual practice, or am I
> blind?
>
>
The basic question is: is the application written from a coder or a dba's
point of view?

In the open source world, code tends to be written from a coders point of
view.  As such, things which would be done via stored procedures, views,
triggers, etc are instead done inside code.  It's quicker and easier to
change it there.  It also means that the application doesn't have to specify
a version of MySQL, making it more broadly used.

When maintenance of such business logic gets out of hand, coders re-invent
the code and move all the database access to specific table "classes" and
objects, where you can now code the rules directly into the program[or use
something like Doctrine which can do the same thing].

Triggers, foreign keys, views, etc work well from a DBA's point of view
where the data is carefully laid out and you don't want some undisciplined
coder coming along and mucking things up by arbitrarily setting their own
auto increment numbers, or deleting half of the data for a record but
missing the related data from other tables.

Of course, business culture will tend to favor one direction or another.  If
when the data is mucked up by bad code that incorrectly implements business
logic, if the DBA is held responsible, or worse yet has to come in over the
weekend to restore the last backup and somehow merge the data to keep all
the good changes..... well, he's certainly going to want to /control/ this
situation in the future.

Whereas if the programmer is under a time crunch and the DBA is insisting on
a week to review business logic changes[because he has just as many, if not
more, things on his plate and needs to find the time to review it] then you
can get business logic creeping into code so as to get the job done.

But maybe I'm just being cynical here. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20101116/32147276/attachment.html>