php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Entwicklung > PHP Developer Forum
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


PHP Developer Forum Hier habt ihr die Möglichkeit, eure Skriptprobleme mit anderen Anwendern zu diskutieren. Seid so fair und beantwortet auch Fragen von anderen Anwendern. Dieses Forum ist sowohl für ANFÄNGER als auch für PHP-Profis! Fragen zu Laravel, YII oder anderen PHP-Frameworks.

Antwort
 
LinkBack Themen-Optionen Bewertung: Bewertung: 1 Stimmen, 5,00 durchschnittlich.
  #1 (permalink)  
Alt 21-08-2009, 09:23
TriphunEM
 Registrierter Benutzer
Links : Onlinestatus : TriphunEM ist offline
Registriert seit: Jun 2003
Beiträge: 549
TriphunEM ist zur Zeit noch ein unbeschriebenes Blatt
Standard Datei in MySQL speichern oder auf der Festplatte!

Ich mach jetzt gerade ein XML-Import. In der XML kommen auch Bilder und PDFs vor die base64 kodiert sind.

Jetzt überleg ich, speicher ich die Datei auf der Festplatte und trag in der DB den Dateinamen ein, oder speicher ich die Daten direkt in der DB.

Am liebsten würde ich die Dateien in der DB ablegen, aber ich hab ein schlechtes gefühl wegen den abfragedauer und der performance der DB, wenn ich solche große Daten in der DB ablege.

Oder könnt ihr mir tipps geben wie ich Dateien in einer DB speichern kann, ohne die Performance und Abfragedauer zu schwächen???

Ich zieh deshalb die DB-variante vor, da der Import weitgehenst dynmamisch sein soll, und ich nicht immer weiß welcher XML-Tag nur ein String ist oder einen Dateiinhalt beinhaltet.
Mit Zitat antworten
  #2 (permalink)  
Alt 21-08-2009, 16:54
wahsaga
  Moderator
Links : Onlinestatus : wahsaga ist offline
Registriert seit: Sep 2001
Beiträge: 25.236
wahsaga befindet sich auf einem aufstrebenden Ast
Standard

Grössere Binärdateien gehören im Normalfall nicht in die DB, die sind im Dateisystem besser aufgehoben.

Ein Argument für die Ablage von Dateien in der DB wäre einfache(re) Durchsuchbarkeit - fällt bei Binärdateien (Bilder, Musik, Videos) natürlich eher unter den Tisch; bei XML hingegen könnte das schon relevant sein.


Zitat:
Ich zieh deshalb die DB-variante vor, da [...] ich nicht immer weiß welcher XML-Tag nur ein String ist oder einen Dateiinhalt beinhaltet.
Das muss sich doch aber irgendwie ermitteln lassen? Daten, deren Bedeutung unbekannt ist, sind doch eher unbrauchbar.


Das XML in die DB legen, und den base64-kodierten Kram aber extrahieren und ins Dateisystem verfrachten, wäre eine Möglichkeit, das ganze performanter zu halten. Natürlich beim Import etwas aufwendiger, aber auf Dauer beim Auslesen vermutlich besser (kommt natürlich im Einzelfalle darauf an, was mit den Daten anschliessend gemacht werden soll).
__________________
I don't believe in rebirth. Actually, I never did in my whole lives.
Mit Zitat antworten
  #3 (permalink)  
Alt 24-08-2009, 12:09
TriphunEM
 Registrierter Benutzer
Links : Onlinestatus : TriphunEM ist offline
Registriert seit: Jun 2003
Beiträge: 549
TriphunEM ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Danke! Denke auch das ich es so machen werden. Das Problem ist, dass ich mein import so dynamisch halten will wie es geht, ohne groß feste regeln hard zu coden. Das problem ich erkenn nicht im XML wenn ein tag binärcode ht, und könnte diesen dann als file speichern. der binärcode ist base64 kodiert und das problem ist, dass es keine möglichkeit gibt eindeutig base64 kodierten code zu erkennen...das wäre wesentlich einfacher für mich!
Mit Zitat antworten
  #4 (permalink)  
Alt 24-08-2009, 12:30
AmicaNoctis
  Moderatorin
Links : Onlinestatus : AmicaNoctis ist offline
Registriert seit: Jul 2009
Beiträge: 5.709
Blog-Einträge: 9
AmicaNoctis sorgt für eine eindrucksvolle AtmosphäreAmicaNoctis sorgt für eine eindrucksvolle Atmosphäre
Standard

