kelatebaru

Queries are gaining more and more complexity, data is getting bigger and bigger. Most optimizations in database technology are done in the database server. This is an approach to optimize queries on the client side. With this ORM, queries ... don't select more data than needed contain less joins when data is expected to be consistent can be written manually in pure SQL are not written in a new query language We need a good API, so ... it should be easy to learn method names must be short and intuitive the goal is to map datasets and relations to objects the API should offer method chaining special features like auto-increments should be included the code should be small, no getters and setters the database schema is created before writing PHP code relationships should be defined in the database, not in the code we get low latencies combined with low memory usage To make things easier, we make some restrictions: only UTF-8 only MySQL/MariaDB (mysqli) only PHP 5.4.0+ only buffer...

ircmaxell: Framework Fixation - An Anti Pattern , short summary: delegation of architecture decisions to frameworks may not be optimal or even wrong only use frameworks when doing prototypes or projects you don't need to maintain frameworks don't save time/money in the long term frameworks don't make it easier to hire good programmers using a framework prevents developers from understanding backgrounds not all framework developers are super heroes (look at the bug trackers ...) favor libraries over frameworks Quotes: Most of the monolithic frameworks are red herrings...solving problems of yesterday The typical mantra of "just let a framework do it for you" helps nothing except creating brainless code monkeys. ( source ) My opinion: frameworks are not so bad, but you need to evaluate them very carefully before using evaluation means checking code quality, features AND performance matching the specific problems of your business choosing the wrong framework throws...

"We Are Borg PHP. We Will Assimilate You. Resistance Is Futile!" Just got to something described as: This extension embeds the V8 Javascript Engine into PHP. It is called v8js and the documentation is already available on php.net , examples and the sources are here . V8 is known to work well in browsers and webservers like node.js, but does it work inside PHP? YES! Here is the installation on Ubuntu 12.04: sudo apt-get install php5-dev php-pear libv8-dev build-essential sudo pecl install v8js sudo echo extension=v8js.so >>/etc/php5/cli/php.ini sudo echo extension=v8js.so >>/etc/php5/apache2/php.ini php -m | grep v8 Let's run a small test script: <?php $start = microtime(true); $array = array(); for ($i=0; $i<50000; $i++) $array[] = $i*2; $array2 = array(); for ($i=20000; $i<21000; $i++) $array2[] = $i*2; foreach ($array as $val) { foreach ($array2 as $val2) if ($val == $val2) {} } echo (microtime(true)-$start)."\n"; // 8.60s $star...

To handle a lot of traffic, we need a fast controller with very little memory overhead. First, we implement a dynamic controller . The design is based on the micro frameworks Slim and Silex . The first example maps the URL "http://server/index.php/blog/2012/03/02" to a function with the parameters $year, $month and $day: // index.php, handle /blog/2012/03/02 $app = new App(); $app->get('/blog/:year/:month/:day', function($year, $month, $day) { printf('%d-%02d-%02d', $year, $month, $day); }); Our controller is a class named App and uses the get() function to map a GET request. Parameters mapped to the function are marked with a colon. Optional parameters are written inside brackets. Here is an example: // handle /blog, /blog/2012, /blog/2012/03 and /blog/2012/03/02 $app = new App(); $app->get('/blog(/:year(/:month(/:day)))', function($year=2012, $month=1, $day=1) { printf('%d-%02d-%02d', $year, $month, $day); }); Instead of ...

ORM has attracted a lot of attention in the last years. So let's get a bit deeper into it. The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically queries can't be optimized queries select more data than needed, things get slower, more latency (some ORMs fetch all datasets of all relations of an object even though only 1 attribute is read) compiling queries from ORM code is slow (ORM compiler written in PHP) SQL is more powerful than ORM query languages database abstraction forbids vendor specific optimizations Other problems coming up with ORM compiling ORM logic from phpDoc instructions or XML files is slow, but can be cached ORM validates relations and field names outside the database, but can't keep relations consistent ORM libraries are often used in projects without making a benchmark before ORM libraries are often used because the documentation of the library says it is very fast ORM libraries are often used by default with...