RE: [PHP-DB] Re: [PHP] Re: Cross DB application

Can someone with database expertise who has used metabase and adodb cut through this rhetoric and give an objective view of these two packages. From what I got from this convo is that metabase is slower but more portable but adodb is faster but not as portable. -----Original Message----- From: Manuel Lemos [mailto:mlemos@acm.org] Sent: April 17, 2002 6:54 AM To: php-general@lists.php.net; php-db@lists.php.net Subject: [PHP-DB] Re: [PHP] Re: Cross DB application Hello John "Microsoft marketeer" Lim: :-) John Lim wrote: > > Manuel, > > > Prepared queries in practice are the same as what John Lim calls in this > > document http://php.weblogs.com/portable_sql as > > "binding", except that > > he doesn't seem to be aware that it is the same thing, so he says that > > only some database can use it! :-) Metabase handles prepared queries > > with ALL supported databases. > > > Some databases such as MS Access/MySQL do not support binding. So > even if you support MySQL, you only get emulated binding in MySQL, and > not the performance increase you might have expected. I hope that is > clearer. You are missing the point. I wrote Metabase so I would not have to change one line of my applications when I switched databases. That is the intention of this thread original poster. Of course low end databases do not support prepared queries/binding, but if you use Metabase prepared queries support you can benefit from eventual extra speed with databases that support placeholders for pre-compiled queries and at the same time the Metabase application will still work seeminglessly with databases that do not support real prepared queries. Most of the popular database abstraction packages support prepared queries, except for your PHP ADODb. So, think about this before you keep throwing sand to the eyes of the users that do not know better, may be you understand the point of catching up on what everybody else is doing for a long time. > > Last but not least, PHP ADODB is an attempt of John Lim to develop > > something of his own copying ideas and names from everywhere and cash on > > it by selling PHPLens. He copied Microsoft ADODB to appeal better to > > Windows users. But since ADODB was not meant specifically for portable > > Web development, he still needed to copy features of Metabase like > > auto-incremented integer sequence values and limiting the range of rows > > returned in select queries result sets. Some of these things that were > > copied had their names changes to not look so obvious but they are still > > copies of Metabase features because only Metabase provided them before. > > > > Manuel, you have a habit of saying nasty things, and you set a bad example > by > doing so, because you are a good programmer who should be a leader in the > community. John, I am sorry but for you I no longer have nice words or else I would be an hypocrit. The reason for this is that you had the dumb idea to spam all the lists you could remember with the forged claim that ADODB was faster than every other database abstraction because your convinient benchmarks showed that. Since your database abstraction could not beat others on real abstraction features you used that to drag users to your package to push them the commercial tool that you sell and requires ADODB to run. That was the lowest Microsoft-like marketing trick - trap them into your Windows clone database abstraction "OS" to sell them your tool for which you have no competitor because nobody else is doing anything like that for your own abstraction later. Of course you may claim ADODB is faster than any other abstraction package, but that's because it does not abstract data type conversion to make user applications portable. It is the same as stating that driving a motocycle naked and without helmet you will drive faster than clothed with the helmet on. It is not the same thing, but unfortunately for the victim users that have fallen for your argument they did not notice that your abstraction can only be faster by doing less, meaning providing less portability support. Since the way you do your abstraction application developers still have to resort to database specific programming to make their applications run in multiple databases, when it comes to real portability ADO DB is absolutely useless. Unforntunately for ADO DB users, they will only notice that when they really try to migrate their applications to other databases than what they use today. By then, it will be too late for them. They may even complain for having been mislead by your hype, but the harm will be already done. > I have no problems saying that I developed ADOdb because I needed a database > class library to implement phpLens. The reason is simple, there is no other > database > class library for php that had sufficient functionality to meet the > sophisticated data > requirements that I had. Frankly I would have used Metabase or PEAR DB or > something > similar if it was mature enough. As to the deficiencies of Metabase and PEAR > DB, i don't > think a mud-slinging match is appropriate, but I believe in my work, and > think it stands > very well compared to other libraries. Sure, keep throwing sand to the users eyes. The only deficiency here seems to be your lack of capability to understand why Metabase was planned the way it became to understand why so many people really value its superiority in providing true portability to database applications. Unfortunately many users do not have enough knowledge enough to understand the arguments that you use to mislead them always have fine print that you of course will not explain them because you want them to fall the trap of be stuck with ADODB to then buy your commercial tool. John, as a marketeer you still have a lot to learn before you realize that you can't fool everybody! Next you will release ADODB XP the one that makes hidden connections to your site to track what the users are doing! hehehe :-) Don't worry, nobody will sue you for the abusing the monopoly of applications for your PHP ADO DB! :-) Manuel Lemos -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php