RE: [PHP] DB stuff

Hi Manual > >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. > > Does this work with all ODBC drivers? It should; it's part of the ODBC API, not something specific to our drivers. > > > The point is that Metabase is a framework that lets non-database expert > developers (99% of the Web developers) write applications that can work > with different database API and so they can switch database backend server > without having to rewrite his application or learn a new database API. This is a good thing, I agree. Also, I believe that there are only a handful of databases that have the characteristics of being a 'web' database. ODBC does abstract underlying functions in the majority of cases, leveling the playing field by enforcing additional functionality on the back end where necessary. ODBC used WITH Metabase to close that last gap is useful. > > Developers often don't have the knowlegde to determine which criteria is > important to make the the choice. A database API like Metabase takes from > the developer the burden of making the wrong choice because later they can > change without hassle. Yes, but doing the research of decision-support vs. transation optimized databases is part of design. Anyone who starts coding without evaluating the details of the approach, tools, etc is probably going to run into many problems in the long run, and I don't think any abstraction layer can alleviate that without defeating the usefulness of design freedom. > >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. > > Metabase does that since a long time before it was publically released. Metabase supports bound paramaters and cursors? Cool, I didn't know that. > > I don't see the point of making database abstraction API integral part of > PHP. When you want to add new drivers of fix the existing ones > you need to ask people to upgrade their PHP version which they often refuse to do even > if they can. Perhaps, but open-source without open-standards strikes me as problematic. Now if Metabase becomes a standard, and proves itself robust across all databases and for most development paradigms (and I'm not saying it isn't) then I think it's a valuable addition to PHP. > > >The perception that ODBC is an old or slow standard > exists because there are old and slow implementation of it. > > I am not talking about the drivers, but about the capabilities of > ODBC API. The API is not inherently slow, this is proven by the fact that we adhere to the ODBC API strictly and have exceptionally fast drivers. > > It's a different thing from what I am talking. AFAIK, cursors do > not avoid > database full scans on the server side which is a thing that brings down > many servers when applications are not ready for big audience. > > Metabase select row range limiting is specified before executing a query. > Cursors are used after the query is executed. The difference is that if > you can specify the range of selected rows that you want to retrieve > information, the server can act in a more optimized way and stop the query > search sooner. Actually, there are several models of cursors. Server side cursors should of course be used in this case; these include static, forward, keyset driven, and mixed. Keyset driven is the most 'intelligent'. One set of index records is pulled at a time, with the cursor sliding along that set, only querying the next set of records when the cursor reaches the end. Using this type of cursor, there is not a full scan - the most intensive query will be to get a set of index results to build the keyset (e.g. 100 records at a time.) This typically gives you a nice bi-directional walk of a record set, with increased performance in adjacent record sets, but doesn't require a full table query. > >> 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. Yes, ODBC does return <DB NULL> or <EMPTY STRING> in a result set; I agree that PHP should return this as well. Another thing is not being able to figure if the > >> underlying DBMS supports transactions. If a database doesn't support transactions, it shouldn't be used for any serious work. Any database worth it's salt supports a transaction model of some sort; even MySQL is implementing them. > > I plan to develop some database specific ODCB drivers for > Metabase, but I'm not sure when I will do it. So, I am always open to contributions. > According to this poll, 20% of Metabase users want to use the ODBC driver. > > http://www.egroups.com/surveys/metabase-dev?id=263873 > > If you or anybody else is interested to develop any driver subclasses for > Metabase ODBC driver, feel free to contact me and I will integrate your > work. > > If you are so commited to promote the use of ODBC among the PHP community, > I think this can be a great opportunity. To be honest it's beyond my current technical abilities, but I can certainly work to make ODBC use easier, document the process, identify problems and try to fix them. I hope this will benefit all the PHP community, Metabase users included :) I look forward to working with the PHP community on this in the future! Best regards, Andrew ---------------------------------------------------- Andrew Hill Director Technology Evangelism OpenLink Software http://www.openlinksw.com XML & E-Business Infrastructure Technology Provider