CronJob-Service
bei SELFPHP mit ...
|
+ minütlichen Aufrufen
+ eigenem Crontab Eintrag
+ unbegrenzten CronJobs
+ Statistiken
+ Beispielaufrufen
+ Control-Bereich
Führen Sie mit den CronJobs von
SELFPHP zeitgesteuert Programme
auf Ihrem Server
aus. Weitere Infos
|
:: Anbieterverzeichnis ::
Globale Branchen
Informieren Sie sich über ausgewählte Unternehmen im Anbieterverzeichnis von SELFPHP
:: Newsletter ::
Abonnieren Sie hier den kostenlosen
SELFPHP Newsletter!
|
MySQLi/PDO/(MySQL) Anfänger, Fortgeschrittene oder Experten können hier Fragen und Probleme rund um MySQLi/PDO/(MySQL) diskutieren |
27.12.2004, 13:51:06
|
Anfänger
|
|
Registriert seit: Dec 2004
Beiträge: 8
|
|
Bilder in DB laden > als 1 MB
Hi Coders
ich programmiere eine Anwendung bei der auch Bilder in Mysql in eine Mediumblob Salte geladen werden können usw.
Wenn ich allerdings Bilder über 1 MB lade, funktionierts nicht. Bei Jpegs um 500 KB klappts gut.
Wo sind denn noch Einschränkungen versteckt.
- PHP -> PHP.ini (Download steht auf 2M)
- PHP -> Downloadzeit <= 30 sec.
- mysql -> Mediumblob (16,7 MB)
- Apache Webserver (? keine)
Für eine Tip wäre ich sehr dankbar.
|
27.12.2004, 14:02:23
|
|
SELFPHP Guru
|
|
Registriert seit: May 2003
Beiträge: 7.187
|
|
Musst du die Bilder zwingend in der Datenbank speichern? Reicht es nicht die Dateien auf dem Webserver abzulegen und nur die Pfade in der Datenbank zu sichern?
|
27.12.2004, 14:08:54
|
|
Junior Member
|
|
Registriert seit: May 2003
Ort: CH Zürich
Alter: 66
Beiträge: 352
|
|
Du willst das Bild direkt in die DB schreiben?
Das solltest Du nicht tun, sondern in der DB nur die Links verwalten und das Bild in einem Verzeichnis ablegen.
Dazu habe ich ein Script geschrieben unter: Bildupload
Zudem, das ganze wird schneller und die DB kommt nicht an ihren Anschlag. Jetzt spielt nur bei PHP der Wert unter"upload_max_filesize" eine Rolle.
|
27.12.2004, 14:09:17
|
Anfänger
|
|
Registriert seit: Dec 2004
Beiträge: 8
|
|
Ich muss sie in der DB speichern, da es sonst zu kompliziert werden würde. Die Anwendung ist ein Auktionsprogramm mit vielen verschiedenen Verfahren, bei denen jeweils natürlich andere Artikellisten mit entsprechenden Bildern genutzt werden.
Jedes Verfahren bekommt eine eigen DB...
Um kein Chaos zu erhalten müsste ich sonst jeweils Unterverzeichnisse für die Bilder anlegen usw...
Einfacher ist da wohl der direkte upload
|
27.12.2004, 14:17:12
|
|
Junior Member
|
|
Registriert seit: May 2003
Ort: CH Zürich
Alter: 66
Beiträge: 352
|
|
Ich würde die Bilder trozdem nicht in die DB speichern.
Ich hatte ein ähnliches Problem. Beim anlegen von Artikeln wird automatisch ein Verzeichnis erstellt das die selbe Nummer hat wie die ID des Artikels, so bleibt es übersichtlich und es sind Bilder mit gleichem Namen zulässig.
Beim löschen der Artikel wird automatisch das Verzeichnis geleert und gelöscht.
|
27.12.2004, 14:24:16
|
Anfänger
|
|
Registriert seit: Dec 2004
Beiträge: 8
|
|
Also gut... dann werde ich mir doch wohl ein bisschen mehr mühe gben müssen und es so machen...
Vielen Dank so far....
|
27.12.2004, 15:30:10
|
|
Member
|
|
Registriert seit: Mar 2002
Ort: Port 80, localhost-city, 127/0/0/1
Beiträge: 878
|
|
nunja, ich will mal wiedersprechen und behaupte einfach mal, dass es mitunter sehr wohl sinn machen kann, Bilder in einer DB zu speichern, und zwar dann, wenn die bilder die eigentlichen daten sind!
(z.b. bei großen Fotoblog seiten oder sowas... ich hab einmal ein bisschen konzeptionell bei der entwicklung von sowas mitgewirkt, und habe in dem zusammenhang auch viele diskussionen über das thema gehabt (unter anderem auch mit ein paar leuten, deren Job Datenbanken (also Data Warehousing, etc.) sind.
Die Sache ist dann einfach die, dass die DB natürlich performance verliert, andererseits tun sich Dateisysteme in extremfällen (also wenn es WAHNSINNIG viele, kleine Dateien sind, die sehr häufig neu erstellt/gelöscht werden) auch nicht viel besser - denn das ist da wieder der vorteil von Datenbanken. Dort wird ausserdem noch gleich die Datenkonsitenz mitbewacht - was passiert, wenn ein bild unabsichtlich gelöscht wird, was aber nicht in der DB gekennzeichnet wird (aus welchem grund auch immer, udn sei es nur, weil ignore_user_abort nicht gesetzt wurde).. wir haben eine tote referenz, die nur SEHR schwer gefunden werden könnte. Ein weiterer Vorteil wären bspw. digitale Signaturen in Bildern, die könnte man sicherlich leichter prüfen wenn sie in DBs sind. Außerdem: was ist wenn ein bug in der software ist, und die bilder nicht immer richtig benamt werden? Findet man diesen Fehler jemals? (und die festplatte müllt sich zu, währed Bilder verschwinden)
Nein, es macht mitunter durchaus sinn, Bilder in DBs zu speichern, aber eben nur in sehr speziellen fällen (und auch dann nicht mit mySQL)
lg matt
|
27.12.2004, 15:42:14
|
|
Junior Member
|
|
Registriert seit: May 2003
Ort: CH Zürich
Alter: 66
Beiträge: 352
|
|
@Matt
Da gebe ich Dir teilweise Recht. Aber es wurde von Bildern mit über 1 MB gesprochen, die würde ich nie in die DB speichern.
Wenn die Bilder bis ca. 50 kB wären, ja dann...
Nebenbei, wie erwähnt, der Name des Verzeichnis sollte der ID in der DB entsprechen, sonst wird es wirklich sehr chaotisch.
|
27.12.2004, 15:54:58
|
|
Member
|
|
Registriert seit: Mar 2002
Ort: Port 80, localhost-city, 127/0/0/1
Beiträge: 878
|
|
hm ich schätze mal chaotisch wird es auf jeden fall, oder? ;)
und wie gesagt, es kommt auch auf den verwendugnszweck an, wenn du eine photocommunity oder sowas aufmachst, dann wäre es schon angebracht, das ganze in der DB zu speichern, so muss man auch nur eines backuppen. BTW: Worst case szenario: Stellt euch vor, irgendwann gibt es einen Overflow bei der PictureId und man müsste die Keys neu sortieren, da sehr viele keys nicht mehr benützt werden (weil die bilder schon gelöscht wurden) Wenn mann da dann alle bilder umbenennen müsste... *schauder*
aber ansonsten bin ich auch der meinung, dass man bilder im normalfall nicht in der DB speichern sollte.
lg matt
|
Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
|
|
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.
HTML-Code ist aus.
|
|
|
Alle Zeitangaben in WEZ +2. Es ist jetzt 08:35:31 Uhr.
|