Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!fu-berlin.de!uni-berlin.de!not-for-mail From: "M. Strobel" Newsgroups: comp.lang.php Subject: Re: transfering all MySQL rows to an array Date: Sun, 08 Jan 2012 19:56:39 +0100 Lines: 39 Message-ID: <9mu778FolU1@mid.uni-berlin.de> References: <9mtls9Fhk7U1@mid.uni-berlin.de> <9mu3ncF3n3U1@mid.uni-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 7duJ5IAjDQ537XgElPFJEAdbGyBRBmIyljmhtmpsiR9o/60mc= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Lightning/1.0b2 Thunderbird/3.1.16 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.php:4309 Am 08.01.2012 19:28, schrieb Gregor Kofler: >> >> PDO is an abstraction layer, but only at the call level. This is >> better than none. > > >> I think people only talking about mysql are thinking small. You >> should not give away flexibility when it comes at small cost. > > I know what PDO does. And does not. Flexibility is quite limited. Take a > query with a LIMIT clause and try to execute it on a MSSQL server. Or > dealing with date data. IOW: Unless you stick to (really) simple CRUD > queries, the additional abstraction layer of PDO won't add an awful lot > of flexibility. Agreed, the interface won't change when switching databases. > >> Small cost: the alleged performance of PDO is rather my >> experience. Additionally the web search turned up in the first hits: >> http://www.el-bato.de/it/php-mysql-vs-mysqli-vs-pdo-performance >> (sorry, in german) > > I doubt that with your average web application the execution time of db > calls will be a problem at all. Proper db design, indexing and effort > put into optimizing the queries themselves will yield much more > performance gain. (The above benchmarks show that the impact of PDO is > little with basic queries. How about memory consumption, will the > benchmarks hold with all data types, etc?) > >> Before we start discussing benchmarks I would like to know: what >> especially do you not like about it? > > You stating "the overhead is minimal due to the fact it is a compiled > extension". Just being a compiled extension doesn't say anything about > performance penalties (or lack thereof). > > Gregor compiled extension in C vs. extension in PHP. /Str.