Du könntest die base64-codierten Daten auch als Data URI schreiben. Dann hast du erstens zusätzliche Merkmale, um es mit Regex zu prüfen und zweitens kannst du gleich den Content-Type noch mit ablegen. Wenn du ganz auf Nummer sicher gehen musst, könntest du mehrstufige Prüfungen machen, z. B.

1. Prüfen, ob "data:" am Anfang steht => false: kein binary
2. Regex prüfen "!^data:[a-z]+/[a-z0-9+-]+;base64,!i" => false: kein binary
3. Base64 decodieren => false: kein binary
4. decodiertes Base64 mit FInfo->buffer() auf richtigen Content-Type prüfen

Geändert von AmicaNoctis (24-08-2009 um 12:44 Uhr)
Mit Zitat antworten
  #5 (permalink)  
Alt 24-08-2009, 12:35
combie
 PHP Expert
Links : Onlinestatus : combie ist offline
Registriert seit: May 2006
Beiträge: 3.296
combie wird schon bald berühmt werden
Standard

Zitat:
Ein Argument für die Ablage von Dateien in der DB wäre einfache(re) Durchsuchbarkeit -
Das wichtigste pro Argument ist meines bescheidenen Erachtens nach die referenzielle Integrität der Daten. Seit InnoDB kein Problem mehr.
Z.B. nur 1 Datensicherung und nicht MySQL Daten und Dateien getrennt.
Irgendwelche Performance Probleme lassen sich durch cachen mildern.

Allerdings bieten normale Webspaces nicht immer die Möglichkeiten mit so riesigen Datensicherungen umzugehen.
__________________
Wir werden alle sterben
Mit Zitat antworten
  #6 (permalink)  
Alt 24-08-2009, 13:28
Lennynero
 Registrierter Benutzer
Links : Onlinestatus : Lennynero ist offline
Registriert seit: Sep 2007
Beiträge: 121
Blog-Einträge: 1
Lennynero ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Zitat:
Zitat von combie Beitrag anzeigen
Das wichtigste pro Argument ist meines bescheidenen Erachtens nach die referenzielle Integrität der Daten. Seit InnoDB kein Problem mehr.
Z.B. nur 1 Datensicherung und nicht MySQL Daten und Dateien getrennt.
Irgendwelche Performance Probleme lassen sich durch cachen mildern.

Allerdings bieten normale Webspaces nicht immer die Möglichkeiten mit so riesigen Datensicherungen umzugehen.
Das mit der einzigen Datensicherung fand ich auch sehr interessant, musste dann aber bei unserer DB feststellen, dass die Größe explodiert ist.

Einen Tipp bzgl Performance hatte ich gelesen, da wurde vorgeschlagen die BLOB_Felder in eine eigene Tabelle zu legen (die dann 1zu1 mit der Tabelle mit den restlichen Dateiinformationen verknüpft ist), denn selbst wenn man die BLOB-Felder nicht abfragen würde, könnte es wohl passieren dass diese beim Abfragen der Tabelle das Ganze ausbremsen.
Mit Zitat antworten
  #7 (permalink)  
Alt 24-08-2009, 13:32
combie
 PHP Expert
Links : Onlinestatus : combie ist offline
Registriert seit: May 2006
Beiträge: 3.296
combie wird schon bald berühmt werden
Standard

Zitat:
denn selbst wenn man die BLOB-Felder nicht abfragen würde, könnte es wohl passieren dass diese beim Abfragen der Tabelle das Ganze ausbremsen.
Dazu habe ich bei mir noch keine Indizien gefunden.
Darum: Das Auslagern in extra Tabellen ist, nunja, recht sinnfrei.

Das dümmste, was man mit solchen Tabellen(mit fetten Blobs) machen kann ist "SELECT * FROM ...."
__________________
Wir werden alle sterben
Mit Zitat antworten
  #8 (permalink)  
Alt 24-08-2009, 13:42
Lennynero
 Registrierter Benutzer
Links : Onlinestatus : Lennynero ist offline
Registriert seit: Sep 2007
Beiträge: 121
Blog-Einträge: 1
Lennynero ist zur Zeit noch ein unbeschriebenes Blatt
Standard

SQL-Optimierung: Tabellen und Spalten anpassen - Teil 3: MySQL 4 - Optimierung von Anfragen | Vermeiden Sie, große BLOB-Werte zu suchen, wenn das nicht unbedingt erforderlich ist | TecChannel.de

