NYCPHP Meetup

[Mitch Pirtle]

On Tue, 1 Mar 2005 13:48:08 -0500, Adam Fields <fields at hedge.net> wrote:
> On Tue, Mar 01, 2005 at 01:10:30PM -0500, Mitch Pirtle wrote:
> 
> It's been my experience (and MySQL certainly encourages this approach)
> that databases are frequently not reused. Obviously, I can't
> generalize to all of the database usages out there - there are lots of
> different patterns. But I think developers for a while have been
> slowly migrating to strongly tying this kind of thing to the
> applications rather than the data stores. Accessing the same data is
> then not done by connecting straight to the db, but through an API
> provided by the app, which enforces your model rules. This gives you
> better portability to other data stores within the context of the app,
> but less easy reuse of the data directly, but also a different kind of
> distributed functionality.
> 
> Whether that's a good thing is arguable - I think there are tradeoffs
> both ways. But it's definitely a pattern I see a lot of.

In the business world I am seeing the exact opposite - each
organization, thanks to MS Access or Filemaker Pro or some such, has
data scattered about the four corners of the earth (engineering,
sales, support and HR) and a consolidation effort is slowly rising up
the priority list.

If the organization decides to commit to a particular database
platform (for whatever reason), not using all of the features
available to your advantage just makes no sense.

And in that scenario (which for my clients is a vast majority) forcing
your developers and consultants to replicate that functionality at the
application level (paying double in efforts and cost) equally makes no
sense.

Not saying this is the only valid approach mind you, just one that
cannot be discounted as a fringe scenario.

> > Put all of the data-related logic in the database as stored procs, and
> 
> In, I must point out, a language that's specific to the database. I'm
> sure you've tried to migrate MSSQL stored procedures to Oracle, yes?
> Not what I'd call pretty.

There are plenty of folks out there (myself included) that would
consider that a moot point.

Writing database-platform neutral SQL is hard in most cases, and
impossible in many others. At that point (just writing SQL calls) you
are already typically tied to a database platform, so why should you
not use what is available? Why not take advantage of the available
features if you can benefit?

As a matter of fact, the "less is more" approach of MySQL forces you
to make changes to your database design as a result. So you could
argue the opposite side of that point with just as much conviction.
;-)

And I would say that one of the patterns you are seeing is actually
the result of MySQL, where developers are 'growing up' in a world
where you cannot enforce logic at the database level and have to
duplicate that at the application layers. Since this occasionally
results in wasted resources (duplication of effort), many of these
databases end up being small islands of data instead, only available
to the one application they were written for. This may not always be a
bad situation though, but I want to stress that in many instances this
can be a very bad situation.

That is why the paired offering of MySQL and PostgreSQL is such a
perfect combination. One gives you speed and ease of use, the other
provides power and features. Both are suported on multiple platforms,
and can be accessed by a myriad of languages and environments. I say
this is the golden age of FOSS databases!

-- Mitch