Re: LAPP statt LAMP?
Moin, * Markus Schulz wrote (2005-11-22 20:11): >Am Dienstag, 22. November 2005 16:55 schrieb Thorsten Haude: >> * Markus Schulz wrote (2005-11-22 16:37): >> >Und genau hier ist mir der Wechsel des DBMS nicht mehr möglich wenn >> > das neue keine Trigger gestattet. Denn der Nachbau von Triggern in >> > der Abstraktionsschicht ist nicht mehr möglich. >> >> Warum das denn nicht? > >Ich versuch mal meine Sicht an einem ganz einfachem Bsp. zu schildern: >Ich habe ein DB-Modell und eine Menge X an Funktionen/Strukturen in PHP >die meine API für die Clients (Web und Standalone) bilden. >Im Falle von Postgres, liefert die PHP API einfach nur das Ergebnis der >entsprechenden plpgsql-Funktion mit konvertierten Datentypen. >Wenn ich dagegen Mysql oder ähnlich funktionsarme DBMS verwende, >implementiere ich die notwendigen Funktionen mittels PHP kombiniert mit >SQL Abfragen an Mysql. >In diesem Interface kann ich vieles Nachbilden, einiges aber nur mit >großem Aufwand, z.B. cascadiertes Löschen/updaten ist verdammt >aufwendig. Das ist unbestritten, aber nicht das gleiche wie "nicht mehr möglich". >Für plpgsql ist da nichts zu tun, das erledigt das DBMS von >allein. Gleiches gilt für Trigger. Bei Triggern sehe ich kein größeres Problem, solange man nicht SQL benutzt, um auf die DB zuzugreifen, sondern einen Satz Funktionen der Mittelschicht. Ok, das würde man ohne Not vielleicht nicht machen, sollte aber auch nicht schwierig zu implementieren sein. >Dagegen läßt sich der Code einer plpgsql Funktion recht leicht in php >+ sql querys umsetzen. Solange man die Stored Procedures nicht zu dicht mit der DB verschmelzt, was aber irgendiwe ihr Hauptvorteil ist. Thorsten -- The best leaders are those barely known to their followers; after them, those they love; after them, those they fear; after them, those they despise. - Lao Tzu pgp0oWkkW8eQJ.pgp Description: PGP signature
Re: LAPP statt LAMP?
Am Dienstag, 22. November 2005 16:55 schrieb Thorsten Haude: > Moin, > > * Markus Schulz wrote (2005-11-22 16:37): > >On Tuesday 22 November 2005 15:27, Thorsten Haude wrote: > >> * Markus Schulz wrote (2005-11-22 15:07): > >> >In jedem zweiten Opensource-Webprojekt Projekt wird es genau so > >> > gemacht. Natürlich kann und sollte man vom DB-Code abstrahieren. > >> > Das spricht jedoch noch absolut nicht gegen den Einsatz von SP. > >> > >> Doch, genau das ist das Hauptargument gegen Stored Procedures, > >> solange man sie nicht einsetzt, um den Zugriff zur DB etwas zu > >> erleichtern. > > > >Warum? Wenn ich eine Schicht habe, die meine Anwendung abstrahiert > > von dem expliziten Aufruf einer SP habe ich doch keine Probleme > > beim Umstieg auf ein anderes DBMS. > > Das bekommst Du eben dann, wenn Du die Stored Procedures nicht 1:1 > auf das neue DBMS übertragen kannst. Wenn Du die DB- und > Geschäftsschicht trennst, hast Du es da erheblich leichter. > > >Und darum ging es doch, das ich im Ernstfall nur in der > >Verbindungsschicht von Anwendung und DBMS die SP eventuell durch SQL > >Code oder ähnliches Ersetzen kann, falls das DBMS mir SP von Haus > > aus nicht bietet. > > "Oder ähnliches" klappt leider nicht so gut, wenn Du die Datenlogik > mit der Geschäftslogik verstrickt hast. Das aber wird einem ja mit > Stored Procedures ja gerade so leicht gemacht. > > >> >Und Trigger empfinde ich als komplizierter zu abstrahieren als > >> > SP. > >> > >> Trigger haben nach außen unsichtbar zu sein. > > > >Und genau hier ist mir der Wechsel des DBMS nicht mehr möglich wenn > > das neue keine Trigger gestattet. Denn der Nachbau von Triggern in > > der Abstraktionsschicht ist nicht mehr möglich. > > Warum das denn nicht? Ich glaube wir haben ein unterschiedliches Verständnis von Abstraktionsschicht. Ich versuch mal meine Sicht an einem ganz einfachem Bsp. zu schildern: Ich habe ein DB-Modell und eine Menge X an Funktionen/Strukturen in PHP die meine API für die Clients (Web und Standalone) bilden. Im Falle von Postgres, liefert die PHP API einfach nur das Ergebnis der entsprechenden plpgsql-Funktion mit konvertierten Datentypen. Wenn ich dagegen Mysql oder ähnlich funktionsarme DBMS verwende, implementiere ich die notwendigen Funktionen mittels PHP kombiniert mit SQL Abfragen an Mysql. In diesem Interface kann ich vieles Nachbilden, einiges aber nur mit großem Aufwand, z.B. cascadiertes Löschen/updaten ist verdammt aufwendig. Für plpgsql ist da nichts zu tun, das erledigt das DBMS von allein. Gleiches gilt für Trigger. Dagegen läßt sich der Code einer plpgsql Funktion recht leicht in php + sql querys umsetzen. Aber nochmal, ich würde freiwillig nicht auf Features des DBMS verzichten die mir einen echten Vorteil verschaffen, das war Felix sein anliegen. -- Markus Schulz Ein wenig wie Windows: entweder es geht einfach oder gar nicht.
Re: LAPP statt LAMP?
On 22.11.05 10:42:06, Markus Schulz wrote: > On Tuesday 22 November 2005 02:36, Andreas Pakulat wrote: > > On 21.11.05 22:01:30, Sven Hartge wrote: > > > [EMAIL PROTECTED] wrote: > > > > dem Wort nach ist LAMP wohl sehr bekannt ... spricht eigentlich > > > > etwas gegen PostgreSQL statt MySQL? Oder anders herum: Warum > > > > eigentlich unbedingt MySQL statt Post? Historisch bedingt? > > > > > > Viele Projekte nutzen die Eigenheiten von MySQL und sind daher nur > > > schwer an Postgres anzupassen. > > > > Welche Eigenheiten? Fehlende Views, Triggers und bis 4.1 (die meisten > > Webspaces laufen noch mit 4.0) Subselects? > > z.B. das Replace Command. Kenne ich nicht, aber... > Oder Inserts mit mehreren VALUES () Blöcken. Das gibts bei Postgres > nicht. Ob das zu einem SQLXX Standard gehört weiss ich allerdings auch > nicht. Ich vermute eher nicht. Darueber bin ich auch letztens "gestolpert" und zuerst hab ich auch gedacht: Wieso kann PG das nicht. Aber wenn du mehrere INSERT'S in einem Block verarbeiten willst ist die korrekte Vorgehensweise sie in einem einzelnen commit zu verpacken. Das kann MySQL auch, aber PG zwingt dich dazu. Weiss eigentlich jemand wie MySQL mehrere VALUES() Bloecke behandelt? Werden das jeweils einzelne Transaktionen oder kommt alles intern in eine Transaktion? > > > MySQL ist/war auch einfacher zu handhaben als Postgres, weswegen > > > wiederum viele Projekte zuerst auf MySQL aufsetzten und erst später > > > dann Postgres-Support bekamen. > > > > Naja, teilweise ist Mysql auch "schwerer" zu bedienen, z.B. bei der > > User-Verwaltung, da sehe ich immernoch nicht wirklich durch und > > ausserdem verstehe ich nicht ganz den Sinn dahinter alle DB-User in > > der DB abzulegen. Da kann man sich auch leicht mal aussperren. > > Ich dagegen finde es sehr gut sämtliche Informationen zu einer Datenbank > in der Datenbank selbst auch vorzufinden. Dagegen ist nichts einzuwenden, aber... > Postgres ermöglich auch den Zugriff auf User Informationen über > Tabellen. Dabei geht man sogar viel weiter als Mysql es macht, es > stehen nämlich sämtliche Informationen zu Datenbanken, Tabellen, > Constraints, Typen, Views, .. in den Systemtabellen zur Verfügung. Bei MySQL sind die Systemtabellen bzw. die Systemdatenbank der _einzige_ Ort wo die Userinformationen gespeichert werden. Wenn die Tabelle weg ist, darfst du dir nen 2. MySQL aufsetzen um an deine Daten zu kommen - oder irre ich mich da? Andreas -- You will be a winner today. Pick a fight with a four-year-old. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: LAPP statt LAMP?
Moin, * Markus Schulz wrote (2005-11-22 16:37): >On Tuesday 22 November 2005 15:27, Thorsten Haude wrote: >> * Markus Schulz wrote (2005-11-22 15:07): >> >In jedem zweiten Opensource-Webprojekt Projekt wird es genau so >> > gemacht. Natürlich kann und sollte man vom DB-Code abstrahieren. >> > Das spricht jedoch noch absolut nicht gegen den Einsatz von SP. >> >> Doch, genau das ist das Hauptargument gegen Stored Procedures, >> solange man sie nicht einsetzt, um den Zugriff zur DB etwas zu >> erleichtern. > >Warum? Wenn ich eine Schicht habe, die meine Anwendung abstrahiert von >dem expliziten Aufruf einer SP habe ich doch keine Probleme beim >Umstieg auf ein anderes DBMS. Das bekommst Du eben dann, wenn Du die Stored Procedures nicht 1:1 auf das neue DBMS übertragen kannst. Wenn Du die DB- und Geschäftsschicht trennst, hast Du es da erheblich leichter. >Und darum ging es doch, das ich im Ernstfall nur in der >Verbindungsschicht von Anwendung und DBMS die SP eventuell durch SQL >Code oder ähnliches Ersetzen kann, falls das DBMS mir SP von Haus aus >nicht bietet. "Oder ähnliches" klappt leider nicht so gut, wenn Du die Datenlogik mit der Geschäftslogik verstrickt hast. Das aber wird einem ja mit Stored Procedures ja gerade so leicht gemacht. >> >Und Trigger empfinde ich als komplizierter zu abstrahieren als SP. >> >> Trigger haben nach außen unsichtbar zu sein. > >Und genau hier ist mir der Wechsel des DBMS nicht mehr möglich wenn das >neue keine Trigger gestattet. Denn der Nachbau von Triggern in der >Abstraktionsschicht ist nicht mehr möglich. Warum das denn nicht? >> >Würde deine Bedenken also eher genau umgedreht haben. Mir fällt da >> >nämlich keine Mögliche Abstraktion ein wie ich unabhängig vom DBMS >> > in einer Abstraktionsebene Trigger implementiere für DBMS die das >> > von Haus aus nicht beherrschen. >> >> Da gibt's schon Wege, aber ein fehlendes Feature kann man sicher >> nicht in allen Fällen ersetzen. Soll das jetzt heißen, daß ich bei >> Oracle, PostgreSQL, Firebird etc. auf alles verzichten soll, was >> MySQL nicht unterstützt? > >Nein, wo sag ich sowas? Wenn Du auf Trigger verzichten willst, weil sie nicht überall vorhanden sind, deutest Du genau das an. Wie sonst soll ich Dich verstehen? >> >SP kann man dagegen mit SQL Code umsetzen. >> >> Nur, wenn es eine passende Laufzeitumgebung gibt. MySQL kann SQL, >> aber eben keine Stored Procedures. > >Die Abstraktionsebene wird ja wohl nicht in SQL umgesetzt sein, eine >Laufzeitumgebung muss also wohl immer vorhanden sein. Huh? Also gibt es eine Laufzeitumgebung für MySQL-Trigger? Thorsten -- The smart way to keep people passive and obedient is to strictly limit the spectrum of acceptable opinion, but allow very lively debate within that spectrum. - Noam Chomsky pgptZRW40qXoh.pgp Description: PGP signature
Re: LAPP statt LAMP?
On Tuesday 22 November 2005 15:27, Thorsten Haude wrote: > * Markus Schulz wrote (2005-11-22 15:07): > >On Tuesday 22 November 2005 14:38, Thorsten Haude wrote: > >In jedem zweiten Opensource-Webprojekt Projekt wird es genau so > > gemacht. Natürlich kann und sollte man vom DB-Code abstrahieren. > > Das spricht jedoch noch absolut nicht gegen den Einsatz von SP. > > Doch, genau das ist das Hauptargument gegen Stored Procedures, > solange man sie nicht einsetzt, um den Zugriff zur DB etwas zu > erleichtern. Warum? Wenn ich eine Schicht habe, die meine Anwendung abstrahiert von dem expliziten Aufruf einer SP habe ich doch keine Probleme beim Umstieg auf ein anderes DBMS. Und darum ging es doch, das ich im Ernstfall nur in der Verbindungsschicht von Anwendung und DBMS die SP eventuell durch SQL Code oder ähnliches Ersetzen kann, falls das DBMS mir SP von Haus aus nicht bietet. > >Und Trigger empfinde ich als komplizierter zu abstrahieren als SP. > > Trigger haben nach außen unsichtbar zu sein. Und genau hier ist mir der Wechsel des DBMS nicht mehr möglich wenn das neue keine Trigger gestattet. Denn der Nachbau von Triggern in der Abstraktionsschicht ist nicht mehr möglich. Trigger sind also eher zu vermeiden als SP. Und nur weil sie nach aussen hin unsichtbar sind, erledigen sie doch eine Aufgabe. Und genau diese muss beim Einsatz eines DBMS ohne Trigger Unterstützung ja auch erledigt werden. Hier fangen die Probleme dann an. Wo wir bei Triggern sind, cascadierende Foreign-Keys sind da auch ein nettes Beispiel, ich kann mir ein Leben ohne kaum noch vorstellen. Das ganze in der Abstraktionsschicht zu implementieren ist Grausam und Fehleranfällig. Ich für meinen Teil würde nie mehr ein DBMS einsetzen das solche Möglichkeiten nicht bietet. > >Würde deine Bedenken also eher genau umgedreht haben. Mir fällt da > >nämlich keine Mögliche Abstraktion ein wie ich unabhängig vom DBMS > > in einer Abstraktionsebene Trigger implementiere für DBMS die das > > von Haus aus nicht beherrschen. > > Da gibt's schon Wege, aber ein fehlendes Feature kann man sicher > nicht in allen Fällen ersetzen. Soll das jetzt heißen, daß ich bei > Oracle, PostgreSQL, Firebird etc. auf alles verzichten soll, was > MySQL nicht unterstützt? Nein, wo sag ich sowas? Im Gegenteil, ich würde immer alles Ausreizen was mir eine Datenbank bietet solange ich dadurch signifikante Vorteile bekomme. Wenn bei Postgres z.B. die Vererbung inkl. allen Constraints funktioniert werden wir sie hier in der Firma auch einsetzen. Ich wollte nur auf die Gefahr von Triggern im Gegensatz zu SP beim Wechsel eines DBMS und der dazu notwendigen Abstraktionsebene hinweisen. Ich für meinen Teil bin auf die Abstraktionsebene nicht angewiesen _weil_ ich das DBMS wechseln will, sondern um verschiedenen Client-Applikationen (Standalone + Browser) eine einheitliche Schnittstelle bieten zu können. > > >SP kann man dagegen mit SQL Code umsetzen. > > Nur, wenn es eine passende Laufzeitumgebung gibt. MySQL kann SQL, > aber eben keine Stored Procedures. Die Abstraktionsebene wird ja wohl nicht in SQL umgesetzt sein, eine Laufzeitumgebung muss also wohl immer vorhanden sein. > >> >DBMS wechseln ist schwierig, das gebe ich zu. Allerdings könnte > >> > man da auch kontern, wer das DBMS wechseln muss hat sich im > >> > Vorfeld nicht genügend Gedanken in Bezug auf Skalierbarkeit etc > >> > gemacht. > >> > >> Quatsch. Es kann einfach einem proprietären Hersteller einfallen, > >> in einer neuen Version oder einem Servicepack zu verbieten, > >> Vogelbilder in der Datenbank zu speichern. Dann steht man da mit > >> seiner Vogelbildersammlung und muß eine neue Datenbank suchen. > >> Will sagen: es gibt noch deutlich mehr Gründe, das DBMS zu > >> wechseln als Leistung. > > > >Und trotzdem bleibt der Wechsel eines DBMS nicht ohne Arbeit. > > Habe ich dem widersprochen? Nein, aber darum ging es in meiner Diskussion mit Felix. Und du hast dir quasi nur den Nebensatz der eigentlichen Aussage rausgepickt :) > >Und mehr wollte ich nicht sagen. > > Da steht implizit, daß man nur wechseln muß, wenn man skalieren muß, > wenn also die Leistung nicht ausreicht. da steht: "Skalierbarkeit etc" Und Gedanken machen kann man sich auch über den Support/Beständigkeit des DBMS Herstellers. Aber darüber will ich eigentlich garnicht diskutieren. Mir ging es einzig und allein um: SP und andere spezifische Features eines DBMS nutzen ja/nein? Markus -- "Ich dachte immer, UNIX ist was für Leute, denen es gefällt, auf einen Bildschirm zu starren, auf dem es aussieht, als hätte sich gerade ein Gürteltier auf der Tastatur gewälzt." (Stefan Schneider)
Re: LAPP statt LAMP?
Hallo Thorsten, * Thorsten Haude <[EMAIL PROTECTED]> [20051122 15:27]: > Trigger haben nach außen unsichtbar zu sein. Durchaus richtig, sind sie ja auch. Nur wird sich meine Applikation dann wohl auf die "niederen Arbeiten", die der Trigger verrichtet, verlassen. Da ist es schnell so weit, dass sie ohne diesen nicht mehr funktionieren kann. Oder vielleicht fragt man sich beim lesen des Quellcodes, warum das da überhaupt funktionieren kann. Usw. Eigentlich sollte man für seine Datenhaltung eine eigene Abstraktion haben. Und WENN man die hat, sehe ich nicht, welchen Nutzen einem ein Trigger noch bringen könnte. Grüße, Felix -- | /"\ ASCII Ribbon | Felix M. Palmen (Zirias)http://zirias.ath.cx/ | | \ / Campaign Against | [EMAIL PROTECTED] encrypted mail welcome | | XHTML In Mail | PGP key: http://zirias.ath.cx/pub.txt | | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 | signature.asc Description: Digital signature
Re: LAPP statt LAMP?
Hallo Thorsten, * Thorsten Haude <[EMAIL PROTECTED]> [20051122 14:35]: > Moin, > > * Felix M. Palmen wrote (2005-11-22 11:06): > >Nicht, dass das jetzt durch bloßes Vorhandsein stören würde, aber: > >Nachdem ich seit einiger Zeit im Job an einem Projekt sitze, bei dem > >Trigger für gewisse Konsistenz-Aufgaben benutzt werden, kann ich nur > >sagen: Sowas ist "böse". > > Sowas ist gut und sinnvoll, man muß es halt nur richtig machen. Was wäre denn "richtig"? Wie vermeidet man denn bei Triggern, dass Logik aus dem dafür offensichtlichen Bereich (nämlich meinem Quellcode) wandert? (und dass diese Programmteile dann mit hoher Wahrscheinlichkeit eben äußerst abhängig sind vom verwendeten DBMS) IMHO ist das einzig vernünftige, statt der Trigger eine eigene Abstraktion zu verwenden, die die entsprechenden Aufgaben übernimmt. > Da ist offensichtlich gepfuscht worden. Ja, zwangsläufig, aber das ist ein anderes Thema. Allein die Verwendung von jeder Menge Triggern halte ich für Pfusch. Grüße, Felix -- | /"\ ASCII Ribbon | Felix M. Palmen (Zirias)http://zirias.ath.cx/ | | \ / Campaign Against | [EMAIL PROTECTED] encrypted mail welcome | | XHTML In Mail | PGP key: http://zirias.ath.cx/pub.txt | | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 | signature.asc Description: Digital signature
Re: LAPP statt LAMP?
Moin, * Markus Schulz wrote (2005-11-22 15:07): >On Tuesday 22 November 2005 14:38, Thorsten Haude wrote: >> Moin, >> >> * Markus Schulz wrote (2005-11-22 12:18): >[...] >> >Gerade SP erlauben es viele Arbeiten die mit der Oberfläche nichts >> > zu tun haben in die Datenbank auszulagern und bereinigen damit den >> > Oberflächen Code. >> >> Oha, Oberflächecode? Fehlt da nicht eine Schicht? Im Gegensatz zu >> Triggern halte ich Stored Procedures tatsächlich für gefährlich, die >> verführen nämlich dazu, DB und Businesslogik zu vermischen. Das kann >> man richtig machen und trennen, dann kann man aber auch gleich eine >> richtige Programmiersprache benutzen. > >In jedem zweiten Opensource-Webprojekt Projekt wird es genau so gemacht. >Natürlich kann und sollte man vom DB-Code abstrahieren. Das spricht >jedoch noch absolut nicht gegen den Einsatz von SP. Doch, genau das ist das Hauptargument gegen Stored Procedures, solange man sie nicht einsetzt, um den Zugriff zur DB etwas zu erleichtern. >Und Trigger empfinde ich als komplizierter zu abstrahieren als SP. Trigger haben nach außen unsichtbar zu sein. >Würde deine Bedenken also eher genau umgedreht haben. Mir fällt da >nämlich keine Mögliche Abstraktion ein wie ich unabhängig vom DBMS in >einer Abstraktionsebene Trigger implementiere für DBMS die das von >Haus aus nicht beherrschen. Da gibt's schon Wege, aber ein fehlendes Feature kann man sicher nicht in allen Fällen ersetzen. Soll das jetzt heißen, daß ich bei Oracle, PostgreSQL, Firebird etc. auf alles verzichten soll, was MySQL nicht unterstützt? >SP kann man dagegen mit SQL Code umsetzen. Nur, wenn es eine passende Laufzeitumgebung gibt. MySQL kann SQL, aber eben keine Stored Procedures. >> >DBMS wechseln ist schwierig, das gebe ich zu. Allerdings könnte man >> > da auch kontern, wer das DBMS wechseln muss hat sich im Vorfeld >> > nicht genügend Gedanken in Bezug auf Skalierbarkeit etc gemacht. >> >> Quatsch. Es kann einfach einem proprietären Hersteller einfallen, in >> einer neuen Version oder einem Servicepack zu verbieten, Vogelbilder >> in der Datenbank zu speichern. Dann steht man da mit seiner >> Vogelbildersammlung und muß eine neue Datenbank suchen. Will sagen: >> es gibt noch deutlich mehr Gründe, das DBMS zu wechseln als Leistung. > >Und trotzdem bleibt der Wechsel eines DBMS nicht ohne Arbeit. Habe ich dem widersprochen? >Und mehr wollte ich nicht sagen. Da steht implizit, daß man nur wechseln muß, wenn man skalieren muß, wenn also die Leistung nicht ausreicht. >Zumal dein Beispiel mehr als abstrus ist Weil es um Vogelbilder geht? Dummerweise kann man im Vorhinein nicht wissen, auf welche absonderliche Gedanken die Hersteller proprietärer Software kommen. Thorsten -- No one ever says, "I can't read that ASCII Email you sent me." pgpqSh3wuGjjR.pgp Description: PGP signature
Re: LAPP statt LAMP?
On Tuesday 22 November 2005 12:26, Felix M. Palmen wrote: > Hallo Markus, > > * Markus Schulz <[EMAIL PROTECTED]> [20051122 12:18]: > > Versteh ich nioht, wieso wird die Applikation durch Verwendung von > > Trigger und SP auseinandergerissen? > > Ein "zip hier, unzip dort" funktioniert nicht mehr. Es sei denn man > macht sich die zusätzliche Mühe und schreibt ein sehr umfassendes > "Setup-Script". Das hat man bei Datenbank gestützten Applikationen doch nie. Eine ordentliche Setup-Engine sollte man dafür schon entwickeln. Dabei kann man gleich den Update-Mechanismus mit entwickeln, den man früher oder später eh brauchen wird. > > Warum das ganze dann noch Einfluss auf einen > > Serverumzug hat versteh ich auch nicht. Wir haben in den letzten > > Jahren keine derartigen Probleme mit Postgres gehabt. Oder verstehe > > ich dich hier irgendwie falsch? > > Man ist zumindest sehr von der Qualität der Im- und Export Funktionen > des DBMS abhängig. Bei MSSQL habe ich da nicht gerade erfreuliche > Erfahrungen. Wir hier mit Postgres haben da bisher kaum Probleme. Wir setzen das alles aber auch mittels Debian Paketen um. Dank Transaktionen bei Postgres hat man bei Problemen im Update Vorgang auch keine Inkonsistenz. > > Gerade SP erlauben es viele Arbeiten die mit der Oberfläche nichts > > zu tun haben in die Datenbank auszulagern und bereinigen damit den > > Oberflächen Code. > > Viel eleganter wäre es, dafür eine weitere Schicht in seiner eigenen > Applikation zu haben. (Die wäre dann auch der richtige Angriffspunkt > bei einem Wechsel des DBMS). Da hast du recht, eine weitere Schicht vor der Applikation ist sehr sinnvoll. In dieser Schicht entscheide ich dann, ob ich die von der Anwendung angeforderte Datenbank Funktion als SP Aufruf weiterreiche oder direkt als hinterlegten SQL Code ausführe muss, weil die DB keine SP bietet. Wieso also auf Features verzichten die ich nutzen kann? Einzig ordentlich designen muss man das ganze. > > > zum größeren Problem wird, an einen Austausch des DBMS möchte ich > > > gar nicht erst denken. > > > > DBMS wechseln ist schwierig, das gebe ich zu. Allerdings könnte man > > da auch kontern, wer das DBMS wechseln muss hat sich im Vorfeld > > nicht genügend Gedanken in Bezug auf Skalierbarkeit etc gemacht. > > Ein Faktor für Skalierbarkeit ist unter anderem der möglichst > einfache Austausch von Modulen. Da magst du Recht haben, trotzdem wird es immer mit Arbeit verbunden sein. Ich glaube kaum das es Enterprise Lösungen gibt, die nur durch Installation eines anderen DBMS und Import des SQL92 Dumps lauffähig werden. Falls doch erscheint mir das DBMS dort nicht als zentraler Bestandteil der Lösung. Markus -- Kreuzigt mich - aber Debian ist einfach deppensicher. Es lässt Deppen gegen eine Wand von Schwierigkeiten klatschen und langsam abtropfen. Wer die Tür findet, darf mitspielen - und so sieht das Spielzeug dann eben aus: Gut gepflegt. -- Joerg Rossdeutscher
Re: LAPP statt LAMP?
On Tuesday 22 November 2005 14:38, Thorsten Haude wrote: > Moin, > > * Markus Schulz wrote (2005-11-22 12:18): [...] > >Gerade SP erlauben es viele Arbeiten die mit der Oberfläche nichts > > zu tun haben in die Datenbank auszulagern und bereinigen damit den > > Oberflächen Code. > > Oha, Oberflächecode? Fehlt da nicht eine Schicht? Im Gegensatz zu > Triggern halte ich Stored Procedures tatsächlich für gefährlich, die > verführen nämlich dazu, DB und Businesslogik zu vermischen. Das kann > man richtig machen und trennen, dann kann man aber auch gleich eine > richtige Programmiersprache benutzen. In jedem zweiten Opensource-Webprojekt Projekt wird es genau so gemacht. Natürlich kann und sollte man vom DB-Code abstrahieren. Das spricht jedoch noch absolut nicht gegen den Einsatz von SP. Und Trigger empfinde ich als komplizierter zu abstrahieren als SP. Würde deine Bedenken also eher genau umgedreht haben. Mir fällt da nämlich keine Mögliche Abstraktion ein wie ich unabhängig vom DBMS in einer Abstraktionsebene Trigger implementiere für DBMS die das von Haus aus nicht beherrschen. SP kann man dagegen mit SQL Code umsetzen. > >DBMS wechseln ist schwierig, das gebe ich zu. Allerdings könnte man > > da auch kontern, wer das DBMS wechseln muss hat sich im Vorfeld > > nicht genügend Gedanken in Bezug auf Skalierbarkeit etc gemacht. > > Quatsch. Es kann einfach einem proprietären Hersteller einfallen, in > einer neuen Version oder einem Servicepack zu verbieten, Vogelbilder > in der Datenbank zu speichern. Dann steht man da mit seiner > Vogelbildersammlung und muß eine neue Datenbank suchen. Will sagen: > es gibt noch deutlich mehr Gründe, das DBMS zu wechseln als Leistung. Und trotzdem bleibt der Wechsel eines DBMS nicht ohne Arbeit. Und mehr wollte ich nicht sagen. Zumal dein Beispiel mehr als abstrus ist, meine Modell Implementierung wird sich wohl an einem SQL Standard + Hersteller spezifische Sprachen halten und von diesem wird sich ein Hersteller nur schwerlich in einem SP trennen. -- Kreuzigt mich - aber Debian ist einfach deppensicher. Es lässt Deppen gegen eine Wand von Schwierigkeiten klatschen und langsam abtropfen. Wer die Tür findet, darf mitspielen - und so sieht das Spielzeug dann eben aus: Gut gepflegt. -- Joerg Rossdeutscher
Re: LAPP statt LAMP?
Moin, * Felix M. Palmen wrote (2005-11-22 11:06): >Nicht, dass das jetzt durch bloßes Vorhandsein stören würde, aber: >Nachdem ich seit einiger Zeit im Job an einem Projekt sitze, bei dem >Trigger für gewisse Konsistenz-Aufgaben benutzt werden, kann ich nur >sagen: Sowas ist "böse". Sowas ist gut und sinnvoll, man muß es halt nur richtig machen. >Vom Schichten-Gedanken her mag es zwar noch Sinn ergeben, aber die >Applikation wird dadurch derart auseinandergerissen, dass schon der >Umzug auf einen anderen Server zum größeren Problem wird, an einen >Austausch des DBMS möchte ich gar nicht erst denken. Da ist offensichtlich gepfuscht worden. Thorsten -- Wer die Wahrheit nicht weiß, der ist bloß ein Dummkopf. Aber wer sie weiß und sie eine Lüge nennt, der ist ein Verbrecher! - Berthold Brecht pgpKl9BYtCSvV.pgp Description: PGP signature
Re: LAPP statt LAMP?
Moin, * Markus Schulz wrote (2005-11-22 12:18): >Versteh ich nioht, wieso wird die Applikation durch Verwendung von >Trigger und SP auseinandergerissen? Ist doch nur eine Frage des >Applikations Designs. Warum das ganze dann noch Einfluss auf einen >Serverumzug hat versteh ich auch nicht. Wir haben in den letzten Jahren >keine derartigen Probleme mit Postgres gehabt. Oder verstehe ich dich >hier irgendwie falsch? >Gerade SP erlauben es viele Arbeiten die mit der Oberfläche nichts zu >tun haben in die Datenbank auszulagern und bereinigen damit den >Oberflächen Code. Oha, Oberflächecode? Fehlt da nicht eine Schicht? Im Gegensatz zu Triggern halte ich Stored Procedures tatsächlich für gefährlich, die verführen nämlich dazu, DB und Businesslogik zu vermischen. Das kann man richtig machen und trennen, dann kann man aber auch gleich eine richtige Programmiersprache benutzen. >DBMS wechseln ist schwierig, das gebe ich zu. Allerdings könnte man da >auch kontern, wer das DBMS wechseln muss hat sich im Vorfeld nicht >genügend Gedanken in Bezug auf Skalierbarkeit etc gemacht. Quatsch. Es kann einfach einem proprietären Hersteller einfallen, in einer neuen Version oder einem Servicepack zu verbieten, Vogelbilder in der Datenbank zu speichern. Dann steht man da mit seiner Vogelbildersammlung und muß eine neue Datenbank suchen. Will sagen: es gibt noch deutlich mehr Gründe, das DBMS zu wechseln als Leistung. Thorsten -- The liberty of a democracy is not safe if the people tolerate the growth of private power to the point where it becomes stronger than the democratic state itself. - Franklin D. Roosevelt pgpmZ2pL8fKs8.pgp Description: PGP signature
Re: LAPP statt LAMP?
Hallo Markus, * Markus Schulz <[EMAIL PROTECTED]> [20051122 12:18]: > Versteh ich nioht, wieso wird die Applikation durch Verwendung von > Trigger und SP auseinandergerissen? Ein "zip hier, unzip dort" funktioniert nicht mehr. Es sei denn man macht sich die zusätzliche Mühe und schreibt ein sehr umfassendes "Setup-Script". > Warum das ganze dann noch Einfluss auf einen > Serverumzug hat versteh ich auch nicht. Wir haben in den letzten Jahren > keine derartigen Probleme mit Postgres gehabt. Oder verstehe ich dich > hier irgendwie falsch? Man ist zumindest sehr von der Qualität der Im- und Export Funktionen des DBMS abhängig. Bei MSSQL habe ich da nicht gerade erfreuliche Erfahrungen. > Gerade SP erlauben es viele Arbeiten die mit der Oberfläche nichts zu > tun haben in die Datenbank auszulagern und bereinigen damit den > Oberflächen Code. Viel eleganter wäre es, dafür eine weitere Schicht in seiner eigenen Applikation zu haben. (Die wäre dann auch der richtige Angriffspunkt bei einem Wechsel des DBMS). > > zum größeren Problem wird, an einen Austausch des DBMS möchte ich gar > > nicht erst denken. > > DBMS wechseln ist schwierig, das gebe ich zu. Allerdings könnte man da > auch kontern, wer das DBMS wechseln muss hat sich im Vorfeld nicht > genügend Gedanken in Bezug auf Skalierbarkeit etc gemacht. Ein Faktor für Skalierbarkeit ist unter anderem der möglichst einfache Austausch von Modulen. Grüße, Felix -- | /"\ ASCII Ribbon | Felix M. Palmen (Zirias)http://zirias.ath.cx/ | | \ / Campaign Against | [EMAIL PROTECTED] encrypted mail welcome | | XHTML In Mail | PGP key: http://zirias.ath.cx/pub.txt | | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 | signature.asc Description: Digital signature
Re: LAPP statt LAMP?
On Tuesday 22 November 2005 11:06, Felix M. Palmen wrote: > Hallo Kai, > > * Kai Festersen <[EMAIL PROTECTED]> [20051122 00:04]: > > MySQL (Trigger, Stored Procedures) und - aus meiner Sicht sehr > >^^ > Nicht, dass das jetzt durch bloßes Vorhandsein stören würde, aber: > Nachdem ich seit einiger Zeit im Job an einem Projekt sitze, bei dem > Trigger für gewisse Konsistenz-Aufgaben benutzt werden, kann ich nur > sagen: Sowas ist "böse". Vom Schichten-Gedanken her mag es zwar noch > Sinn ergeben, aber die Applikation wird dadurch derart > auseinandergerissen, dass schon der Umzug auf einen anderen Server Versteh ich nioht, wieso wird die Applikation durch Verwendung von Trigger und SP auseinandergerissen? Ist doch nur eine Frage des Applikations Designs. Warum das ganze dann noch Einfluss auf einen Serverumzug hat versteh ich auch nicht. Wir haben in den letzten Jahren keine derartigen Probleme mit Postgres gehabt. Oder verstehe ich dich hier irgendwie falsch? Gerade SP erlauben es viele Arbeiten die mit der Oberfläche nichts zu tun haben in die Datenbank auszulagern und bereinigen damit den Oberflächen Code. > zum größeren Problem wird, an einen Austausch des DBMS möchte ich gar > nicht erst denken. DBMS wechseln ist schwierig, das gebe ich zu. Allerdings könnte man da auch kontern, wer das DBMS wechseln muss hat sich im Vorfeld nicht genügend Gedanken in Bezug auf Skalierbarkeit etc gemacht. Markus -- "Des is völlig wurscht, was heut beschlossen wird: I bin sowieso dagegn!" (SPD-Stadtrat Kurt Schindler; Regensburg)
Re: LAPP statt LAMP?
Hallo Kai, * Kai Festersen <[EMAIL PROTECTED]> [20051122 00:04]: > MySQL (Trigger, Stored Procedures) und - aus meiner Sicht sehr ^^ Nicht, dass das jetzt durch bloßes Vorhandsein stören würde, aber: Nachdem ich seit einiger Zeit im Job an einem Projekt sitze, bei dem Trigger für gewisse Konsistenz-Aufgaben benutzt werden, kann ich nur sagen: Sowas ist "böse". Vom Schichten-Gedanken her mag es zwar noch Sinn ergeben, aber die Applikation wird dadurch derart auseinandergerissen, dass schon der Umzug auf einen anderen Server zum größeren Problem wird, an einen Austausch des DBMS möchte ich gar nicht erst denken. Grüße, Felix -- | /"\ ASCII Ribbon | Felix M. Palmen (Zirias)http://zirias.ath.cx/ | | \ / Campaign Against | [EMAIL PROTECTED] encrypted mail welcome | | XHTML In Mail | PGP key: http://zirias.ath.cx/pub.txt | | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 | signature.asc Description: Digital signature
Re: LAPP statt LAMP?
On Tuesday 22 November 2005 02:36, Andreas Pakulat wrote: > On 21.11.05 22:01:30, Sven Hartge wrote: > > [EMAIL PROTECTED] wrote: > > > dem Wort nach ist LAMP wohl sehr bekannt ... spricht eigentlich > > > etwas gegen PostgreSQL statt MySQL? Oder anders herum: Warum > > > eigentlich unbedingt MySQL statt Post? Historisch bedingt? > > > > Viele Projekte nutzen die Eigenheiten von MySQL und sind daher nur > > schwer an Postgres anzupassen. > > Welche Eigenheiten? Fehlende Views, Triggers und bis 4.1 (die meisten > Webspaces laufen noch mit 4.0) Subselects? z.B. das Replace Command. Oder Inserts mit mehreren VALUES () Blöcken. Das gibts bei Postgres nicht. Ob das zu einem SQLXX Standard gehört weiss ich allerdings auch nicht. Ich vermute eher nicht. > > MySQL ist/war auch einfacher zu handhaben als Postgres, weswegen > > wiederum viele Projekte zuerst auf MySQL aufsetzten und erst später > > dann Postgres-Support bekamen. > > Naja, teilweise ist Mysql auch "schwerer" zu bedienen, z.B. bei der > User-Verwaltung, da sehe ich immernoch nicht wirklich durch und > ausserdem verstehe ich nicht ganz den Sinn dahinter alle DB-User in > der DB abzulegen. Da kann man sich auch leicht mal aussperren. Ich dagegen finde es sehr gut sämtliche Informationen zu einer Datenbank in der Datenbank selbst auch vorzufinden. Postgres ermöglich auch den Zugriff auf User Informationen über Tabellen. Dabei geht man sogar viel weiter als Mysql es macht, es stehen nämlich sämtliche Informationen zu Datenbanken, Tabellen, Constraints, Typen, Views, .. in den Systemtabellen zur Verfügung. Markus Schulz -- "Wenn manche Leute verstanden hätten, wie Patente erteilt werden würden, als die meisten der heutigen Ideen erfunden wurden, und wenn sie sich dann Patente geholt hätten, wäre unsere Branche heute im kompletten Stillstand." Bill Gates (1991)
Re: LAPP statt LAMP?
On 21.11.05 22:01:30, Sven Hartge wrote: > [EMAIL PROTECTED] wrote: > > > dem Wort nach ist LAMP wohl sehr bekannt ... spricht eigentlich etwas > > gegen PostgreSQL statt MySQL? Oder anders herum: Warum eigentlich > > unbedingt MySQL statt Post? Historisch bedingt? > > Viele Projekte nutzen die Eigenheiten von MySQL und sind daher nur > schwer an Postgres anzupassen. Welche Eigenheiten? Fehlende Views, Triggers und bis 4.1 (die meisten Webspaces laufen noch mit 4.0) Subselects? > MySQL ist/war auch einfacher zu handhaben als Postgres, weswegen > wiederum viele Projekte zuerst auf MySQL aufsetzten und erst später > dann Postgres-Support bekamen. Naja, teilweise ist Mysql auch "schwerer" zu bedienen, z.B. bei der User-Verwaltung, da sehe ich immernoch nicht wirklich durch und ausserdem verstehe ich nicht ganz den Sinn dahinter alle DB-User in der DB abzulegen. Da kann man sich auch leicht mal aussperren. Andreas -- Blow it out your ear. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: LAPP statt LAMP?
Hi, Ja. AFAIK hat Postgresql viele Features die es nahe an "professionelle/proprietäre" Datenbanken bringen, ob man die allerdings immer alle braucht, naja, bin kein Datenbankexperte ... Naja, viele Autos haben auch einen Airbag oder ABS. Normalerweise braucht man das Zeugs auch nicht. Voellig unnuetz im Alltag. Find ich auch, Postgres ist einfach eine strategisch richtige Entscheidung, weil es mehr Standards hat, also kompatiblere Befehle zum SQL-Standard nutzt, mehr Features hat bzw. wesentlich laenger hat als MySQL (Trigger, Stored Procedures) und - aus meiner Sicht sehr sympathisch - keine so hektische Entwicklung durchmacht wie MySQL, wo quartalsweise neue Features auftauchen. Postgres ist eine Konkurrenz für Oracle. Und die vielgeschmähte Langsamkeit (ob das noch so ist, bin seit 7.1 kein Pg-Nutzer mehr) ist der Preis für die Sicherheit. Moeglicherweise ist Postgres nicht so flott in der Kommunikation/Austausch mit XML, da hat die MySQL-Truppe frühzeitig gut reagiert. Mir persönlich schien Postgres auch einfacher in der Installation, das hab ich in 20 Minuten hinbekommen, MySQL nie unter drei Stunden. Aber... die beiden Lager können hier jetzt endlos einen Schmäh hinlegen... ;-) Insofern: wenn man nur eine Mini-Datenbank braucht fuer paar tausend Adressen oder so Kram, keine grossen mathematischen Sachen, also nur Datenhaltung... dann kann man aus meiner Sicht auch SQLite benutzen, das ist m.E. ab PHP5 standardmaessig vorinstalliert, in einem normalen Alltag braucht man wenig mehr. Wenn es aufwaendiger wird und kritischer, dann kann es nur Postgres sein. Dazwischen liegen extrem hohe Datenmengen in einfacher Vorhaltung, also Telefonnummern oder MP3-Titel, das würd' ich nicht in SQLite machen wollen, aber auch nicht in Postgres. Von daher: Je nach Zweck... MySQL allerdings ist mit Abstand am besten unterstützt - was auch immer es in PHP gibt, es läuft auf MySQL, fuer Postgres vorgefertigte Pakete gibt es vielleicht 10 bis 15% von den MySQL-Angeboten. Will man also Tools von der Stange, dann ist MySQL moeglicherweise die beste Wahl - es sei denn, das betreffende Tool gibts auch in SQLite. Kai -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: LAPP statt LAMP?
On Mon, Nov 21, 2005 at 10:20:53PM +0100, Matthias Haegele wrote: > >Ähm, ja. Vermutlich, weil MySQL von deutlich mehr Hostern angeboten > >wird. Rein technisch ist PG deutlich besser. IMHO. > Ja. AFAIK hat Postgresql viele Features die es nahe an > "professionelle/proprietäre" Datenbanken bringen, ob man die allerdings > immer alle braucht, naja, bin kein Datenbankexperte ... Naja, viele Autos haben auch einen Airbag oder ABS. Normalerweise braucht man das Zeugs auch nicht. Voellig unnuetz im Alltag. Nur: wenn man in eine Situation kommt, in der man es dann doch mal braucht, ist es eine dumme Situation, wenn man ein Auto gekauft hat, in der Annahme, dass man diese Sachen eh nie brauchen wird. Insofern setze ich lieber das ein, was mir alle Freiheiten laesst, anstatt dann ploetzlich vor der Situation stehen zu muessen, eine Datenbank zu haben, die den Anforderungen nicht mehr gerecht wird und wo ich dann doch noch migrieren muss. Unnuetzer zusaetzlicher Aufwand, IMHO. Dann doch lieber aufs richtige Pferd setzen... -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc signature.asc Description: Digital signature
Re: LAPP statt LAMP?
Andreas Kretschmer schrieb: am 21.11.2005, um 21:53:11 +0100 mailte [EMAIL PROTECTED] folgendes: Moin, zusammn, Hallo!. Ähm, ja. Vermutlich, weil MySQL von deutlich mehr Hostern angeboten wird. Rein technisch ist PG deutlich besser. IMHO. Ja. AFAIK hat Postgresql viele Features die es nahe an "professionelle/proprietäre" Datenbanken bringen, ob man die allerdings immer alle braucht, naja, bin kein Datenbankexperte ... Andreas Grüsse MH -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: LAPP statt LAMP?
Hi, * [EMAIL PROTECTED] wrote (2005-11-21 21:53): >dem Wort nach ist LAMP wohl sehr bekannt ... spricht eigentlich etwas >gegen PostgreSQL statt MySQL? Oder anders herum: Warum eigentlich >unbedingt MySQL statt Post? Historisch bedingt? Das ist vor allem historisch bedingt. Ich würde mich zB. vermutlich für Ruby entscheiden, das wäre dann LAPR. In der Wikipedia finden sich ganze Listen mit möglichen Kombinationen. Thorsten -- Is there a suspect in your family? - Contact the Ministry of Information. pgpohoJFtA8Jm.pgp Description: PGP signature
Re: LAPP statt LAMP?
am 21.11.2005, um 21:53:11 +0100 mailte [EMAIL PROTECTED] folgendes: > Moin, zusammn, > > dem Wort nach ist LAMP wohl sehr bekannt ... spricht eigentlich etwas > gegen PostgreSQL statt MySQL? Oder anders herum: Warum eigentlich Nein. Ganz im Gegenteil. > unbedingt MySQL statt Post? Historisch bedingt? Millionen von Fliegen... Ähm, ja. Vermutlich, weil MySQL von deutlich mehr Hostern angeboten wird. Rein technisch ist PG deutlich besser. IMHO. Andreas -- Andreas Kretschmer(Kontakt: siehe Header) Heynitz: 035242/47212, D1: 0160/7141639 GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net ===Schollglas Unternehmensgruppe=== -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: LAPP statt LAMP?
[EMAIL PROTECTED] wrote: > dem Wort nach ist LAMP wohl sehr bekannt ... spricht eigentlich etwas > gegen PostgreSQL statt MySQL? Oder anders herum: Warum eigentlich > unbedingt MySQL statt Post? Historisch bedingt? Viele Projekte nutzen die Eigenheiten von MySQL und sind daher nur schwer an Postgres anzupassen. MySQL ist/war auch einfacher zu handhaben als Postgres, weswegen wiederum viele Projekte zuerst auf MySQL aufsetzten und erst später dann Postgres-Support bekamen. Grundsätzlich spricht nichts dagegen. S° -- Sven Hartge -- professioneller Unix-Geek Meine Gedanken im Netz: http://sven.formvision.de/blog/ -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
LAPP statt LAMP?
Moin, zusammn, dem Wort nach ist LAMP wohl sehr bekannt ... spricht eigentlich etwas gegen PostgreSQL statt MySQL? Oder anders herum: Warum eigentlich unbedingt MySQL statt Post? Historisch bedingt? Gruß, Raimund
