MySQL 5.5, aus Trigger aufs Dateisystem zugreifen

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

gibt es eine Möglichkeit, aus einem MySQL Trigger oder einer Stored Routine auf das Dateisystem zuzugreifen? Ich möchte Files erstellen und/oder beim Delete-Trigger auch löschen.

Ist dann nur die Frage, wie man den User (Owner des Files) festlegt.

Alternativ könnte man auch auf ein Skript zugreifen, das unter dem passenden User läuft und den Dateinamen als Parameter aufnimmt. Das muss dann allerdings selber wieder gut gesichert liegen, dass es nur vom Datenbankbenutzer benutzt werden kann.

Leider weiß ich nicht, wie das geht und wo ich was darüber finden kann.

Spirituelle Grüße
Euer Robert

[dedlfix]

Tach!

gibt es eine Möglichkeit, aus einem MySQL Trigger oder einer Stored Routine auf das Dateisystem zuzugreifen? Ich möchte Files erstellen und/oder beim Delete-Trigger auch löschen.

Geht meines Wissens nicht. Das einzige mit Dateien ist SELECT ... INTO OUTFILE/DUMPFILE und LOAD DATA INFILE. Löschen geht gar nicht.

Ist dann nur die Frage, wie man den User (Owner des Files) festlegt.

Nur root kann das unter Unix. Andere Nutzer dürfen keine Dateien verschenken.

Alternativ könnte man auch auf ein Skript zugreifen, das unter dem passenden User läuft und den Dateinamen als Parameter aufnimmt.

Auch das gibts nicht.

Leider weiß ich nicht, wie das geht und wo ich was darüber finden kann.

Im MySQL-Handbuch, in den Kapiteln zur Statement-Syntax und den Funktionen. Da glänzen solche Dinge durch Abwesenheit.

dedlfix.

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

Leider weiß ich nicht, wie das geht und wo ich was darüber finden kann.

Im MySQL-Handbuch, in den Kapiteln zur Statement-Syntax und den Funktionen. Da glänzen solche Dinge durch Abwesenheit.

Ja leider. Habe ich alles durchgeblättert nach einer Idee. Schade. Das wäre eien gutes Feature für Webdatenbanksysteme.

Spirituelle Grüße
Euer Robert

[dedlfix]

Tach!

Leider weiß ich nicht, wie das geht und wo ich was darüber finden kann.
Im MySQL-Handbuch, in den Kapiteln zur Statement-Syntax und den Funktionen. Da glänzen solche Dinge durch Abwesenheit.
Ja leider. Habe ich alles durchgeblättert nach einer Idee. Schade. Das wäre eien gutes Feature für Webdatenbanksysteme.

Find ich nicht. Eine Datenbank ist kein Dateiverwaltungssystem. Wenn du Daten speichern willst, dann kannst du das in ihr drin machen. Die BLOB-Datentypen sind für Binärkrams vorgesehen.

dedlfix.

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

Leider weiß ich nicht, wie das geht und wo ich was darüber finden kann.
Im MySQL-Handbuch, in den Kapiteln zur Statement-Syntax und den Funktionen. Da glänzen solche Dinge durch Abwesenheit.
Ja leider. Habe ich alles durchgeblättert nach einer Idee. Schade. Das wäre eien gutes Feature für Webdatenbanksysteme.

Find ich nicht. Eine Datenbank ist kein Dateiverwaltungssystem. Wenn du Daten speichern willst, dann kannst du das in ihr drin machen. Die BLOB-Datentypen sind für Binärkrams vorgesehen.

So ändern sich die Zeiten. 20 Jahre lang wird man konditioniert, dass z.B. Bilder (2MB und größer) nicht in die Datenbank gehören, und dann kommt hier im Forum jemand, und behauptet glatt das Gegenteil. Du bist mir hoffentlich nicht böse, wenn ich jetzt mal verwunderte Kopf- und Augenbewegungen mache?

Ich hatte hier im Archiv vorhin erst dutzende Threads gefunden, die förmlich mit Steinen schmissen, weil jemand fragte, wie man Bilder in der Datenbank speichern könne.

Spirituelle Grüße
Euer Robert

[hotti]

hi,

Ich hatte hier im Archiv vorhin erst dutzende Threads gefunden, die förmlich mit Steinen schmissen, weil jemand fragte, wie man Bilder in der Datenbank speichern könne.

Eine Datenabstraktion kennt keine Grenzen ;)

Wie wärs mit Lazy-Load? Alle Daten eines User-Profiles bilden einen Hash (Perl):

  
   my $user_object = tie my %user_data, 'User'; # Binde den Hash %user_data an class 'User'  

