NYCPHP Meetup

[Mitch Pirtle]

> Here's what I like:
> - automatically generated PHP objects to represent each table in your 
> database
> - these objects inherit a bunch of useful methods from the base class 
> (e.g. update, edit, delete, fetch, etc.)
> 
> Here's what bothered me:
> - Joins of 2 or more tables require awkward config files and don't seem 
> very mature
> (this may be more a problem of the "Data Object" concept than of 
> DB_DataObject's actual implementation)
> - One reason to use these is to avoid hard-coded SQL, but you'd 
> inevitably have to hard-code SQL in these objects for complex queries.
> 
> I'm interested to here what others say...

Ditto from here.  If I was to build a phpMyAdmin clone it would be great 
with this library. But of course, this assumes you are only interested 
in working with one table at a time!

Seemed like a great idea at first, but the more I worked with it, the 
more it reminded me of HTML templating systems - powerful, but 
complicated and time-consuming to learn, and sometimes restrictive 
enough to cost more effort down the road.

-- Mitch

>From hans not junk at nyphp.com  Fri Jan 16 15:47:13 2004
Return-Path: <hans not junk at nyphp.com>
Received: from ehost011-1.exch011.intermedia.net (unknown [64.78.21.3])
	by virtu.nyphp.org (Postfix) with ESMTP id 04437A85F0
	for <talk at lists.nyphp.org>; Fri, 16 Jan 2004 15:47:13 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [nycphp-talk] PEAR DB_DataObject -- opinions?
Date: Fri, 16 Jan 2004 12:47:10 -0800
Message-ID: <41EE526EC2D3C74286415780D3BA9F8752A9D1 at ehost011-1.exch011.intermedia.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [nycphp-talk] PEAR DB_DataObject -- opinions?
Thread-Index: AcPcadQgD/vaBvqUS4WaHztxz7EhBgABpWbw
From: "Hans Zaunere" <hans not junk at nyphp.com>
To: "NYPHP Talk" <talk at lists.nyphp.org>
X-BeenThere: talk at lists.nyphp.org
X-Mailman-Version: 2.1.2
Precedence: list
Reply-To: NYPHP Talk <talk at lists.nyphp.org>
List-Id: NYPHP Talk  <talk.lists.nyphp.org>
List-Unsubscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
	<mailto:talk-request at lists.nyphp.org?subject=unsubscribe>
List-Archive: <http://lists.nyphp.org/pipermail/talk>
List-Post: <mailto:talk at lists.nyphp.org>
List-Help: <mailto:talk-request at lists.nyphp.org?subject=help>
List-Subscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
	<mailto:talk-request at lists.nyphp.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jan 2004 20:47:13 -0000


> Does anybody with any experience with the Pear DB_DataObject=20

Nope.

> package have any opinions about it?=20

Yup.

I deeply dislike any frontend code that attempts to automatically build
SQL statements for you, and/or wraps objects around tables.  I
understand the purpose, which is to abstract database access into easily
managable pieces, but it's the wrong approach.  This is why stored
procedures were invented.

So you use MySQL 4.x and don't have stored procs?  Still, I see
DataObject, and libs similar to it, as detrimental - for several
reasons:

-- you loose any benefit of the DB that you're actually using.  Code
specifically for your database - it's its own world.
-- the overhead quickly becomes enourmous
-- why does application level code need to wrap database access?  SQL is
it's own language - love it.

But then again, this is coming from someone who thinks database
abstraction (in app code, like PHP) is a Bad Thing to begin with.

H