MySQL INSERT-Wert automatisch ersetzen möglich?

[mschrak]

Hallo zusammen,

gibt es eine Möglichkeit, einen mit INSERT in einer bestimmten Spalte eingegebenen Wert genau an dieser Stelle automatisch mit einem korrespondierenden Wert aus einer anderen Tabelle dieser DB zu ersetzen?
Beispiel: Per INSERT übergeben möchte ich einen Namenskürzel-Wert, zB "sme" an spalte 'namenskuerzel' in 'tbl_irgendwas'. Darin stehen soll dann aber der Wert "Meier, Siegfried", der aus der Tabelle 'klarnamen' der DB kommt, die nur die Aufschlüsselung beinhaltet (Spalten also 'kuerzel' als Primärschlüssel und in Spalte 2 'klarname'.

Ich hoffe, ich habe mich verständlich ausgedrückt.
(Hintergrund ist, dass ich einem Nutzer, der SELECT-Rechte auf die Tabelle 'tbl_irgendwas' hat, keinen Zugang zu den Kuerzeln geben möchte.)
Ich weiss, hoert sich widersinnig an, aber ich möchte tatsächlich die Kürzel und nicht die Klarnamen vor dem Zugriff dritter schützen.

Danke schon mal im Voraus,

Martin

 

[benneq]

Meinst du sowas?

INSERT INTO mytable VALUES ('', 42, (SELECT irgendwas FROM woanders))

 

[esb315]

Mir würde da get/set einfallen. Hab ich aber bisher nur OO-Sprachen genutzt. Wäre interessant ob das auch in solchen Aufrufen möglich ist.

 

[mschrak]

@benneq: Vom Ergebnis: Ja, allerdings müsste ich dann ja dem nutzer das Leserecht auf 'woanders' geben, so dass er wieder die kuerzel sehen kann, was ich nicht will. Ich hatte da an eine "automatische Ersetzung innerhalb der DB" gedacht, irgendiwe wie ein Fremdschlüssel...

 

[benneq]

Dann kannst du dir einen Trigger einrichten, der automatisch die Tabelle aktualisiert, wenn eine neuen Zeile eingefügt wird: https://wiki.selfhtml.org/wiki/Datenbank/MySQL_Triggers_und_Stored_Functions

Allerdings versteh ich nicht, was das Ganze bringen soll. Für das INSERT wird doch bereits das Kürzel benötigt, also muss es dem Nutzer bereits bekannt sein

(Ansonsten würde ich solche Restriktionen immer im Application Code lösen und nicht über die Datenbank.)

 

[BiGfReAk]

Du kannst dafür Trigger definieren
https://wiki.selfhtml.org/wiki/Datenbank/MySQL_Triggers_und_Stored_Functions

 

[Andreas_]

Hintergrund ist, dass ich einem Nutzer, der SELECT-Rechte auf die Tabelle 'tbl_irgendwas' hat, keinen Zugang zu den Kuerzeln geben möchte

Da musst Du Dir etwas anderes einfallen lassen. Wenn der User SELECT-Rechte hat, dann könnte er ja sich die Werte nach dem INSERT ansehen.

Typischerweise löst man derartige Zugriffsgeschichten mit Views. Der eingeschränkte Nutzer erhält nur Zugriffsrechte auf eine View, die die entsprechende Spalte nicht enthält.
https://dev.mysql.com/doc/refman/8.0/en/view-syntax.html

 

[Tokolosh]

Bei dir geht es doch um eine Webanwendung, wenn ich das richtig verstanden habe? Wie schon erwähnt ist es nicht unbedingt üblich dort eingeschränkte Rechte zu haben. Typischerweise gibt es einen Datanbankbenutzer, der SELECT, UPDATE, INSERT, DELETE Rechte auf die Datenbank hat. Eben die typischen CRUD-Rechte. Der Rest wird dann aus dem Backend-Code gesteuert.

 

[Andreas_]

Wenn es sich um eine Webanwendung handelt, dann kann ich das Problem des TE nicht nachvollziehen. Schließlich entscheidet er in dem Fall doch welche Daten der User sieht und welche nicht.

Auf Grund der Fragestellung ging ich von Benutzern mit Datenbankzugriff aus ...

 

[parats]

@benneq: Vom Ergebnis: Ja, allerdings müsste ich dann ja dem nutzer das Leserecht auf 'woanders' geben, so dass er wieder die kuerzel sehen kann, was ich nicht will. Ich hatte da an eine "automatische Ersetzung innerhalb der DB" gedacht, irgendiwe wie ein Fremdschlüssel...

Du willst prinzipiell nur den geschlüsselten Wert abspeichern, richtig? Das lässt sich im Zuge des Inserts ja automatisch realisieren, wenn du eine entsprechende Schlüssel-Tabelle per join anbindest.
Zur Anzeige von Daten sollten ausschließlich views verwendet werden, immerhin will man seine physische Struktur durch eine logische Schicht trennen, um bei etwaigen Erweiterungen unabhängig arbeiten zu können.

 

[mschrak]

Nein, es handelt sich (noch) nicht um eine Webanwendung. Insofern war die Annahme mit dem direkten DB Zugriff berechtigt. An eine Webanwendung habe ich mich bislang noch nicht herangetraut.
@parats: Das werde ich tun.