DB Interface

[emergence]

hab mich heute etwas mit dem umbau der phplib bzw den kompletten austausch beschäftigt, und da hab ich mir einiges durch den kopf gehen lassen...

die phplib als solche wird ja nicht mehr weiter entwickelt bzw. ist komplett nach pear verlagert worden, somit hab ich mir mal die ADODB angesehen...
-> http://adodb.sourceforge.net/
ist ja ein sehr nettes teil...

da gibts an sich einen sehr netten weg die phplib fast komplett rauszubekommen und das ganze auch noch kompatibel zu halten...
-> http://rfkmap.sourceforge.net/download/adodb-sql.html

das ganze emuliert phplib db zugriff auf basis von adodb

soweit ich das bis jetzt mal abgecheckt habe sind die restlichen teile
also sess und auth parts zwar momentan nicht kompatibel, ließen sich aber auch entsprechend einbinden... (die perm wäre egal)

na wie auch immer...

probleme soweit ich das gesehen habe ergeben sich an sich mit
$db->nextid() und das handling der sequence...
auch nicht schlecht das für jeden sequence eintrag ne eigene tabelle in adodb angelegt wird... ( ) und das ganze wird auch noch in den treiber dateien für die einzelnen db typen definiert...

was auch noch ganz nett ist -> es wäre möglich in der config.php einen primärenen db treiber zu definieren...

die setup routine könnte man an sich ebenso relativ leicht auf dein phplib kombatibles format bringen... da müsste man nicht mal seine phplib denkweise ändern

auch ganz nett ist das ein grossteil der funktionen innerhalb von functions.database.php durch die adodb gedeckt wären...

nachteil:
das ganze zeugs ist doch etwas gross (ca. 1,5 mb)
wird vermutlich langsamer sein als die phplib

vorteil:
mehr db schnittstellen
mehr möglichkeiten für hacker
zusätzliche möglichkeit nur mit adodb syntax arbeiten zu können
usw...

was mich jetzt intressieren würde ist einfach nur ob bestrebungen dahingegehen vorliegen, das entsprechend irgendwann mal in contenido einzubauen...
und die frage ob andere entwickler sich daran beteiligen würden, möchten, können, wollen etc...

[emergence]

keiner ne meinung dazu ? na dann leg ich das mal auf eis...

[timo]

naja wie schon vor einiger Zeit erwähnt, soll es ja demnächst viel neues bei Contenido geben, daher hab ich da im Moment leider auch keine Meinung zu

[HerrB]

naja wie schon vor einiger Zeit erwähnt, soll es ja demnächst viel neues bei Contenido geben, daher hab ich da im Moment leider auch keine Meinung zu

Öhm, d.h. wir sollten im Moment keine Energie mehr reinstecken...? Über einen Tipp (es sei jetzt mal dahingestellt, in welcher Form), woran denn gearbeitet wird bzw. was sich verändern wird (d.h. was man getrost ignorieren kann) würden wir uns schon freuen...

Gruß
HerrB

[timo]

naja es soll ein "neues" Contenido entstehen - inwieweit das solche Änderungen betrifft, kann ich leider nicht sagen (ich weiß es selbst noch nicht)

[rethus]

Ok, ich weiß dass der Thread steinalt ist, aber er ist meiner Meinung nach wieder sehr aktuell.
Da die Entwicklungen im Web wirklich schnellen Schrittes voran gehen, und mittlerweile auch viele unter Windows Server betreiben, würde es mich interessieren, ob für die Zukunft eine ausrichtung in Sachen Interportabilität von Contenido geplant ist.

Insbesondere denke ich hier an die DB in Verbindung mit ADODB.
Soweit ich weiß, geht Contenido derzeit ja Datenbanktechnisch über eine Wrapper-Klasse.
Wäre es hier nicht möglich diese in einer weiteren zu kapseln und letzendlich mit Adodb auf die Datenbanken zuzugreifen?

[xmurrix]

Hallo rethus,

die Umstellung von Contenido auf ADOdb oder ähnliches, auch wenn DB_Contenido als Wrapper dafür fungiert, wird sehr wahrscheinlich nicht möglich sein, wenn man dabei auch noch kompatibel bleiben möchte. Im Contenido Core gibt es viele SQL-Statements, die nicht dem ANSI-SQL Standard entsprechen, sondern rein MySQL spezifisch sind. Das bedeutet, trotz Verwendung von ADOdb, wäre nur der MySQL-Treiber verwendbar.

