Re: The MySQL/PHP pair

"Laconic2" <laconic2_at_comcast.net> wrote in message news:uI2dnfENLMeFZh3cRVn-uw_at_comcast.com...
>
> "Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message
> news:6oqqlc.8nm.ln_at_mercury.downsfam.net...
> > Seems a lot of us here fall into the "the-database-is-the-app" camp,
> wishing
> > to see the database know completely how to defend itself as it were
> against
> > any bad data. Typical tools involve triggers, constraints and so forth.
> >
> > For this reason it seems MySQL is regularly dismissed because it cannot
> > defend itself. It is not a *real* DBMS.
> >
> It depends on how valid Spight's Law is. If you really need a DBMS, even
> when you think you don't, then settling for something tha tlooks like a
> DBMS, but is not really a DBMS may be a terrible pitfall.
>
> If, on the other hand, Dawn is correct in her assertion that a lot of
apps
> can get along, and in fact deliver more bang for the buck by AVOIDING the
> "bulky, awkward DBMS", then maybe MySQL suffers from being TOO MUCH like
a
> DBMS.
>

I'm guessing she is right ;-)
My impression when working with MySQL for a very short time was that it provided the worst of both worlds, however, I've heard more "good results" stories since then, so I'm more inclined to cut it slack and figure that it does help developers with lean & mean, big bang for the buck development. It almost looks like the more we remove from an RDBMS, the more productive our development environment becomes. Hmmmmmmmm. smiles. --dawn

>
> > But you know, it seems that there is a large group of people out there
> > developing against MySQL with PHP. The logic seems to be that you need
a
> > barrier beyond which bad data cannot go, but when the app is deployed
> > through the web, then that barrier is the web layer. If no user can
> > possibly SQL in, then the overpowering lure of PHP/MySQL leads to the
> > conclusion that biz logic can just go into the PHP and you get pretty
fast
> > to the Look Ma, It Works! stage.
> >
> I think the keyword in the above is "against". If the developers are
> developing "against" MySQL, then who is "for" it?
>
> Who is responsible for the data?
>
> > I just wonder if we have been unfair to MySQL.
>
> I don't really know, because I haven't used it. I wouldn't use it in an
> enviroment where the data base is an "integrated data store". I think an
> IDS needs defenses against rogue processes, whether those rogue processes
> reflect lack of foresight, or actual malice.
>
> If your capsule has PHP/MySQL inside it, I don't care, as long as your
> capsule works as advertised. If it doesn't work as advertised, then you
are
> responsible.
Received on Fri Oct 29 2004 - 01:22:51 CEST