Re: The MySQL/PHP pair
Date: Thu, 28 Oct 2004 09:58:37 -0400
Message-ID: <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.
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
> 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?