Sollte der Core erfolgreich auf einen neuen DB-Abstraktions Layer umgestellt werden, haben wir immer noch Module/Plugins, die da draußen herumschwirren.

Du kannst aber deinen eigenen DB-Abstraktions Layer im Frontend, in Modulen und Plugins verwenden, das Backend kann ja weiterhin wie bisher arbeiten.

Gruß
xmurrix

[kummer]

ich weiss, das ist eher eine prinzipielle frage. trotzdem: ist eine weitergehende abstraktion überhaupt sinnvoll? einfach so eine andere db zu verwenden, ohne zuvor alles eingehend zu prüfen wird nicht möglich sein. soviel ist klar. das braucht ressourcen. angesichts des entwicklungsfortschritts bei contenido in den vergangenen jahren ist davon auszugehen, dass man sich das nicht wird leisten können. entscheidender für mich ist allerdings die frage, ob der verzicht auf spezifische db-features, die ein bestimmtes rdbms mit sich bringt, nicht stark auf die leistung drücken muss.

um die frage auch gleich zu beantworten: das drückt. und zwar nicht zu knapp. weitergehende abstraktion bringt einen gewinn auf der einen, aber eben auch einen verlust auf der anderen seite. der code wird generischer und damit portabler. das ist die eine seite. aber wozu sollte ich ein anderes rdbms einsetzen wollen? doch vermutlich deshalb, weil es features aufweist, die ich gerne nutzen möchte. und hier tritt das dilemma dann zutage: genau das kann ich dann eben nicht, weil eine abstraktion entweder nur nutzen kann, was in allen unterstützten persistenzschichten vorhanden ist. womit das feature, das ich nutzen möchte, nicht zu nutzen ist. oder die abstraktion nutzt das rdbms in optimaler weise, also abgestimmt auf das jeweilige rdbms. dann wird jedoch der source komplexer oder der überhang auf programmatischer seite höher. und genau dieser überhang führt zu den leistungsunterschieden in verschiedenen technologien. während bei java (um nur ein bispiel zu nennen) ein solcher nur beim anwendungsstart auftritt und sich deshalb abstraktionsschichten wesentlich besser einsetzen lassen, ist das bei skriptsprachen (wie eben php) bei jedem einzelnen request wieder der fall.

bei zend lässt sich das sehr gut sehen. man kann sich die queries - auch bei nutzung der db-abstraktion - selber schreiben (und damit im idealfall optimal auf das zielsystem abstimmen). oder man lässt das zend tun. mit dem resultat, dass es erheblich langsamer ist. dafür portabler. aber eben, wozu sollte ich ein anderes rdbms einsetzen wollen, wenn ich die features, die für die db-wahl ausschlaggebend war, nicht werde nutzen können? mein fazit ist deshalb klar. abstraktion ja. optimierung auf ein zielsystem auch. soweit abstrahieren, dass eine portierung möglich wird auf kosten der leistung? ein klares nein. aber klar, die prämissen sind entscheidend. hier die leistung, da die portablität. man wird sich für das eine oder andere entscheiden müssen. oder dann die technologie wechseln (java und hibernate z.b.). dort ist das dillema kleiner; ganz verschwindet es aber freilich auch da nicht. die prinzipien bleiben dieselben. bloss die auswirkungen sind kleiner.

meist steht hinter dem wunsch weitreichender abstraktion nicht portablilität. das nur so nebenbei. häufig ist es eher eine frage der fitness der programmierer. sql ist jedermanns sache nicht. da sind dann hohe abstraktionslevels sozusagen sexy. aus der optik der anwender ist es eigentlich nie ein gewinn, da der leistungseinbusse nichts positives gegenüber steht.

[rethus]

Stimt, habt beide Recht. Hab mir die sache auch nochmal durchdacht. So oft kommt es ja nicht vor, dass man lieber eine andere DB nutzen müsste. Und Abstraktion verkompliziert, und frisst ressourcen.

Zudem hab ich gesehen, das ADODB schon steinalt ist, also seit 2007 scheinbar nicht mehr gepflegt wird.
Also einfach xlosen den Trhead, eh noch so einer wie ich hier vorbei kommt, und den wieder aufwärmt