Trigger

[Rehan2112]

Hallo zusammen, Ich bin neu hier. Habe eine Frage zu MySQL Trigger. Ich habe eine MySQL Datenbank in die Datensätze von verschiedenen Mitgliedern laufen. Nun möchte ich das jeder Datensatz eines bestimmten Mitglieds in eine eigene Tabelle laufen. Ist das möglich und wie geh ich am besten vor. Vielen Dank für Eure Hilfe

 

[akretschmer]

Das ist prinzipiell gesehen eine strunzdoofe Idee, weil Du mit jedem neuen Mitglied eine neue Tabelle erstellen müßtest. Dementsprechend dann auch alle Abfragen ändern etc.

Evtl. geht die Antwort auf Deine Frage eher in Richtung Partitionierung, aber da müßte man mal wissen, welches Problem Du zu lösen versuchst.

 

[akretschmer]

Aber um Dir dennoch eine elegante Lösung zu zeigen, allerdings mit PostgreSQL:

postgres=# create table verein (name text) partition by list (name);
CREATE TABLE
postgres=# create table verein__p1 partition of verein for values in ('Hans');
CREATE TABLE
postgres=# create table verein__p2 partition of verein for values in ('Max');
CREATE TABLE
postgres=# create table verein__p3 partition of verein for values in ('Otto');
CREATE TABLE
postgres=# insert into verein values ('Hans');
INSERT 0 1
postgres=# insert into verein values ('Max');
INSERT 0 1
postgres=# insert into verein values ('Otto');
INSERT 0 1
postgres=# select * from verein;
 name 
------
 Hans
 Max
 Otto
(3 rows)

postgres=# select * from only verein;
 name 
------
(0 rows)

postgres=# select * from verein__p1;
 name 
------
 Hans
(1 row)

postgres=# select * from verein__p2;
 name 
------
 Max
(1 row)

postgres=# select * from verein__p3;
 name 
------
 Otto
(1 row)

postgres=#

Problematisch wird es nur, wenn die Partition nicht existiert:

postgres=# insert into verein values ('Susi');
ERROR:  no partition of relation "verein" found for row
DETAIL:  Partition key of the failing row contains (name) = (Susi).
postgres=#

Das könnte man mit einer Default-Partition lösen, in die alles geht, was als Partition nicht definiert ist. Erspare ich mir jetzt aber mal.
Ob MySQL das kann weiß ich nicht.

Und: sowas macht man nicht ohne guten Grund. Der Grund, warum Du sowas willst, ist noch immer unbekannt.

 

[Rehan2112]

Vielen Dank für die Antwort. Ich Probier das mal aus.

 

[akretschmer]

Vielen Dank für die Antwort. Ich Probier das mal aus.

Nett. Aber keine Antwort auf meine Fragen. Egal, viel Erfolg!

 

[ukulele]

Befasse dich mit Relationalen Datenbanken und Normalisierung und du wirst erkennen das entweder deine Idee falsch ist oder das du keine Relationale Datenbank brauchst sondern eher eine Datei pro Mitglied.

 

[Rehan2112]

Ja, ich glaube mein Ansatz ist falsch, wie bekomme ich hin das wenn ein Benutzer einen Eintag per Formular macht dieser in die Tabelle desjenigen Benutzers eingetragen wird. Aber das ist wahrscheinlich eher was für ein php Forum. Ich bin halt Anfänger.

 

[akretschmer]

Noch einmal: der Gedanke, je Benutzer eine Tabelle haben zu wollen oder müssen ist mit an Sicherheit grenzender Wahrscheinlichkeit Bullshit.
Welches Problem willst Du mit Tabelle je Nutzer lösen, welches Du bei einer Tabelle für alle Nutzer hättest?

 

[ukulele]

Die Idee ist nicht eine Tabelle pro Nutzer sondern grundsätzlich eine Spalte für die Beziehung zum Nutzer, genannt Fremdschlüssel. Du wirst diese absoluten Grundlagen lernen müssen ansonsten baust du nur Blödsinn zusammen.

 

[dabadepdu]

Der Nutzer ist nicht ein Parent Objekt einer Tabelle, sondern ein Attribut, ein Teil der verwalteten Daten. Auf Deutsch:
Es gibt eine Spalte "benutzer" oder eine Referenz(eine ID), die auf einen Nutzer in einer Nutzertabelle zeigt.

Zur Abfrage/Anzeige im Web wird diese Nutzer ID mitgeführt und muss entsprechend gefiltert werden, falls ein Nutzer nur seine eigenen Daten sehen soll.

Im großen Stil ist es ein Mandant. Das wird meist anders umgesetzt. Wenn eine komplette Anwendung 1:1 identisch für verschiedene Kunden betrieben wird, dann in verschiedenen Datenbanken oder in verschiedenen Schemata, sofern die DB das kann.

 

[akretschmer]

Im großen Stil ist es ein Mandant. Das wird meist anders umgesetzt. Wenn eine komplette Anwendung 1:1 identisch für verschiedene Kunden betrieben wird, dann in verschiedenen Datenbanken oder in verschiedenen Schemata, sofern die DB das kann.

Ginge auch dann alles in einer Tabelle mit Rechtetrennung via RLS (Row Level Security). Natürlich nur, wenn die DB das kann.

 

[dabadepdu]

Ginge auch dann alles in einer Tabelle mit Rechtetrennung via RLS (Row Level Security). Natürlich nur, wenn die DB das kann.

Ja, das gleiche Prinzip könnte verwendet werden. Ist aber vielleicht nicht die Kragenweite/vordringliches Problem des TE.

 

[akretschmer]

Exakt, daher auch meine bisher unbeantwortete Frage in #2