[PHP-DEV] Database Abstraction

2003-02-05 Thread Kasper Skårhøj
Hi folks.

I have a question about database abstraction. If this is not the place to ask, please 
redirect me.

There are millions of PHP-scripts using MySQL. Most of them probably doesn't use an 
Database Abstraction Layer (DBAL) in order to support other databases. When the 
requirement is made some day that a script should support another DB than MySQL 
programmers are facing the challenge of literally rewrite most of their code to fit 
some DBAL, like ADOdb or whatever.

So my idea was to make a DBAL which basically offers a parallel set of functions to 
the current MySQL-functions (search/replace) but internally parses the queries and 
re-makes the query into something Oracle or MSSql or some third DB would understand. 
This would be totally transparent and give instant DBA to millions of PHP-scripts. A 
MySQL emulator. For MySQL it wouldn't affect performance. For other DBs I would 
require a little parsing time of the query.

I know this is not as simple as it sounds, but is it *totally impossible* since noone 
made it yet and if some of you think it is, please let me know why. I think the idea 
is obvious.


- kasper

-
Q: So who is going to drive TYPO3 ahead?
A: The man in the mirror!



--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Database Abstraction

2003-02-05 Thread Derick Rethans
On Wed, 5 Feb 2003, [ISO-8859-1] Kasper Skårhøj wrote:

 Hi folks.
 
 I have a question about database abstraction. If this is not the place
 to ask, please redirect me.

wrong list :) - [EMAIL PROTECTED]

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Database Abstraction

2003-02-05 Thread Daniel Lorch
hi,

 There are millions of PHP-scripts using MySQL. Most of them probably doesn't
 use an Database Abstraction Layer (DBAL) in order to support other databases.
 [..]

There are (too) many parallel efforts trying to create yet another database
abstraction layer. We all know it's necessary, but we also know that by ab-
stracting you have to either reduce the available features to the least
common denominator (not so good), or emulate stuff within the abstration
layer. 

Check out the existing ones, first:

  http://pear.php.net/packages.php?catpid=7catname=Database
  http://phplib.sf.net/
  http://freshmeat.net/projects/metabase/

-daniel

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Database Abstraction

2003-02-05 Thread Hartmut Holzgraefe
Kasper Skårhøj wrote:

but internally parses the queries and re-makes the query into something 
 Oracle or MSSql or some third DB would understand. This would be totally
 transparent and give instant DBA to millions of PHP-scripts. A MySQL emulator.

ODBC does something similar AFAIK, just with ANSI SQL as standard dialect
instead of MySQL ...

but still i'd like to see how you are going to get features like
auto-increment or fulltext search 're-made' ;)



--
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED]   Tel.: +49-711-99091-77

Sie finden uns auf der CeBIT in Halle 6/H44   http://www.six.de/cebit2003/


--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] database abstraction layers [from: MySQLfeature/bug]

2001-02-04 Thread Manuel Lemos

Hello Mark,

On 31-Jan-01 16:33:56, you wrote:

 I have been crafting my own database abstraction layer, and in doing so
 create an array of the results of a query.
 
 Is this an db abstraction layer written in php (script), or written as a
 module for php (C)?
 
 I was thinking of writing an (open source) db-abstraction module (that uses
 existing db-modules, of course), which could then be used from php-script
 as well as from other modules that need db-functionality without committing
 to a specific database.
 
 Or, does such a module exist already and should I concentrate on using
 and/or co-developing that one?

I'd be open to turning it into C, as all my layer is really doing at its
core is to do every single bit of error checking and API utilization for all
the different DB drivers present on the system.

Before trying to re-invent the wheel, maybe you would like to take a look
at Metabase.  It is not yet written in C, but nothing stops it from being
converted. Unlike others it assures inter-database application portability.


What I've seen of PHPLIB and PEAR's DB function don't interest me. I hardly
see the point of using objects to do the work that a general function would
do just as well and without any need to instantiate it.

Objects are important to interface with different database drivers using
the same API, but yes for the public API objects are not needed, they are
really confusing for less experienced programmers and they are also a
problem for PHP3 users (yes, a lot of PHP developer can't or don't want to
move to PHP 4).


I need to spend some time with the Zend API to see if it's really worth it
for my time to go about doing it, but yes, I am very much considering
turning it into C.

I doubt that it is worthy, not just because of the conversion risks but also
the maintenance costs.

Instead, if you would like to join and contribute of Metabase, look here
for this poll and tell how would you like to participate.

