RE: [PHP] DB stuff

Manuel, Not to beat a dead horse, but let me address some of these differences of opinion... > Dennis explicitly 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. ODBC actually does guarantee that date values will be returned in the same format. As long as you use proper escape syntax, ODBC will take that and translate any needed changes against the back end. e.g. Select * from Table where Date = {d '2000-11-17'} will determine what order. Also, specific database settings can be passed on server setup; a programmer can certainly tweak an environment variable from dd-mm-yy to yy-mm-dd if it is essential, without changing the app at all. > > >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. Absolutely, I am quite heavily biased towards ODBC - to the idea of ODBC though, not just my company's implementation of it. PHP is a language that exceptionally facilitates dynamic webpages creation, yet still allows granular control over the content of those pages. I don't think that Metabase and ODBC necessarily conflict either, in fact I think that ODBC is a great complementary piece here - the issue I have is that Metabase, or any application framework, can eliminate the need for a PHP developer to learn to handle much of the structuring of dynamic websites, and replace it with a need for the programmer to learn a specific framework. I have nothing but respect for your skills and accomplishments Manual, and I think you perform great services to the web development community, but if everyone using PHP adopted Metabase and things like it, then wouldn't something be lost? Isn't this how bloat creeps into software languages? I don't want PHP to turn into something like Java or even Powerbuilder, where there is a widget for everything, whose code does 3 things you want it to and 27 things you may not use, and the best people using it are the one's whose personal viewpoints mesh best with the idiosyncrasies of the tools. I am looking quite forward to PEAR, as well, but I hope it becomes something like DBD:DBI, though not a framework on top of PHP that hides granular control. I believe that abstraction layers need to address impedance mismatch, and go no further, to allow complete abstraction from the back end, without restricting the options of developers. To this end work still needs to be done on things like cursor handling, statement preparation with bound parameters, etc. > 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. Isn't this what ODBC does?? The API, if followed, provides this assurance. PHP has much of this implemented already. > 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. Yes, agreed, ODBC compliance is kind of like SQL compliance - two standards that were touted well before standards became so tightly adopted. If a WYSIWYG vendor claimed XHTML compliance today, and only implemented 80%, they would (financially) be shot. This doesn't mean that open standards specifications aren't valid and powerful, however. I urge people to no more blindly accept an ODBC driver than they do a database - you will find many differences above and beyond simple performance. > > For instance, I can't tell whether the underlying 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. Absolutely, but I would argue these things should be integral to a web-optimized language (via PEAR, perhaps?) and not something that should sit in any way 'above' the language. It's certainly a level above ODBC. > > 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. Untrue. The perception that ODBC is an old or slow standard exists because there are old and slow implementation of it. > > 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. Yes, it's called cursors. PHP's limited cursor support is not a failing of ODBC, but a limit of the language. I would love to see it addressed as much as you, but I differ in at what level it should be implemented. > 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. Limit is a bit of a workaround though - again, databases should support robust cursor models. > > ODBC has scroll cursors, but it doesn't seem to have an efficient 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. Agreed, but again an issue with the cursor model of the PHP - you have 'fixed' it with workarounds, but the need for better data handling still remains in PHP. > > 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. ah, as I reach the end it seems we are in many ways on the same page here - but please don't slam ODBC in favor of workarounds, just because you have built them. I agree that workarounds are necessary, considering the state of some of these things (null fields, sequences, cursors) but standards do exist that can be implemented to close the last gaps. Respectfully, Andrew ---------------------------------------------------- Andrew Hill Director Technology Evangelism OpenLink Software http://www.openlinksw.com XML & E-Business Infrastructure Technology Provider