Zitat:
Sammeln Sie BLOB-Werte in einer separaten Tabelle
Manchmal kann es sinnvoll sein, BLOB-Werte aus einer Tabellenspalte in eine separate Tabelle zu verschieben, wenn Sie dadurch die Zeilen der ursprünglichen Tabelle in ein
Format fester Länge umwandeln können. Damit wird die Fragmentierung der
ursprünglichen Tabelle reduziert, und Sie können die Leistungsvorteile von Zeilen fester Länge nutzen. Außerdem können Sie bei dieser Vorgehensweise Anfragen vom Typ SELECT * in der Primärtabelle ausführen, ohne umfangreiche BLOB-Werte über das Netzwerk zu holen.
"SELECT *" sollte man imo generell vermeiden.

Das war jetzt auch die schnellste Quelle die ich gefunden habe... bin mir aber sicher das ich das auf einer englischsprachigen Seite etwas ausführlicher begründet gelesen habe.
Mit Zitat antworten
  #9 (permalink)  
Alt 24-08-2009, 14:00
combie
 PHP Expert
Links : Onlinestatus : combie ist offline
Registriert seit: May 2006
Beiträge: 3.296
combie wird schon bald berühmt werden
Standard

Habs gerade noch mal getestet.

Tabelle mit ca 20000 Rows
Mysql 5.1.30-community
innodb
In den Blobs liegen PDF Dateien verschiedenster Größe.


Ein SELECT, welcher ca 100 Rows daraus per where selektiert.
Die BLOB Spalte nicht mit ausgewählt.


Erst mit Blobspalte, danach Blobspalte entfernt, und das gleiche select Statement verwendet.

Kein Unterschied/Tendenz festzustellen.
__________________
Wir werden alle sterben
Mit Zitat antworten
  #10 (permalink)  
Alt 26-08-2009, 13:58
unset
  Moderator
Links : Onlinestatus : unset ist offline
Registriert seit: Jan 2007
Ort: Düsseldorf
Beiträge: 3.782
unset befindet sich auf einem aufstrebenden Ast
Standard

Also, ich persönlich speicher Daten seit einigen Jahren nur noch in der Datenbank –*auch wenn ich dafür schon oft blöd angeguckt worden bin. So wirklich triftige Argumente dagegen konnte mir niemand nennen. Und nennenswerte Geschwindigkeitseinbußen konnte ich auch nicht feststellen. IMHO spricht nix dagegen.
Mit Zitat antworten
  #11 (permalink)  
Alt 26-08-2009, 14:11
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.593
h3ll befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von unset Beitrag anzeigen
Also, ich persönlich speicher Daten seit einigen Jahren nur noch in der Datenbank –*auch wenn ich dafür schon oft blöd angeguckt worden bin. So wirklich triftige Argumente dagegen konnte mir niemand nennen. Und nennenswerte Geschwindigkeitseinbußen konnte ich auch nicht feststellen. IMHO spricht nix dagegen.
Wenn du mit externe Programme auf die Dateien zugreifen willst, musst du sie jedesmal aus der Datenbank holen und abschließend wieder zurückspeichern. Ziemlich umständlich und verbraucht unnötig Ressourcen.

Außerdem wird dadurch eine Synchronisation unnötig kompliziert. Auf Dateisystemebene reicht einfach ein rsync und fertig ist die Geschichte. Wenn du jetzt aber anfängst Binärdaten zwischen zwei Datenbanken abzugleichen, geht die Performance der Server schnell in die Knie.

Dateien auf Dateiebene kannst du übrigens problemlos mit HTML verlinken. Wenn die Dateien allerdings in der Datenbank sind, brauchst du ein Script, das jedesmal die Daten aus der Datenbank zieht. Das kann bei einer großen Menge schon zu einem ziemlichen Problem werden. Stell dir ein CMS vor wo Bilder auf der Seite verlinkt sind. Angenommen auf einer Seite sind 50 Bilder, dann werden pro Seitenaufruf 51 PHP-Prozesse gestartet (einer, der HTML liefert, und 50 andere, die Bilder aus der Datenbank holen). Wenn jetzt 10 Leute gleichzeitig aufrufen hast du statt 10 PHP-Prozesse 510 PHP-Prozesse.

Geändert von h3ll (26-08-2009 um 14:17 Uhr)
Mit Zitat antworten
  #12 (permalink)  
