Re: Why use PHP? What are the disadvantages?

I think what you might be referring to as an integrated database would
be the Berkeley DB implemented via the dba extension. It is still
there, though most people end up using SQLite if they are looking for an
embedded DB because it is easier to cross-pollinate with other SQL DB's
like MySQL.

Kevin Schroeder
Technology Evangelist
Zend Technologies, Ltd.
www.zend.com
www.twitter.com/kpschrade
www.eschrade.com


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of MattLavinder@xxxxxxxxxxxxxxxxxxx
Sent: Tuesday, April 20, 2010 8:28 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Why use PHP? What are the disadvantages?


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.