NYCPHP Meetup

[Dan Cech]

Phil Powell wrote:

> Dan Cech wrote:
>> The differences between MySQL 4.x and 3.23.x are not that great when 
>> dealing with the simple SQL required for this type of system, and thus 
>> far in all my PHP work I haven't found a situation where you can't 
>> come up with a solution which will work with the 2 different flavours 
>> of MySQL.  Admittedly I try to restrict myself to code which will also 
>> function on PostgreSQL, Oracle and MSSQL, but my point is that the 
>> majority of problems can be solved without having to resort to vendor 
>> or release-specific SQL extensions, if that is what is required.
>>
>> As for using a shell script to execute queries through the MySQL 
>> command-line client, my opinion is that it is a Bad Thing.  Admittedly 
>> you don't have the advantage of being able to use transactions anyway, 
>> but by designing your system this way you are not only breaking up 
>> what should really be an atomic database operation into several 
>> different parts, but also creating a solution which cannot be easily 
>> upgraded to take advantage of features such as transaction support.
>>
> You do have a point.. I guess I just can't think of a solution that 
> would fit the current environment.  However,  I would think that 
> allowing for futuristic transactional support is in order by providing 
> OO-level switches that determine the flavor of your MySQL and act 
> accordingly.

Great!  Though why you would need separate SQL for the 2 versions of 
MySQL is still something of a mystery to me, what exactly are you trying 
to do that would cause problems with 3.23.x?

> Sorry, but I don't understand the term "atomic" in this case.

What I mean by 'atomic' is that the operation should (theoretically) be 
a single indivisible operation.  Unfortunately this is a dream which is 
almost always unattainable.

What transactions do is to try and 'fake' this by letting you either 
commit or rollback the entire transaction as one unit, effectively 
turning your sequence of SQL commands into a single entity.

On a side note, you can easily implement transaction support in your 
existing code (as well as support multiple databases) if you use the 
ADOdb database abstraction layer (I'm sure PEAR::DB can do it to, but I 
use ADOdb).  Using these systems you can write code which will take 
advantage of transaction support if it is available, but still work on 
databases which do not support transactions.

Dan


>From hans not junk at nyphp.com  Fri Feb 20 16:38:40 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 2DF35A85EA
	for <talk at lists.nyphp.org>; Fri, 20 Feb 2004 16:38:40 -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] constants vs globals
Date: Fri, 20 Feb 2004 13:38:46 -0800
Message-ID: <41EE526EC2D3C74286415780D3BA9F87937C99 at ehost011-1.exch011.intermedia.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [nycphp-talk] constants vs globals
Thread-Index: AcP1ewG/DY7246w6SKqfG8UL6fnDywCfrRlA
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, 20 Feb 2004 21:38:40 -0000


> At the PHP conference in New York last spring I remember someone asked
> Rasmus a question: which is more expensive, accessing a=20
> global or defining
> a constant? He said without hesitation "defining a constant."=20
> There was
> silence for a couple beats, then on to the next question.

At that same conference I chatted with Zeev about this issue, too.  He
concured, and said that defining a constant is more expensive than
setting a variable.

However, somehow I knew he wasn't telling the whole story, so I asked
why... and why would anyone want a constant, aside from being static and
globally scoped.

He said that using constants, once defined, are less expensive than
variables.  So I said... "hah, thought you'd say something like that..."
:)

H