DB-Zugriff via Framework

Ein Problem bekomme ich jedoch oft mit der Flexibilität, wenn man z.B. eine sehr Umfangreiche Tabelle mit 50 Spalten hat... (ja ich weiß dass man sowas nicht tun soll, aber das kommt nunmal vor, man muss es ja nicht selbst verschuldet haben) Nun möchte man je nach Abfrage mal die komplette Tabelle für 10 Einträge oder doch nur ID und Name über die ersten 3k Zeilen erhalten, die wenigsten DB-APIs sind auf einen derartigen Fall jedoch eingestellt.
Besonders toll war dieser Fall mit .Net, dort mussten wir bei unserem letzten Versuch für jede andere Spaltenauswahl eine neue Funktion in diesem Datenbankobjekt schreiben. Es war nicht möglich die alten einfach anzupassen.
Ich habe mir das Ganze etwa 1-2x angetan, dann bin ich wieder zu reinem SQL gewechselt und habe die Datenbank von Hand aufgerufen. Wir hatten am Ende also zwei komplett unterschiedliche Arten auf die Datenbank zuzugreifen im Projekt, eine schlechter als die andere implementiert. (Das betroffene Projekt war eh nicht gerade das tollste.)
Bei Propel/Symfony bin ich gestern wieder mit einem derartigen System kolidiert, auch wenn dort die Probleme bei weitem nicht so schlimm waren, war ich doch gezwungen meine Eigenen Funktionen zu realisieren.
Symfony generiert anhand einer Datenbankbeschreibung schlicht die Zugriffsfunktionen für so ziemlich jede mögliche Datenbankabfrage. Man kann ein Auswahlkriterium für die WHERE-Klausel als Objekt zusammenstellen und übergibt dieses Objekt dann einer Funktion alá Tabelle::doSelect(Criteria).
Probleme treten auf, wenn man versucht mit Joins zu arbeiten. Symfony stellt direkt Funktionen für alle angegebenen Möglichkeiten die Tabelle mit einer anderen zu joinen bereit (Tabelle::doSelectJoin...), auch stehen Funktionen bereit um Alle möglichen Joins bereit zu stellen (doSelectJoinAll). Was jedoch nicht zur Verfügung steht sind Funktionen mit denen man von z.B. 10 Möglichen Joins auf diese Tabelle nur 2 oder 3 bestimmte ausführt (9 geht wieder: doSelectJoinAllExcept).
Symfony hat jedoch im Gegensatz zu anderen Systemen an dieser Stelle den Vorteil dass es sich relativ schnell dazu bewegen lässt soetwas doch zu tun.
Man leitet einfach in der Klasse für diese Tabelle eine neue Funktion ab. (Die Klassen sind extra dafür in 3 Dateien unterteilt, um die Datenbankstruktur auch bei selbsterstellten Funktionalitäten noch automatisiert aktuell halten zu können.)
Das Ganze macht sich in wenigen Minuten wenn man einmal verstanden hat wie es funktioniert und ist dann auch ziemlich flexibel. Einzig die Dokumentation zu dieser Möglichkeit fehlt nahezu komplett aber da in einem Unterverzeichnis der komplette generierte Code liegt (der übrigens grauenvoll aussieht), kann man ja schnell mal nachsehen was man tun müsste.
Propel ist also definitiv einen Schritt weiter als die damals von mir getestete Version von .Net. Beide Systeme haben jedoch noch grobe Designfehler, die sie bei komplexeren Anforderungen etwas behäbig machen. Propel gleicht das, etwas umständlich zwar aber doch recht leicht zu verwenden, wieder aus.
.Net jedoch schien diese Fehler einfach als unumgänglich hinzunehmen. Wahrscheinlich hatte man sich dort auch vom reinen Design etwas verrannt.
Wahrscheinlich müssen wir auf das ultimative Abfragesystem noch eine Weile warten.
(Oder habt ihr es bereits gefunden? Dann bitte eine Anmerkung in den Kommentaren hinterlassen!)