http://www.egroups.co.uk/surveys/metabase-dev?id=392814

Metabase is available for free and over 4.000 unique PHP users downloaded
it from here:

http://phpclasses.UpperDesign.com/browse.html/package/20


There are several ready to use components based on Metabase like this for
browsing query results:

http://phpclasses.UpperDesign.com/browse.html/package/130

or even full application frameworks like Binary Cloud:

http://www.binarycloud.com/


Regards,
Manuel Lemos

Web Programming Components using PHP Classes.
Look at: http://phpclasses.UpperDesign.com/?[EMAIL PROTECTED]
--
E-mail: [EMAIL PROTECTED]
URL: http://www.mlemos.e-na.net/
PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp
--


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




RE: [PHP-DEV] database abstraction layers [from: MySQLfeature/bug]

2001-02-04 Thread Sean R. Bright


This is something that PHP has always lacked.  Its also something that I
have always found to be the most attractive about application servers like
Allaire's Cold Fusion (http://www.allaire.com/).  The ability to totally
abstract database access makes it much easier on the developer and
transparent to the end-user.

While I agree that there are high maintenance costs, I still believe that
its worth it in this case.  For an initial offering, a subset of DB
functionailty would be needed, something that all of the databases offer,
for example:

1) $connection_id = db_connect( $host_string );
2) $query_result  = db_query( $query );
3) $query_row = db_fetch_row( $query_result );
4) void db_close( $connection_id );

(Perhaps $host_string is the identifier for some defined datasource in the
php.ini or .htaccess files)

This abstraction (any abstraction for that matter) would open up the doors
for quite a number of interesting capabailities.  For example, a flatfile
"driver" that would be queried, or a google "driver."

PEAR is fine for most people (myself included) but from an efficiency
standpoint, this would be much better handled from the PHP API level, and
not from the PHP language level.

In any case, I am more than willing to help out in any way that I can.

Regards,
===
Sean Bright
[EMAIL PROTECTED] / [EMAIL PROTECTED] / http://www.seanbright.com/
===

 -Original Message-
 From: Manuel Lemos [mailto:[EMAIL PROTECTED]]
 Sent: Sunday, February 04, 2001 2:12 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [PHP-DEV] database abstraction layers [from:
 MySQLfeature/bug]


 Hello Mark,

 On 31-Jan-01 16:33:56, you wrote:

  I have been crafting my own database abstraction layer,
 and in doing so
  create an array of the results of a query.
 
  Is this an db abstraction layer written in php (script),
 or written as a
  module for php (C)?
 
  I was thinking of writing an (open source) db-abstraction
 module (that uses
  existing db-modules, of course), which could then be used
 from php-script
  as well as from other modules that need db-functionality
 without committing
  to a specific database.
 
  Or, does such a module exist already and should I
 concentrate on using
  and/or co-developing that one?

 I'd be open to turning it into C, as all my layer is really
 doing at its
 core is to do every single bit of error checking and API
 utilization for all
 the different DB drivers present on the system.

 Before trying to re-invent the wheel, maybe you would like to
 take a look
 at Metabase.  It is not yet written in C, but nothing stops
 it from being
 converted. Unlike others it assures inter-database
 application portability.


 What I've seen of PHPLIB and PEAR's DB function don't
 interest me. I hardly
 see the point of using objects to do the work that a general
 function would
 do just as well and without any need to instantiate it.

 Objects are important to interface with different database
 drivers using
 the same API, but yes for the public API objects are not
 needed, they are
 really confusing for less experienced programmers and they are also a
 problem for PHP3 users (yes, a lot of PHP developer can't or
 don't want to
 move to PHP 4).


 I need to spend some time with the Zend API to see if it's
 really worth it
 for my time to go about doing it, but yes, I am very much considering
 turning it into C.

 I doubt that it is worthy, not just because of the conversion
 risks but also
 the maintenance costs.

 Instead, if you would like to join and contribute of
 Metabase, look here
 for this poll and tell how would you like to participate.

 http://www.egroups.co.uk/surveys/metabase-dev?id=392814

 Metabase is available for free and over 4.000 unique PHP
 users downloaded
 it from here:

 http://phpclasses.UpperDesign.com/browse.html/package/20


 There are several ready to use components based on Metabase
 like this for
 browsing query results:

 http://phpclasses.UpperDesign.com/browse.html/package/130

 or even full application frameworks like Binary Cloud:

 http://www.binarycloud.com/


 Regards,
 Manuel Lemos

 Web Programming Components using PHP Classes.
 Look at: http://phpclasses.UpperDesign.com/?[EMAIL PROTECTED]
 --
 E-mail: [EMAIL PROTECTED]
 URL: http://www.mlemos.e-na.net/
 PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp
 --


 --
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail:
 [EMAIL PROTECTED]



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




