× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.