Jag arbetade ganska mycket med Zend_Db bibliotek, som inkluderar en PHP klass för att konstruera SQL-frågor
. Jag bestämde mig för att försöka hantera alla tänkbara SQL-syntaxer i WHERE och HAVING klausuler av flera skäl:
-
PHP är ett skriptspråk som analyserar och kompilerar kod på varje begäran (såvida du inte använder en bytecode-cache). Så PHP-miljön är känslig för skrymmande kodbibliotek - mer än Java eller C# eller Python eller vad har du. Det är därför en hög prioritet att hålla biblioteken så smala som vi kan.
Alla
Zend_Dbbiblioteket jag arbetade på var cirka 2 000 rader PHP-kod. Däremot är Java Hibernate i storleksordningen 118K kodrader. Men det är inte så mycket problem eftersom ett Java-bibliotek är förkompilerat och inte behöver laddas vid varje begäran. -
SQL-uttryck följer en generativ grammatik som är mer kompakt och lättare att läsa och underhålla än någon av de PHP-baserade konstruktionerna du visade. Att lära sig SQL-uttryckets grammatik är mycket lättare än att lära sig ett API som kan simulera det. Det slutar med att du stöder en "förenklad grammatik". Eller så börjar du på det sättet och finner dig själv tvingad av din användargemenskap till Funktionskrypning tills ditt API är oanvändbart komplext.
-
För att felsöka en applikation som använde ett sådant API, skulle du oundvikligen behöva tillgång till det slutliga SQL-uttrycket, så det handlar om läckaste abstraktionen du kan ha.
-
Den enda fördelen med att använda ett PHP-baserat gränssnitt för SQL-uttryck skulle vara att det underlättar kodkomplettering i smarta redigerare och IDE. Men när så många av operatorerna och operanderna använder strängkonstanter som
'>=', förstör du all kodkompletterande intelligens.
uppdatering: Jag har precis läst en bra bloggartikel "A Farewell to ORMs ." Författaren, Aldo Cortesi, föreslår att du använder SQL Expression Language i Pythons SQLAlchemy. Syntaktisk socker och operatörsöverbelastning som är standard i Python (men stöds inte i PHP) gör detta till en mycket effektiv frågegenererande lösning.
Du kanske också tittar på Perls DBIx::Class, men det slutar med att den blir ganska ful.