RE: [PHP-DEV] database abstraction layers [from: MySQLfeature/bug]

2001-02-04 Thread Manuel Lemos

Hello Sean,

On 04-Feb-01 16:09:21, you wrote:

This is something that PHP has always lacked.  Its also something that I
have always found to be the most attractive about application servers like
Allaire's Cold Fusion (http://www.allaire.com/).  The ability to totally
abstract database access makes it much easier on the developer and
transparent to the end-user.

Metabase assures this for you.  Metabase goes further, not only it assures
portability of the application acceses to the databases, but is also to
install database schema from a database independent schema definition
format base in XML.

This means that only need to tell which tables, fields, indexes and
sequences in a simple XML file and Metabase manager installs it for
you in any of the supported databases seeminglessly.

The cool part is that if you want to change your database schema (and often
you do), you just need to change the schema definition file and Metabase
manager will update your schema without disturbing any data added to the
database since the database was first installed or was updated for the last
time.


PEAR is fine for most people (myself included) but from an efficiency
standpoint, this would be much better handled from the PHP API level, and
not from the PHP language level.

Metabase API is made of simple functions (not objects that you have to
create).  Doing what Metabase already does with built-in functions would
not buy you much that would be worthy.

Manuel Lemos


 Hello Mark,

 On 31-Jan-01 16:33:56, you wrote:

  I have been crafting my own database abstraction layer,
 and in doing so
  create an array of the results of a query.
 
  Is this an db abstraction layer written in php (script),
 or written as a
  module for php (C)?
 
  I was thinking of writing an (open source) db-abstraction
 module (that uses
  existing db-modules, of course), which could then be used
 from php-script
  as well as from other modules that need db-functionality
 without committing
  to a specific database.
 
  Or, does such a module exist already and should I
 concentrate on using
  and/or co-developing that one?

 I'd be open to turning it into C, as all my layer is really
 doing at its
 core is to do every single bit of error checking and API
 utilization for all
 the different DB drivers present on the system.

 Before trying to re-invent the wheel, maybe you would like to
 take a look
 at Metabase.  It is not yet written in C, but nothing stops
 it from being
 converted. Unlike others it assures inter-database
 application portability.


 What I've seen of PHPLIB and PEAR's DB function don't
 interest me. I hardly
 see the point of using objects to do the work that a general
 function would
 do just as well and without any need to instantiate it.

 Objects are important to interface with different database
 drivers using
 the same API, but yes for the public API objects are not
 needed, they are
 really confusing for less experienced programmers and they are also a
 problem for PHP3 users (yes, a lot of PHP developer can't or
 don't want to
 move to PHP 4).


 I need to spend some time with the Zend API to see if it's
 really worth it
 for my time to go about doing it, but yes, I am very much considering
 turning it into C.

 I doubt that it is worthy, not just because of the conversion
 risks but also
 the maintenance costs.

 Instead, if you would like to join and contribute of
 Metabase, look here
 for this poll and tell how would you like to participate.

 http://www.egroups.co.uk/surveys/metabase-dev?id=392814

 Metabase is available for free and over 4.000 unique PHP
 users downloaded
 it from here:

 http://phpclasses.UpperDesign.com/browse.html/package/20


 There are several ready to use components based on Metabase
 like this for
 browsing query results:

 http://phpclasses.UpperDesign.com/browse.html/package/130

 or even full application frameworks like Binary Cloud:

 http://www.binarycloud.com/


 Regards,
 Manuel Lemos

 Web Programming Components using PHP Classes.
 Look at: http://phpclasses.UpperDesign.com/?[EMAIL PROTECTED]
 --
 E-mail: [EMAIL PROTECTED]
 URL: http://www.mlemos.e-na.net/
 PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp
 --


 --
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail:
 [EMAIL PROTECTED]



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]



Regards,
Manuel Lemos

Web Programming Components using PHP Classes.
Look at: http://phpclasses.UpperDesign.com/?[EMAIL PROTECTED]
--
E-mail: [EMAIL PROTECTED]
URL: http://www.mlemos.e-na.net/
PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp
--


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For 

RE: [PHP-DEV] database abstraction layers [from: MySQL feature/bug]

