[KLUG Members] MySQL adoption

[Adam Williams]

> >>the ability to have *1* would be a huge boon - and fundamentally I don't
> >>see why I can't have *1* - had the developers of given applications been 
> >>more "considerate" of larger issues.
> >There's no compelling reason why you can't have *1*; but it is often not
> >an economically attractive choice to make. ... Also, applications often start life
> >as a small-scale system that doesn't demand this level of abstraction, but 
> >later on....
> Exactly. I know I started out working with linux here at work because I 
> found that php and mysql provided a lot more power than my Access/ASP 
> solution. I started learning from scratch. A quick small project was 
> easily done with MySQL and some 30ish php files. Now over the last two 

Our intranet (and that of most medium sized companies I suspect) is in
the same state.  Apache/PHP came online as an easy and rather nifty way
to solve a coiple of problems.  And the intranet grew like a malignant
cancer.

> years that has grown and grown and now includes more than 50 php class 
> files, and a couple hundred other php files. Sure I would love to have 
> everything be database independent now...but like everyone else I just 
> can't justify the time to go back and redo so much work at the moment.

Right;  hence the emphasis on getting the message out to start that
way.  Because hundreds of more-or-less stand alone PHP files is a mess. 
PHP and other scripting lanaguage are really handy,  but their also a
trap.

> >>Behind the PostgreSQL/MySQL debate lie interesting assumptions concerning 
> >>application developement and deployment.
> >I would prefer to pursue that discussion, and believe that it is not framed
> >well as a "PostgreSQL/MySQL debate".
> I agree with you here. I get a magazine from www.phparch.com (GREAT 
> stuff if you're into PHP dev) and in their last issue they had an 
> awesome article on migrating from MySQL to PG. In it the author 
> discussed the limitations in MySQL and how things such as views and 
> triggers were meant to be used to cut down on application code and 
> perform operations that really separate out the DB layer from the 
> application. I thought it was a great read because while I knew what 
> triggers and views were from an db class I had in college, I have never 
> sat down and looked at their practical uses. I can see how it would be 
> very useful to take some operations from the code I write and hand it 
> off to the database to work
> The benefits are not only the separation of logic, but in large systems 
> with the application and database reside on different servers I can see 
> how having the db server handle some functions would help lighten the 
> load on the app side.

Not only lighten to load, but most imporantly impose some consistancy
across applications.  You can't trust, no matter how well you document,
every app to do something the same way or to make the same assumptions
about the data - it just doesn't work.  Rather than joining lots of
tables in some report you create a view, and the reports use that view; 
saves immense amounts of grief later on down the road when management
decides to change something and your like "Uh, so how many places do I
need to make an adjustment for that?"  The answer to that question is
almost always that noone knows.