CONTENIDO Forum

hallo

vielleicht kann mir jemand weiterhelfen. wenn ich mit der DB_contenido-Klasse ein insert in eine tabelle mit einem autowert-primärschlüssel vornehme, stellt mir dann die klasse den eingefügten autowert in irgendeiner form zur verfügung? und wenn ja, wie?

danke im voraus.

gruss,
andreas

du meinst mit auto_increment ?
ähm nein...

contenido verwendet hiefür die con_sequence
in der db klasse steht dafür die funktion nextid zur verfügung...
diese übernimmt das raufzählen in der con_sequence...

damit das natürlich funktioniert muss ein entsprechender eintrag der tabelle in der con_sequence vorhanden sein...

gibt es einen grund dafür? weil eigentlich würde mysql die insertid für verwendete db-verbindung zur verfügung stellen. der umweg über eine weitere tabelle ergibt - mindestens vordergründig - für mich kaum einen sinn.

ich hab das auch schon mal gefragt
siehe -> http://www.contenido.de/forum/viewtopic.php?p=8456#8456

ein weiteres zitat von timo:

das problem ist, daß nicht jede DB unique unterstützt, deshalb ist das auch über die sequence gelöst, sonst könnten wir einfach auto_increment benutzen.

falls es doch jemand braucht - ist nämlich letztlich performanter als extra eine weitere tabelle anzusprechen -, folgender query gibt den auto_wert zurück:
der wert bezieht sich auf die laufende verbindung und wird nicht durch inserts anderer clients oder anderer verbindungen beeinflusst.

gruss,
andreas

Dann musst Du aber die con_sequence noch updaten. Übrigens Oracle kann z.B. kein AutoWert in einem Tabellenfeld - ist dort mit so genannten "Sequenzen" gelöst...

Gruß
HerrB

nope, muss ich nicht. ich benutze einfach die contenido-db-klasse für eigene tabellen. dass eine id mehrfach in verschiedenen tabellen verwendet wird, stört dabei überhaupt nicht.

Übrigens Oracle kann z.B. kein AutoWert in einem Tabellenfeld - ist dort mit so genannten "Sequenzen" gelöst...

genau das habe ich ja gemeint. jede datenbank hat eine lösung für dieses problem. mit den sequenzen wird übrigens genau das gleiche erreicht, wie mit dem auto_increment (nur halt etwas performanter, da kein weiterer db-zugriff notwendig ist).

logisch das es preformanter ist... empfehlenswert ist es dennoch nicht...

was wenn jemand oracle db einsetzen möchte...
und die phplib dementsprechend umkonfiguriert würde dein modul eventuell nicht laufen...

nun ja, das ist schon richtig. allerdings wird kein script laufen, das mehr von einer db verwendet, als ansi92. die unterschiede sind so gross, dass ich mir kaum vorstellen kann, dass eine klasse einen arbiträren query so umschreiben kann, dass ein ursrpünglich für oracle geschriebener query auf mysql läuft (schon nur wegen den subselects zum beispiel oder funktionen, deren aufruf in beiden system nicht gleich ist).

ich mache mir darüber wenig sorgen. wenn es jemand für ein anderes rdbms einsetzen möchte, als ich es ursprünglich geschrieben habe, wird es nicht laufen. dafür ist es eben performanter.

mich würde interessieren, ob jemand schon überhaupt versucht hat, contenido mit oracle zu laufen zu bringen. ich halte es zwar nicht für gänzlich ausgeschlossen, allerdings würde es mich überraschen. schon alleine deshalb, weil oracle keine queries akzeptiert, die länger sind als 4000 zeichen. das heisst, dass ein blob oder clob zwingend mit variablenbindung übertragen werden muss. da hilft dann dynamisches umschreiben wenig.

genau deshalb gibt's die GenericDB - die soll als Layer fungieren, daß ein Entwickler eben kein Stück SQL mehr schreiben muß und damit auch gleich Cross-DB-Kompatibel ist.

machst du werbung für die genericdb ?

emergence hat geschrieben: machst du werbung für die genericdb ?

naja, kommt drauf an

der ursprüngliche Gedanke war ja, daß die Sequence ausreicht. Aber mit den ganzen MySQL-spezifischen Statements wurde daraus dann die GenericDB, dann die GenericDB mit Treibern usw

aber ein spezifisches problem mit unspezifischen methoden zu lösen, heisst letztlich, performance zu verlieren. ich frage mich deshalb, in wie weit es sinnvoll sein kann, ein anderes rdbms zu verwenden, wenn man dessen spezifische vorteile nicht wird nutzen können.

konkret: warum oracle einsetzen, wenn es durch die verwendung eines layers dann eben doch nicht mehr kann als jedes andere rdbms?

kummer hat geschrieben:aber ein spezifisches problem mit unspezifischen methoden zu lösen, heisst letztlich, performance zu verlieren. ich frage mich deshalb, in wie weit es sinnvoll sein kann, ein anderes rdbms zu verwenden, wenn man dessen spezifische vorteile nicht wird nutzen können.

Richtig, aber dafür bedeutet es kompatibilität. Wenn man alles optimieren würde, gäbe es z.b. keine Win32API, sondern jeder würde alles gleich mit Assembler machen.

Wenn du für deine Zwecke auto_increment nutzen kannst und auch optimierte SQL-Statements, dann ist das okay, aber wir von Contenido können und wollen es nicht.

Und als "Problem" sehe ich den aktuellen Stand von Contenido: Das System ist schwer debugbar, die SQL-Statements funktionieren nur auf MySQL und optimiert sind die Statements gar nicht.

konkret: warum oracle einsetzen, wenn es durch die verwendung eines layers dann eben doch nicht mehr kann als jedes andere rdbms?

Weil die Anforderungen unterschiedlich sein können. Und soviel Performance geht da nicht verloren. Außerdem bedeutet die GenericDB (im Zuge mit dem geplanten Ausbau auf Objekte) mehr Komfort beim Entwickeln, von dem auch die Endanwender profitieren können (weniger Bugs, mehr Konsistenz, bessere Anpassbarkeit).

nun ja, ich will ja nicht harnäckig erscheinen und im grund begrüsse ich alle arbeiten, die in richtung vereinfachung gehen natürlich.

nur noch soviel: da geht zuweilen mächtig performance verloren! wenn irgendwo überflüssig sequentiell abgefragt wird, anstatt einen - je nach rdbms verfügbaren - subselect oder join zu verwenden (ich denke da insbesondere an die möglichkeit unter oracle rekursiv abzufragen), dann macht das unter last sehr viel aus. wir reden zwar nur über wenige millisekunden; aber die vervielfachen sich unter last gewaltig.

um die diskussion nicht erneut anzufachen nur noch dies: es ist zu begrüssen, wenn es konsistenter wird und einfach zu debuggen. aber - wenn sich das realisieren lässt - sollte es immer noch die möglichkeit geben, selber arbiträre queries absetzen zu können. das scheint mir doch sehr wichtig!

ich will im übrigen nicht die entwicklerarbeit kritisieren: ich bin sehr zufrieden mit contenido!

gruss,
andreas