2001-02-01 Thread Marc Boeren


Hi,

I need to spend some time with the Zend API to see if it's really worth it
for my time to go about doing it, but yes, I am very much considering
turning it into C.

I've really been hoping that someone was going to take an intermediately
complex Zend extension and put together a how-to that would help beginners
and advanced programmers alike.

I've managed to create a working module using the 'web application
development with php 4.0' book, lurking on this list, searching on the net
and nosing through the code. The module is able to use functions from the
compiled-in mysql-module and all seems ok, so I think the basic ingredients
to build a db-abstraction module are available...

I think there is a real need for someone or a group of programmers to get
together and write a step-by-step theory/implementation "cookbook" for the
sake of the community. Should I reach that point, I'd be happy to do it,
but
I tend to believe that the community could do it faster and better than I
could right now, and that if if such a document were made publicly
available, the community could build more and better core tools faster.

You could try www.zend.com/apidoc, which contains a part of the book I
mentioned and gives a nice intro/howto to developing php-extensions. It's
helped me, I know :-)

Cheerio, Marc.



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




AW: [PHP-DEV] database abstraction layers [from: MySQL feature/bug]

2001-01-31 Thread Harald Radi

there exists a db abstraction layer in the PEAR (pear.php.net)

harald.

 -Ursprngliche Nachricht-
 Von: Marc Boeren [mailto:[EMAIL PROTECTED]]
 Gesendet: Mittwoch, 31. Jnner 2001 16:57
 An: '[EMAIL PROTECTED]'
 Cc: 'Mark J. Hershenson'
 Betreff: [PHP-DEV] database abstraction layers [from: MySQL feature/bug]



 I have been crafting my own database abstraction layer, and in doing so
 create an array of the results of a query.

 Is this an db abstraction layer written in php (script), or written as a
 module for php (C)?

 I was thinking of writing an (open source) db-abstraction module
 (that uses
 existing db-modules, of course), which could then be used from
 php-script as
 well as from other modules that need db-functionality without
 committing to
 a specific database.

 Or, does such a module exist already and should I concentrate on using
 and/or co-developing that one?

 Thanks, Marc.

 --
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: [EMAIL PROTECTED]




-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




RE: [PHP-DEV] database abstraction layers [from: MySQL feature/bug]

2001-01-31 Thread Marc Boeren


there exists a db abstraction layer in the PEAR (pear.php.net)

I know, but this is done in php-script, not as a php-module... wouldn't a
php-module be more efficient (faster?) and less hassle to use for people
(php compiled with dbal-module and eg mysql-module, users just type
$handle=dbal_connect("MySQL", "dbname", "username", "pasword"); or something
and don't have to include the php-scripts on their own pages) ?

Cheerio, Marc.

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] database abstraction layers [from: MySQLfeature/bug]

2001-01-31 Thread Mark J. Hershenson

 
 I have been crafting my own database abstraction layer, and in doing so
 create an array of the results of a query.
 
 Is this an db abstraction layer written in php (script), or written as a
 module for php (C)?
 
 I was thinking of writing an (open source) db-abstraction module (that uses
 existing db-modules, of course), which could then be used from php-script as
 well as from other modules that need db-functionality without committing to
 a specific database.
 
 Or, does such a module exist already and should I concentrate on using
 and/or co-developing that one?
 
 Thanks, Marc.

I'd be open to turning it into C, as all my layer is really doing at its
core is to do every single bit of error checking and API utilization for all
the different DB drivers present on the system.

What I've seen of PHPLIB and PEAR's DB function don't interest me. I hardly
see the point of using objects to do the work that a general function would
do just as well and without any need to instantiate it.

I need to spend some time with the Zend API to see if it's really worth it
for my time to go about doing it, but yes, I am very much considering
turning it into C.

I've really been hoping that someone was going to take an intermediately
complex Zend extension and put together a how-to that would help beginners
and advanced programmers alike.

I think there is a real need for someone or a group of programmers to get
together and write a step-by-step theory/implementation "cookbook" for the
sake of the community. Should I reach that point, I'd be happy to do it, but
I tend to believe that the community could do it faster and better than I
could right now, and that if if such a document were made publicly
available, the community could build more and better core tools faster.

My 2 cents...:)

--

Per the initial question I posted, can there at least by made available a
newer option for mysql_fetch_array() such as MYSQL_ALL, which would then
give you null and non-null associative names?

  Mark J. Hershenson
  [EMAIL PROTECTED]
  http://www.green-ant.com/


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]