Und jetzt kommt der Hack mit Lazy-Load: Der Hash ist leer zum Zeitpunkt des Binden an die Klasse! Erst wenn ein Key befragt wird, z.B.:

  
   my $img = $user_data{portrait};  
   # oder  
   my $name =$user_data{name};  

läuft im Hintergrund eine Methode (FETCH) welche die Daten aus einer DB oder aus dem FS beschafft. Ganz wie von Zauberhand bewegt ;)

Und das Objekt? Das brauchen wir z.B. hier:

  
   $user_object->write; # Änderungen speichern  

Die gute Nachricht: Das geht auch mit PHP.

Gute Nacht ;)

[1UnitedPower]

Hakuna matata!

So ändern sich die Zeiten. 20 Jahre lang wird man konditioniert, dass z.B. Bilder (2MB und größer) nicht in die Datenbank gehören, und dann kommt hier im Forum jemand, und behauptet glatt das Gegenteil. Du bist mir hoffentlich nicht böse, wenn ich jetzt mal verwunderte Kopf- und Augenbewegungen mache?

Stumpfe Konditionierung bringt uns nicht weiter, man muss sich mit der Diskussion befassen, die Pro- und Kontraargumente verstehen, um in einer Situation die passende Entscheidung zu treffen.

Welches Problem stellt sich dir eigentlich? Versuche das mal frei von Lösungsideen zu formulieren. Hängt es mit deinem Problem der leeren Dateipfade zusammen?

[dedlfix]

Tach!

So ändern sich die Zeiten. 20 Jahre lang wird man konditioniert, dass z.B. Bilder (2MB und größer) nicht in die Datenbank gehören, und dann kommt hier im Forum jemand, und behauptet glatt das Gegenteil.

Vielleicht sollte ich meine Standard-Einschränkung noch erwähnen: Es kommt auf den Anwendungsfall und die individuellen Gegebenheiten an.

Es hat sicher ein paar Eigenschaften, die im allgeimeinen negativ sind, aber auch welche, die sehr vorteilhaft sind. BLOBs können im Gegensatz zu separat gespeicherten Dateien weder verwaisen (wenn Fremdschlüssel ordentlich gepflegt werden) noch abhandenkommen. Das erkauft man sich mit Mehraufwand den das DBMS hat, aber man spart sich wiederum eigenen Mehraufwand an anderer Stelle. Plattenplatz spart man in keinem Fall. Bewerte die Eigenschaften in Bezug auf deine Anwendung und deine System, statt unhinterfragt 20 Jahre alte Argumente herunterzubeten.

dedlfix.

[Auge]

Hallo

Find ich nicht. Eine Datenbank ist kein Dateiverwaltungssystem. Wenn du Daten speichern willst, dann kannst du das in ihr drin machen. Die BLOB-Datentypen sind für Binärkrams vorgesehen.

So ändern sich die Zeiten. 20 Jahre lang wird man konditioniert, dass z.B. Bilder (2MB und größer) nicht in die Datenbank gehören, und dann kommt hier im Forum jemand, und behauptet glatt das Gegenteil. Du bist mir hoffentlich nicht böse, wenn ich jetzt mal verwunderte Kopf- und Augenbewegungen mache?

Ich hatte hier im Archiv vorhin erst dutzende Threads gefunden, die förmlich mit Steinen schmissen, weil jemand fragte, wie man Bilder in der Datenbank speichern könne.

Da ich mich mehrfach an solchen Diskussionen beteiligt habe, möchte ich mich auch hier kurz zu Wort melden.

Steine wurden, zumindest von mir, dann auf das Vorhaben geworfen, wenn es dem Fragesteller darum ging, etwas zu tun, was mit dem Dateisystem besser und schneller ginge. Oft bestand das Anliegen darin, Uploads in der Datenbank statt im Dateisystem zu speichern, um in der Datenbank eine Verknüpfung zwischen dem Upload selbst und einem Datensatz oder Datensätzen herstellen zu können. An dieser Stelle habe ich die Speicherung des Uploads im Dateissystem zuzüglich der Bekanntmachung dieses Vorgangs in der DB propagiert. Die beziehung lässt sich so genausogut herstellen. Die von dedlfix genannten Vorteile sind davon unbelassen.

So weit ich mich erinnere, waren die meisten Anfragen zu dem Thema so oder so ähnlich gelagert. Und ja, in solchen Fällen ist das Speichern der Binärdaten nicht zielführend. Für andere Fälle sieht das halt anders aus. Den Datentyp BLOB für Binärdaten gibt es ja nicht umsonst.

Tschö, Auge