phpbar.de logo

Mailinglisten-Archive

Re: Bilder in Datenbank ablegen
Archiv Mailingliste mysql-de

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bilder in Datenbank ablegen



-----BEGIN PGP SIGNED MESSAGE-----

On Sat, 10 Apr 1999, Matthias Pigulla wrote:
>Oliver Artelt wrote:
>> >Wie willst Du ein SELECT einer Datenbank in einem Proxy speichern?
>> Es ging nur um Images, die als eigenstaendiges Dokument vom HTTP-Server
>> angebeoten werden (Grafik oder Download...).
>Also, wenn Du einen Filenamen in der DB speicherst und in einer
>dynamischen Seite einen Verweis mit IMG SRC machst, bei dem zwar der
>SRC-Wert aus der DB kommt, aber auf eine Datei im FS zeigt.
>
Nein, die Dokumente sollten sich in der DB befinden.

>> Und um die Frage: Sollen die Bilder dann vom FS verwaltet werden
>> (uebrigens interessante These vom 'php-Rasmus': Ein FS stellt ein optimiertes
>> BLOB-Speichersystem dar) oder komplett in der DB belassen. Um die Sache zu
>Ich denke, PHP-Rasmus liegt da richtig, weil ich mir die Datenbank nicht
>so performant wie das FS vorstellen kann. Aus dem FS kann ich (als
>Apache) die Datei so ziehen, in der Datenbank muß ich erstmal einen
>Thread forken, SQL analysieren, Daten lokalisieren.
>
Darueber wurde hier schon geredet...

>Achtung, nicht genauer durchdachter Output, möglicherweise Schwachsinn:
>---
>Wie wäre eine MySQL-Erweiterung: Ein Datentyp "FILENAME", der auf eine
>Datei in einem DMBS-weiten Verzeichnis verweist. MySQL könnte die Datei
>dann löschen, wenn ein entsprechendes Feld gelöscht wird.

>Probleme: Das Verzeichnis sollte möglichst exklusiv von MySQL verwaltet
>werden, muß aber auch Zugriffe z.B. vom Webserver erlauben. Zusätzlich
>könnten wir hier vom Unix-Rechtesystem her Probleme kriegen. Die
>Dateinamen müssten außerdem von MySQL vergeben werden, um in dem Pool
>eine datenbankübergreifende Eindeutigkeit zu gewährleisten. Kurz, die
>BLOBs als eigenen Eintrag im FS sichern, in einer Form, die _auch_ ein
>direktes Auslesen aus dem FS zuläßt.

Ich denk, dass dieses entweder so keinen Sinn macht oder in Form von Triggern,
die sh-Kommandos zulassen, geloest werden sollte.

>---
>
>> verallgemeinern, koennte man das als zwei Sonderfaelle betrachten und
>> vielleicht einen Proxyserver als Kriterium verwenden, auch wenn man ihn etwas
>> zweckentfremdet.
>Sorry, ich verstehe nicht, was genau Du meinst...
>
??
ich kann:
- -alle Images im FS ablegen
- -alle in der DB belassen
- -oder nach einem Kriterium beides nutzen (z.B. beim ersten Anfassen ins FS
kopieren, die am hauefigsten benoetigten nur ins FS ablegen)
Ich wollte nur angeben, dass ein Proxy eine Moeglichkeit darstellt,
Lasten zu verteilen (indem ein anderer Server zur Imageverwaltung mit
genutzt wird). Wer genug Speicher und CPULeistung im DBServer hat, muss es ja
nicht so machen.

>Aber wie stehts eigentlich mit den SELECT CACHEDs?
>
>> Noe, gluecklicherweise laeuft ein HTTP-Server (zumindest Apache) die URI von
>> links nach rechts ab, bis er ein vorhandendes Dokument findet, dessen Mimetype
>> / Modulextension er versteht:
>> <IMG SRC=imagesender.php3/myimage.gif>
>
>Ok, also Du würdest die Argumente im Pfadteil (so hieß das bei den CGIs)
>an PHP übergeben. Dann sieht das für den Proxy aus wie eine Datei. Das
>scheitert dann doch, wenn ich einen Aufruf <IMG
>SRC="gimmeimage.php3?id=123"> habe, oder?

Exakt dieses habe ich vermieden, indem ich die Grafik-id in myimage versteckt
habe und sie ueber $REQUEST_URI (eine Apache-Umgebungsvariable) auslese.

>
>> Der Browser benennt den Download als myimage.gif (rechts nach links).
>Es geht ja nicht um den Download, sondern um den Proxy. Aber solange der
>den vollen Pfad sieht (siehe Abschnitt oben), ist das ok.
>
>Bei der ganzen Proxysache sollte man dann aber beachten, daß immer noch
>Daten geliefert werden können, die so nicht mehr in der DB existieren.
>
Genau wie der lokale Proxy desjenigen, der die Seite angefordert hat.

- -----------------------------------------------------------------------
Oliver Artelt                              Jordanstr.7, 39112 Magdeburg
mailto:oli_(at)_cubeoffice.de             Tel: 0391-6112827 Fax: 0391-604243 
- -----------------------------------------------------------------------
http://www.transnet.de                  ISP: Wir schaffen Verbindungen!
http://www.magdeburg-online.de       Die Magdeburger Online-Information
- -----------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBNxISL/5e/rfn+ii1AQGVeQQAhcXGmravFmfNAwJ6sFms87Esc/Wodoh7
uoAMCZbmtemeODId0j5tF+nyarwDfrU5VM/vL1bmGmgzDSoDdOHH7npez0k/a+nm
xcbeD+fZ9cPDvy3G7ZcivHHcT2Tp4HwPCFrBNpOquJ1ZhvY1ig4sBsuzUZv0ULb6
Aob3P1V5Ug8=
=ZrfV
-----END PGP SIGNATURE-----


Home | Main Index | Thread Index

php::bar PHP Wiki   -   Listenarchive