Re: Why use PHP? What are the disadvantages?

[MattLavinder@xxxxxxxxxxxxxxxxxxx]

At one point PHP had an integrated database.  Not sure if it was any good,
but I don't think anyone used it so it was removed.  Fact is distributed
workloads are so common people (outside the IBM i world) don't even know
this debate exists.

With the "No-SQL" movement and frameworks, I tend to wonder if we aren't
heading back towards integrated databases. To me it seems it is only a
matter of time before someone comes out with the new, modern, open-source
language that puts everything together and claims it is revolutionary.
Sure was...back in 1987.


> Criticizing PHP is kind of like throwing your baseball mitt out in
> front of a steam roller, in an attempt to knock it off course.  But
> Tom's experience with stored procedures is indicative of the types
> of pitfalls inherent in "distributed" workloads.  And PHP is like
> Java EE and Microsoft aspx.net in that you must interface with host
> resources via distributed interfaces of one sort or another.
>
> You might contrast that with RPG programs, which run in the same
> address space as the routines that perform database I/O.  Native
> interfaces are much more streamlined; much easier to debug.
>
> It's not just a question of learning multiple languages, it's more a
> question of using distributed architecture.  Of course vendors do
> their best to make the interfaces appear simple.  But there's no way
> to make than as reliable or efficient or even as flexible as native
> interfaces, running in the same address space.
>
> If you dig deep and analyze distributed architectures, you find
> multiple levels of interfaces that map data sets from one type of
> component to another in an extended chain.  It may be mapping an SQL
> result set to a PHP array, which in turn is mapped to another OO
> component which may be bound to another OO component which may be
> mapped to a UI component.  A change to a single record in a database
> may trigger a series of component data set refreshes all the way
> down the line to the browser.  A failure may occur at any link alongthe
chain.
> I see this in most database maintenance models, where the user
> begins with a grid component showing a list of records.  The user
> double clicks on a record to activate and edit record window.
> Changes are written to the server.  Then a series of data sets are
> refreshed, ending with a refresh of the UI grid.  What a waste of
> resources.  But that's the norm, under distributed architecture.
>
> -Nathan.