RE: [PHP] DB stuff

Hello Andrew, On 07-Nov-00 16:41:06, you wrote: >There are several different approaces to this, all have their relative >strengths and weaknesses: >1. ODBC - speed and functionality depends on the vendor, and you need to >obtain and install the drivers. You can get speed increases and additional >functionality enforced on back end databases if you select a good driver, >but they are usually not free and you are somewhat dependent on a commercial >company developing upgrades, fixes, etc. >2. unified ODBC functions - limited set of functions, no real ODBC layer >that abstracts or adds any value beyond simplified coding. Still dependent >on native layer, which may require licensing the native layer and dealing >with its speed and performance limitations. Dennis explictly asked for database abstraction packages that provide server independence. ODBC does not provide that because you often need to know how to handle with the underlying DBMS in your application to handle things that are specific. Think for instance about date fields. ODBC does not guarantee that selected date values will always be returned in the same date format. You have to sort that out in your application. >3. a DB abstraction class or layer such as Metabase, PEAR, etc/ - database >abstraction, and therefore easier database app building, but the paradigm is >to hide logic in functions. You aren't always sure what you are getting and >since it's not standards based you are limited to using it in individual >circumstances - and why not roll your own database classes if you are going >to do some real programming anyways? This is an heavily biased statement towards ODBC. We know your company sell ODBC drivers and it is expected that you would favour a ODBC solution. I can't speak for Pear, but if you look well over Metabase you can see that it comes with a driver compliance test script that is used to assure that its API works exactly the same regardless of the underlying DBMS you can work with. So, it's not true that you can't always be sure what you are getting from it as you claim. Actually that is my impression from ODBC since I developed the ODBC driver for Metabase. For instance, I can't tell whether the undlerlying database supports sequences. Another thing, although I can figure if the underlying DBMS supports auto-increment fields, I can't figure how to retrieve the last value that was inserted in auto-incremented column after I execute an INSERT statement. The ability to access to sequences or auto-incremented fields is vital for Web applications because they need to handle consistently concurrent accesses. It's funny that you mention users are limited to use Metabase/Pear in limited circumstances because they are not standards based. The truth is that ODBC got somehow stuck in the time before the Web became a viable platform for database applications. For instance, when you display query results in Web pages you may not be able to display the whole result set in a single page. What you usually do is to display a subset of the result rows in different pages. This is an every day need of Web database application developers. Since HTTP server access is stateless, you can't keep the same server connection between requests to serve pages to the same user. MySQL which is a modern database shaped to the Web database programming needs has the LIMIT keyword that is used to tell the server to only return a given range of rows. Other DBMS may have or not have the similar things. Metabase abstracted the selected row range access with a single call that has to be made before executing queries to tell which rows you want to display at a time. The good thing is that it works with all supported databases. ODBC has scroll cursors, but it doesn't seem to have an effecient way to the same as Metabase which is telling the server to only return the specified rows, even when the underlying database is MySQL or something else with similar selected row range specification capabilities. What good does it do to ODBC being based on a standard if this standard is not adapted to the needs of Web programming developers? Not much IMHO. While we are at it, if you are really concerned in making ODBC a better option for PHP programmers, you may work on it's API to let developers be able to figure if a given result value is NULL or not, because currently it is not possible to distinguish if a text result value is NULL or is just an empty string. Another thing is not being able to figure if the underlying DBMS supports transactions. These limitation are in PHP ODBC API, not in ODBC API itself. Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?user=mlemos@acm.org -- E-mail: mlemos@acm.org URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp --