On Mon, 10 Nov 2003 05:53:51 +0100 "Arndt Stedler" wrote:

Oh, seit neuestem scheinbar schon: - Starting with version 4.1, MySQL supports all subquery forms and - operations which the SQL standard requires, as well as a few - features which are MySQL-specific. Ich muss mir (und dem Kunden) aber erst mal die neueste Version unterjubeln;-)

Dem wäre eher davon abzuraten, 4.1 ist erst in einer Alpha-Version verfügbar - würd ich also besser nicht in einer produktiven Umgebung einsetzen. Hmm, die freie und auch nicht schlechte PostgreSQL-DB dürfte mit solcherlei SubSelects keine Probleme haben, ansonsten bleibt dir nur der Umweg über die Joins.

Am Montag, 10. November 2003 15:40 schrieb Arndt Stedler: [lässt Du bitte die Vorredner leben? Sonst weiss man nicht mehr, wer was geschrieben hat] [...] [Frank Wehrsenger]

...

Hmm, die freie und auch nicht schlechte PostgreSQL-DB dürfte mit solcherlei SubSelects keine Probleme haben, ansonsten bleibt dir nur der Umweg über die Joins.

Ich denke, ich bleib' erstmal bei MySQL, denn eigentlich finde ich die Klasse. Noch kann sie zwar nicht alles, wird aber immer besser und zudem ist sie schnell und Platfomunabhängig. Auch wenn ich derzeit ein paar JOIN - Klimmzüge absolvieren muss ;-) bin ich doch sehr zufrieden.

Ich würde Dir auch raten, sich mal PostgreSQL anzuschauen. Wenn Du einmal mit den Möglichkeiten vertraut bist (ich bin z. B. ein Fan von Triggern und Stored Procedures - man kann sich damit das Leben auf der Anwendungsseite sehr erleichtern ;), willst Du nicht mehr zurück. Jan BTW: Die mysql-Firma vertreibt ja in Zukunft auch SAP-DB (ex. ADABAS) - auch die ist einen Blick wert (steht unter (L)GPL) - wenn Du von DB/2 kommst, schätzt Du vielleicht die Möglichkeit, dass man SAP-DB in verschiedenen SQL-Dialekten betreiben kann (u. a. eben auch DB/2, Informix, Oracle).

Hallo, Am Mon, 10 Nov 2003, Al Bogner schrieb:

mehr oder weniger vollzogen. Das GUI-Frontend bzw. die Masken müssen noch erstellt werden, und ich weiß noch immer nicht, womit ich das mit möglichst wenig Aufwand mache. Mit wxpython? Tk? Knoda ist für mich nur suboptimal. Ich war erstaunt, wie gut man MySQL mit Shellscripts (here) steuern kann.

*g* Da wuerde ich mir mal php, perl mit DBI (z.B. als CGI, oder mit perl/Tk, perl/Gtk oder perl/QT fuer die UI) oder sowas anschauen, zumindest wenn's ne "eigene" angepasste UI sein soll. Achso, u.U. auch was mit *dialog, kommt halt darauf an, wie komplex deine UI werden soll. Oder auch OOo / StarOffice... -dnh PS: knoda kenne ich immer noch nicht ;) -- 6.9 is a good thing interupted by a period.

Am Dienstag, 11. November 2003 00:10 schrieb Al Bogner: [...]

Ich will eigentlich gar nicht so viel. Aber, ich will das UI nicht per Browser realisieren. Bei Verlassen eines Feldes soll die Änderung in der DB erfolgen und nicht erst, wenn ich mit einem "Knopf" die Datenübernahme in die DB befehle. Einen Trigger werde ich am

Hast Du Dir das auch richtig überlegt? Du vervielfachst den Traffic im Netz und die Belastung des DB-Servers und bringst Deine Daten in Gefahr. Beispiel1: Kunde *Ich_zock_Dich_ab_AG*; Kreditlimit alt 1.000,-, neu 100.000,-; <ENTER> - *ups*, sollte ja 100,00 heissen; zurück. In der Zwischenzeit hat der Kunde erfolgreich Deine Firma gekauft. Beispiel2: Abhängigkeiten zwischen Feldern - Wenn älter als 18 Jahre, dann *Hardcore*-Checkbox aktivieren. Jetzt ändere bei aktiviertem *Hardcore*-Feld das Alter auf 16 - entweder brüllt die DB (ach ne - das kann mysql ja eh nicht ;) oder aber Du hast gerade gegen das Jugenschutzgesetz verstoßen und morgen steht die Polizei vor Deiner Tür ;) Willst Du sowas alles in der Anwendung abfangen? Bei _jedem_ relevanten Feld? Jedesmal mit DB-Insert / -Update? Auch wenn es unbequemer ist: - Eingaben - Client-seitige Verifizerung der Eingaben - Übergabe an DB - (bei mysql eher zu vernachlässigende ;) DB-seitige Verifizierung - Resultat anzeigen - der Benutzer will ja schliesslich wissen, obs geklappt hat

DB-Frontend wohl haben wollen, d.h. bei Verlassen eines Feldes, soll ein Shellscript oder was immer ausgeführt werden. Die

Hast Du Dir mal Gedanken über die Performance gemacht, wenn Du bei jedem Klick Scripts ablaufen lässt?

David, nachdem du mich etwas kennst, was würdest du vorschlagen?

Hast du zufällig Links zu _DB-Beispielen_ für perl/Tk, perl/Gtk oder perl/QT zur Hand?

Wenn ich mich mal in das traute Zwiegespräch einmischen darf ... Wenn es Dir erstmal um das Handling des DB-Zugriffs geht, kannst Du von mir ein paar perl-DBI-Schnipsel haben (wobei ich nicht so recht glauben mag, dass es da keine Beispiele z. B. auf cpan.org gibt). Da ist aber keine GUI-Programmierung drin. Im Linux-Magazin gab es auch schon des öfteren ausführliche Artikel (Perl-Snapshot) zu diesem Thema. Jan

Am Mittwoch, 12. November 2003 00:08 schrieb Al Bogner: [...]

Der Traffic im lokalen Netz ist mir total egal. Dem Netz ist sowieso meist langweilig. Denk an ein Small-Office-Büro mit ein paar kleinen Datenbanken von ein paar tausenden Datensätzen und dann gibt es noch ein paar größere DBs von vielleicht 10-20MB. Also keine wirkliche Herausforderung für eine DB. [...] Bei _jedem_ Klick muß ja ein Script nicht ablaufen. Ich denke da zB an die Übertragung der Daten ins Handy. Mysql braucht dafür selber 1(?) Sekunde und das Schreiben ins Handy für alle Bereiche dauert ca. 1 Minute. Es ist vollkommen egal, ob zu dieser Zeit von jemand anderem eine neue Adress eingegeben wird oder nicht. Die Eingabe der Kriterien zur Übertragung erfolgt durch den, dem das Handy gehört.

Damit ist aber immer noch nicht die Konsistenz der Daten gewährleistet - zu dem Zeitpunkt, an dem die DB die Daten abholt, können sie ja gerade von einem anderen Nutzer korrumpiert worden sein.

Ich experimentiere mit ca. 20.000 Datensätzen und wundere mich, was ich da für "Unfug" anstellen kann, ohne dass die Performance leidet. Alles was in ein paar Sekunden erledigt ist, ist ok. Bitte denke daran, hier geht es um eine DB-Migration im kleinen Bereich und entscheidend ist mal, dass all das gemacht werden kann, was bis jetzt schon immer funktionierte. Einerseits gibt es das optimale DB-Design, worüber man viel nachdenken muß und andererseits muß sich natürlich auch der Aufwand dafür rechtfertigen. IMO ist es wichtig zu wissen, dass man einen Kompromiß eingegangen ist.

Nicht skalier- / erweiterbar by Design - IMHO eine kurzsichtige Herangehensweise, aber das ist Deine Sache. Ich habe die Erfahrung gemacht, dass in jeder Anwendung, die eine Multiuser-Datenbank benutzt, das DB-Design der Punkt ist, worüber man am längsten und zuerst nachdenken sollte. Jede nachträgliche Änderung potenziert den Aufwand. Jan P.S.: Script ist unterwegs.

Am Mittwoch, 12. November 2003 20:51 schrieb Al Bogner:

Am Mittwoch, 12. November 2003 02:04 schrieb Jan Trippler:

...

Damit ist aber immer noch nicht die Konsistenz der Daten gewährleistet - zu dem Zeitpunkt, an dem die DB die Daten abholt, können sie ja gerade von einem anderen Nutzer korrumpiert worden sein.

Sorry, das verstehe ich nicht. Was meinst du mit korrumpiert? Ist ein "LOCK TABLE" für eine Sekunde zu empfehlen? Wenn du Lust hast, dann schick ich dir mein Shellscript mit mysql-Abfragen zur Übertragung ins Handy um zu beurteilen, ob dafür PostgreSQL unbedingt zu empfehlen wäre. Entscheidend ist, dass das Script das (quick and dirty) kann, was ich brauche. Mit gscmxx komme ich nicht so weit.

LOCK TABLE? Nicht zu empfehlen. Sowas sollte man nur dann machen, wenn man Wartungsarbeiten macht, nie im Betrieb - du sperrst ja alle User aus! Nein, was ich damit meinte: So wie Du es vorhast (wenn ich Dich richtig verstanden habe), willst Du Daten nach dem Verlassen der Felder in die DB schreiben. Damit kommst Du aber in Situationen, dass z. B. die Postleitzahl einer Adresse geändert ist, die Strasse aber noch nicht - schwupps hast Du fehlerhafte Daten, wenn in dieser Zeit gerade von einem anderen User die Daten geholt werden. Dein Script zu schicken ist nicht so sinnvoll zur Zeit - ich schaffs ja nicht mal, meine eigenen Projekte weiterzutreiben :( Stress

...

Nicht skalier- / erweiterbar by Design - IMHO eine kurzsichtige Herangehensweise, aber das ist Deine Sache.

Das sehe ich nicht so. Du kannst aber auch meine DB nicht kennen.

Jau, deshalb steht auch IMHO da ;)

PS: Dein PM mit den Scripts ist noch nicht angekommen.

Ich habs gestern nicht mehr gemacht, weil die aktuelle Version auf nem anderen Rechner lag (der gerade nicht verfügbar war). Ist aber vorhin raus.

Hallo, Am Tue, 11 Nov 2003, Al Bogner schrieb:

Am Montag, 10. November 2003 22:52 schrieb David Haller:

...

...

mehr oder weniger vollzogen. Das GUI-Frontend bzw. die Masken müssen noch erstellt werden, und ich weiß noch immer nicht, womit ich das mit möglichst wenig Aufwand mache. Mit wxpython? Tk? Knoda ist für mich nur suboptimal. Ich war erstaunt, wie gut man MySQL mit Shellscripts (here) steuern kann. [..] Da wuerde ich mir mal php, perl mit DBI (z.B. als CGI, oder mit

Am Mon, 10 Nov 2003, Al Bogner schrieb: perl/Tk, perl/Gtk oder perl/QT fuer die UI) oder sowas anschauen, zumindest wenn's ne "eigene" angepasste UI sein soll. Achso, u.U. auch was mit *dialog, kommt halt darauf an, wie komplex deine UI werden soll. Oder auch OOo / StarOffice...

Ich will eigentlich gar nicht so viel. Aber, ich will das UI nicht per Browser realisieren. Bei Verlassen eines Feldes soll die Änderung in der DB erfolgen und nicht erst, wenn ich mit einem "Knopf" die Datenübernahme in die DB befehle.

Siehe dazu Jan's Antwort. Das ist keine gute Idee. Was man machen kann (zumindest in Perl/Tk[1]), ist die _Eingabe_ gleich zu pruefen.

Einen Trigger werde ich am DB-Frontend wohl haben wollen, d.h. bei Verlassen eines Feldes, soll ein Shellscript oder was immer ausgeführt werden.

Das geht besser ueber "callback-Funktionen", egal mit was du das umsetzt (ausser OOo / SO).

Die Masken/Formulare will ich mit der Maus "zeichnen" können und dabei sollte es einen "magnetischen Raster" geben.

Das wird schwierig. Da kenne ich auch nix (ausser SO/OOo und Access).

OO ist auch irgendwie eine Notlösung. Bei Knoda gefällt mir u.a. der Einstieg nicht bzw. habe ich noch nicht herausgefunden, wie ich eine DB direkt starte. Außerdem ist Knoda manchmal langsam.

David, nachdem du mich etwas kennst, was würdest du vorschlagen?

Kommt darauf an, wie "vielfaeltig" deinen UIs sein muessen und was du genau machen willst... Da ich perl/Tk kenne beziehe ich mich mal darauf... Wenn die UI keine besonderen Layoutanforderungen hat, dann kannst du die Details auch per Schleife oder so "ausfuellen", d.h. die UI "generieren" lassen. Das ist dann aber nicht mehr "trivial"...

Hast du zufällig Links zu _DB-Beispielen_ für perl/Tk, perl/Gtk oder perl/QT zur Hand?

Nein. Aber ich hab mal ein paar Fetzen aus diversen scripten zusammengeschmissen und ein (sehr einfaches) Beispiel zur Dateneingabe in perl/Tk gebastelt (siehe unten). Das Beispiel ist wirklich "Quick & very very Dirty" und soll nur illustrieren, wie relativ einfach man so eine UI stricken kann... Damit das Beispiel funktioniert, muss man nur die DB und den User anlegen. Achso: eine Pruefung auf "Uniqueness" der Daten ist bisher nicht drin, das macht man besser durch eine passende Definition der DB-Tabelle(n), die Fehlermeldung(en) ("duplicate entry") kann man leicht abfangen, behandeln usw. Vorhandene Datensaetze kann man natuerlich auch bearbeiten, das wird dann aber etwas aufwaendiger[2], das wuerde das "Minimalbeispiel" sprengen ;) Dank DBI beschraenkt sich eine Umsetzung auf PostgreSQL auf ein Anpassen der DSN und der SQL-Statements[3], die UI mit perl/Gtk oder perl/QT wird aehnlich gebaut (in Abhaengigkeit vom Toolkit natuerlich). Du hast also, je nach Toolkit, verschiedene "Widgets" und "Layout-Moeglichkeiten"... Das ganze soll dir erstmal nur ne Idee davon geben, wie sowas "Perl/Tk + DBI" aussehen koennte ;) HTH, -dnh [1] ich hab hier ein script wo ich in einem Eingabefeld mache ;) [2] Listbox, auswaehlen, bearbeiten, update + Fehlerbehandlung... [3] die man dann in einem echten script besser z.B. in einem hash gesammelt hinterlegt und nicht direkt im code ;) ==== ./test_perl_tk_DBI.pl [schreibweise komprimiert] ==== #! /usr/bin/perl -w use strict; use Tk; use DBD::mysql; my $db = "tktest"; my $table = "TKTest"; my ($dsn, $user, $pass ) = ( "dbi:mysql:database=$db", "tkuser", "test"); my ($dbh, %uidata, $mw); # db-handle, data from UI, main window sub db_connect { $dbh = DBI->connect($dsn, $user, $pass, { RaiseError => 1 } ) or die "Cannot connect to database"; } sub db_disconnect { return $dbh->disconnect(); } sub _db_create_table { my $sth = $dbh->prepare("SHOW TABLES FROM $db;"); if (!$sth->execute) { die "Error:" . $sth->errstr . "\n"; } while ( @_ = $sth->fetchrow_array() ) { if( $_[0] =~ /$table/ ) { $sth->finish(); return; } }; $sth->finish(); $sth = $dbh->prepare("CREATE TABLE $table ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, name VARCHAR(255) NOT NULL, tel VARCHAR(50), PRIMARY KEY (id))" ); if (!$sth->execute) { die "Error:" . $sth->errstr . "\n"; } $sth->finish(); } sub db_add_entry { # first validate data if( $uidata{'name'} !~ /\w+/ ) { $mw->messageBox( -message => "invalid name Entry", -type => 'OK' ); return; } if( $uidata{'tel'} && $uidata{'tel'} !~ /[\d+()-]+/ ) { $mw->messageBox( -message => "invalid Tel Entry", -type => 'OK' ); return; } # then commit data my $s = "INSERT INTO $table SET name=" . $dbh->quote($uidata{'name'}) . ", tel=" . $dbh->quote($uidata{'tel'} ? $uidata{'tel'} : "NULL") . ";"; my $sth = $dbh->prepare($s); if ( ! $sth->execute ) { print STDERR "DBI-Error (", $sth->err, ") : ", $sth->errstr, " in table $table.\n"; } $sth->finish(); $mw->messageBox( -message => "Entry added", -type => 'OK' ); } sub ui_close { db_disconnect() or die; exit 0; } sub ui_generate { $mw = new MainWindow(); $mw->Label( -text => "TkTest")->pack; my $f = $mw->Frame->pack; $f->Label( -text => "Name: ")-> grid( -row => 0, -column => 0); $f->Entry( -textvariable => \$uidata{'name'} )->grid( -row => 0, -column => 1); $f->Label( -text => "Tel: ")->grid( -row => 1, -column => 0); $f->Entry( -textvariable => \$uidata{'tel'} )->grid( -row => 1, -column => 1); $f->pack(); $mw->Button( -text => "Add", -command => \&db_add_entry)->pack; $mw->Button( -text => "Quit", -command => \&ui_close)->pack; } db_connect(); _db_create_table(); ui_generate(); Tk::MainLoop(); db_disconnect(); ==== -- There are three stages to sex in a person's life: Tri Weekly, Try Weekly, and Try Weakly

Am Montag, 10. November 2003 21:37 schrieb Al Bogner: [...]

Gibt es eine Alternative für "if" unter PostgreSQL? Trigger und Stored Procedures werden bei MySQL auch kommen. Mal sehen, ob ich bald mit MySQL anstehe und zu PostgreSQL migriere.

Ein IF in SQL? Huch? SQL ist eine _Query-Language_, keine Programmiersprache. Ein if gibts in PostgreSQL - da wo es hingehört: In die Procedure Language. Ich hab mir die Seite, die Du genannt hast, mal angeschaut - hm, naja. Einige Sachen stimmen IMHO einfach nicht, andere sind etwas - ähm, einseitig - dargestellt. Ein paar Beispiele (ich gehe von der PostgreSQL-7.2 Doku aus, die ich hier habe, ich nehme an, dass die als Vergleich herangezogene 7.3 nicht weniger hat): - da steht unter *other types*: Datentyp byte gibts bei beiden nicht - der Datentyp heisst unter PG bytea, er existiert. - der Typ *double* findet sich in mysql, in PG nicht. Logo - da heisst er nämlich *double precision* - der taucht aber nicht auf. - Typ *text* existiert angeblich nicht unter PG - Lüge. - Die Funktion concat existiert nicht in PG - stimmt! Der Standard definiert nämlich || als String-Verkettung - daraus folgt gleich nochwas: || als *OR*-Ersatz gibt es demzufolge nicht. - kleine Sachen: Keyword VIEW ex. angeblich nicht, ein paar Absätze oben wird aber (korrekt) erwähnt, dass *CREATE VIEW* existiert. Keyword *trigger* gibts angeblich auch nicht - komisch: Wieso funktioniert dann die *create trigger* Anweisung? - *Alter table modify column* geht nicht in PG. Stimmt. Heisst "alter table alter column* - taucht aber nicht auf. - *Case insensitive compare* geht nach der Seite nicht - Schwindel. Dafür gibts nen ganzen Sack von Möglichkeiten (ilike, regular expressions). - Funktion *Function SUBSTRING as MID* geht nicht - häh? substring('einszweidrei' from 5 for 4) liefert 'zwei'. - Funktion *regexp in select* geht ja auch nicht - wir nehmen da nämlich einfach reguläre Ausdrücke (z. B. in like). Um es mal vorsichtig auszudrücken: Dieser Vergleich erscheint mir nicht ganz unparteiisch. Wenn ich bei solchen Vergleichen von den mysql-Funktionen, Datentypen, ... ausgehe, dann fällt natürlich in jedem Bereich ausser dem ANSI-Standard dieser Vergleich zu Gunsten von mysql aus. Dabei wird oft einfach ignoriert, dass viele Funktionalitäten mit anderen (nicht genannten) Funktionen realisiert wurden. Das ganze Datum- / Zeithandling z .B. läuft in PostgreSQL ganz einfach über Operatoren (+, -, *, /) - da brauche ich gar keine Funktionen! Das Thema Procedures würde mysql ziemlich blöd dastehen lassen, weil Du da in PG fast beliebig Programmiersprachen einbinden kannst und so deren gesamten Funktionsumfang nutzen kannst. Ich will noch hinzufügen, dass ich nicht mysql in Grund und Boden verdamme - ich halte das Produkt für durchaus geeignet bei bestimmten Anwendungen. Ich würde es nur begrüßen, wenn man _vor_ dem Einsatz mal gründlicher nachdenken würde und nicht gleich *mysql, weil - das nehmen sie alle* brüllen würde. Für DB-Anwendungen mit höheren Ansprüchen an die Qualität des DB-Designs (z. B. kaufmännische Anwendungen) halte ich (fast) jede andere SQL-DB für besser geeignet. Jan P.S.: *umpf* jedes Mal bei diesem Thema gehen die Gäule mit mir durch ;) Dabei haben die anderen DBMS in der Regel eine lange Zeit an Produktreife hinter sich, mysql eher nicht.

Am Dienstag, 11. November 2003 23:42 schrieb Al Bogner: [IF im select]

Für einen schnellen Textexport finde ich das zb ganz praktisch. Ich habe mir zB ein Script gemacht, das die Daten aus der mysql-db so exportiert, dass ich diese per Shell-Script in das Telefon-, Adressbuch bzw. Kalender diverser Handys importieren kann. Die DB enthält dazu ein Feld "Tel-Nr. unterdrücken j/n). Mit "if" im select-Befehl kann ich nun direkt angeben, ob ich vor der Nr. #31# haben will und brauche dafür kein externes Programm. Solche simplen if-statements brauche ich hier relativ oft.

select name, '#31#' || telno from adresse where telno_unterduecken = 'j' union select name, telno from adresse where telno_unterdruecken = 'n' order by 1; (oder umgekehrt ;) SQL kann mehr, als die meisten glauben.

Hier ist die Situation so: Beim Recherchieren kam klar heraus, dass ich in der Theorie PG besser fand. In der Praxis scheiterte ich dann aber schon am Textimport.

Im Nachhinein ist mir klar, dass da PG nichts dafür konnte und auch bei mysql klappte es anfangs nicht und zwar nicht aus Syntax-Problemen, sondern weil ich spezielle Zeichen im Text hatte. PhpMyAdmin mag die Daten noch immer nicht, aber mittlerweile komme ich auch mit der Kommandozeile klar. Anfangs steht man da ziemlich an, wenn man nicht importieren kann und eine DB zu migrieren ist.

Naja, dann wäre aber psql einen zweiten Blick wert gewesen - PostgreSQL kann auch Daten per Script importieren. Wenn man einen Fehler hat, sollte man doch erstmal die Ursachen erforschen und _dann_ entscheiden, ob es an der Software oder an den Daten liegt.

So bin ich nun mal bei MySQL gestrandet, weil ich einfach mal das realisieren konnte, das ich brauchte. Ob es gut gelöst ist, steht fürs erste nicht zur Diskussion, entscheidend ist, dass das funktioniert, was ich brauche.

Hm - Deine Entscheidung, Dein Projekt. Jan

Am Freitag, 14. November 2003 03:43 schrieb Manfred Tremmel:

Am Dienstag, 11. November 2003 23:42 schrieb Al Bogner:

...

Für einen schnellen Textexport finde ich das zb ganz praktisch. Ich habe mir zB ein Script gemacht, das die Daten aus der mysql-db so exportiert, dass ich diese per Shell-Script in das Telefon-, Adressbuch bzw. Kalender diverser Handys importieren kann. Die DB enthält dazu ein Feld "Tel-Nr. unterdrücken j/n). Mit "if" im select-Befehl kann ich nun direkt angeben, ob ich vor der Nr. #31# haben will und brauche dafür kein externes Programm. Solche simplen if-statements brauche ich hier relativ oft.

Verständlich, kann mir auch nicht vorstellen, wie das ohne if funktionieren soll.

Eine Möglichkeit, das obige Problem mit einem UNION-Select zu lösen, habe ich vor ein paar Tagen hier gepostet.

Bei der Tipprunde von KnightSoft-Net generier ich mir mit einem SQL-Statement die komplette Ligatabelle aus den Spielergebnissen aus vier Datenbanktabellen. Ich seh jetzt ehrlich auch keinen Grund, wieso ich das im Programm machen sollte, wo ich mir Massenweise interne Tabelle aufbaun müsste, das ganze zusammenrechnen, neu sortieren usw.. In dem SQL-Statement sind 67 ifs drin, habs gerade nachgezählt ;-)

Da würden mich mal a) das DB-Design b) das erwartete Ergebnis c) der Select interessieren (natürlich nur, wenn Du das willst - am besten per PM). So wie sich das anhört, wären wohl Trigger + Stored Procedures das Mittel meiner Wahl (dann natürlich - noch - nicht in MySQL ;). Das ist natürlich nur ne Vermutung - ohne Kenntnis von (a) - (c) nur Spekulation. Kann aber ein paar Tage dauern - ich hab nächste Woche 2 lange Bahnfahrten vor mir ;) Jan

Am Montag, 10. November 2003 06:14 schrieb Adolf Kreet:

...

-----Original Message----- From: Jan Trippler [mailto:Jan.Trippler@t-online.de] Sent: Monday, November 10, 2003 2:06 AM To: suse-linux@suse.com Subject: Re: SQL Syntax in MySQL *schauder*

...

P.S.: Steig auf ne richtige Datenbank um ;)

Hi Jan, was heisst denn richtige Datenbank? Da käme doch wohl nur Firebird in Frage. Aber deren Rechteverwaltung ist noch längst nicht so ausgefuchst wie bei MySQL. Und ansonsten gibt es doch nur sehr teure Programme. Ab MySQL 4 wird es doch richtig interessant.

PostgreSQL SAP-DB / ADABAS alles (L)GPL Jan