Alt 26-08-2009, 14:37
unset
  Moderator
Links : Onlinestatus : unset ist offline
Registriert seit: Jan 2007
Ort: Düsseldorf
Beiträge: 3.782
unset befindet sich auf einem aufstrebenden Ast
Standard

Wie ich schon angedeutet habe, dass sind Rechenspielchen und Zahlen, die in der realen Welt dann gar nicht mehr so ein Gewicht haben. Ich mache das seit Jahren so und habe damit noch nie Probleme gehabt. Wobei: Es handelt sich dabei tatsächlich auch nur noch um Daten, die (dort) nicht mehr nachbearbeitet werden –*d.h. das externe Öffnen fällt flach. Obwohl ich mal angefangen habe, mir für so einen Fall einen FUSE-Wrapper zu bauen –*aber wo kein Kläger, da kein Richter, und ohne Motivation einfach nur aus Spaß war mir das dann doch zu schwer.
Mit Zitat antworten
  #13 (permalink)  
Alt 26-08-2009, 15:37
PHP-Desaster
 PHP Expert
Links : Onlinestatus : PHP-Desaster ist offline
Registriert seit: Mar 2006
Beiträge: 3.105
PHP-Desaster befindet sich auf einem aufstrebenden Ast
Standard

Wir nutzen das intern auch so für verschiedene Systeme. Hintergrund ist jedoch die verteile Ausführung der Anwendung mit der Datenbank als einzigen gemeinsamen Datenspeicher. Sicherlich auch irgendwie über einen entsprechenden Fileserver zu lösen, jedoch ist die Datenbank eh immer vorhanden, erlaubt auf jeden Fall Locks, etc. Der Einrichtungsaufwand ist einfach geringer.
Mit Zitat antworten
  #14 (permalink)  
Alt 27-08-2009, 03:25
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard

Ich habe noch niemals ernsthaft Dateien in einer DB gespeichert und sehe das auch bei der Arbeit nie.
Was speichert ihr denn da bitte für Dateien? Warum eigentlich in der DB?
Nur weil das Backupscript dann eine Zeile kürzer ist?
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Externe Datei auslesen und in Datei auf Webserver speichern mega16 Apps und PHP Script Gesuche 3 25-09-2014 20:58
Entscheidung: Log in Datei oder Datenbank speichern? carapau PHP Developer Forum 9 26-04-2007 15:11
Aus Datei Textblöcke in neue Datei speichern lollol Apps und PHP Script Gesuche 16 20-08-2005 17:31
pdf-Datei in mysql speichern (blob?) masch SQL / Datenbanken 1 04-12-2003 10:34
MySQL Datenbank in TXT Datei speichern Hifi PHP Developer Forum 1 29-05-2002 18:58

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni

Wissensbestand in Unternehmen
Wissensbestand in UnternehmenLebenslanges Lernen und Weiterbilden sichert Wissensbestand in Unternehmen

25.05.2018 | Berni


 

Aktuelle PHP Scripte

ADSMAN V3 - Werbe-Manager ansehen ADSMAN V3 - Werbe-Manager

ADSMAN V3 - mehr als nur ein Bannermanager! Banner, Textanzeigen und PagePeel Manager! Mit ADSMAN PRO haben Sie die Marketinglösung für eine effektive und effiziente Werbeschaltung mit messbaren Ergebnissen. Unterstützt werden Bannerformate in beliebi

25.10.2018 virtualsystem | Kategorie: PHP/ Bannerverwaltung
PHP News und Artikel Script V2

News schreiben, verwalten, veröffentlichen. Dies ist jetzt mit dem neuen PHP News & Artikel System von virtualsystem.de noch einfacher. Die integrierte Multi-User-Funktion und der WYSIWYG-Editor (MS-Office ähnliche Bedienung) ermöglichen...

25.10.2018 virtualsystem | Kategorie: PHP/ News
Top-Side Guestbook

Gästebuch auf Textbasis (kein MySQL nötig) mit Smilies, Ip Sperre (Zeit selbst einstellbar), Spamschutz, Captcha (Code-Eingabe), BB-Code, Hitcounter, Löschfunktion, Editierfunktion, Kommentarfunktion, Kürzung langer Wörter, Seiten- bzw. Blätterfunktion, V

22.10.2018 webmaster10 | Kategorie: PHP/ Gaestebuch
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 00:08 Uhr.