NYCPHP Meetup

NYPHP.org

[nycphp-talk] MySQL Case Study - Stanford Graduate School of Business (avail. at HBR Online)

Adam Fields fields at hedge.net
Tue Mar 1 13:48:08 EST 2005


On Tue, Mar 01, 2005 at 01:10:30PM -0500, Mitch Pirtle wrote:
[...]
> For example, take your prototypical application for HR, where you
> track employees, their vacation and benefits. With MySQL you are
> forced to put all of the business rules in the application layer --
> preferably PHP ;-) -- causing unneccessary duplication of effort and
> providing more opportunity for error. Not to mention the added effort
> of porting all that logic from the PHP web application to the .Net fat
> client, or to the python server-side scripts...

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.


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

> you can share that logic with any application that can connect to your
> database. So the web front end is using the exact same rules as the
> fat client for HR people and so on. The language used is no longer of
> consequence, you are free to choose as you see fit.
> 
> > Oracle's great, but it's overkill for all but the most demanding
> > applications.
> 
> It's overkill for anything, even nuclear particle research. I mean,
> once I populated a table with java methods as plaintext, constructed a
> SELECT, compiled and executed the results of the query right in the
> database. Why in the world would you need this? LOL
[...]

Heh.


-- 
				- Adam

-----
** My new project --> http://www.visiognomy.com/diagrams
   **  Flagship blog --> http://www.aquick.org/blog
Hire me: [ http://www.adamfields.com/Adam_Fields_Resume.htm ]
Links:   [ http://del.icio.us/fields ]
Photos:  [ http://www.aquick.org/photoblog ]





More information about the talk mailing list