[PHP] Images uit database

[trinite_t]

Zoals al eerder gemeld ben ik bezig met het bouwen van een webshop. Ik loop nu alleen tegen het volgende probleem aan:
Ik laad images vanuit de database met het volgende phpscript:

PHP:

    require_once "include/Firebird.class.php";
    include_once "include/variables.inc.php";

$GLOBALS['DBPass']);
    session_start();
    $db = $_SESSION['db'];
    header("Content-type: image/jpg");
    $db->connect();
    $result = $db->query("SELECT MFOTO FROM MAGAZIJN WHERE MARTCODE='$_GET[artcode]'");
    $db->close();
    $result = ibase_fetch_object($result);
    if($result->MFOTO != NULL){
        /*
         ibase_blob_info array:
         [0] bloblength(total)
         [1] number of segments
         [2] size of largest segment
         [3] stream or segmented blob
         [4] ??
        */
        $blobinfo = ibase_blob_info($result->MFOTO);

        $blobhandle = ibase_blob_open($result->MFOTO);
        for($i = 0; $i < $blobinfo[1]; $i++){
            $readsize = $blobinfo[2];
            if($i == ($blobinfo[1] - 1)){
                $readsize = $blobinfo[0] - (($blobinfo[1] - 1) * $blobinfo[2]);
            }
            $totalimage .= ibase_blob_get($blobhandle, $readsize);
        }
        ibase_blob_close($blobhandle);
        
        echo $totalimage;
    }else{
        $image = imagecreate(53, 23);

        $bgcolor = imagecolorallocate($image, 255, 255, 255);
        $textcolor = imagecolorallocate($image, 0, 0, 0);

        imagestring($image, 2, 3, 0, "No image", $textcolor);
        imagestring($image, 2, 0, 10, "available", $textcolor);

        imagejpeg($image);
    }

Dit werkt goed, maar om een image te kunnen resizen moet je hem openen via een bestandsnaam:

PHP:

magecreatefromjpeg ( string filename)

maar omdat mijn images uit een database kom heb ik alleen een variabele ($totalimage) met binaire data van het image. Nu zou ik deze wel via een omweg op de hd kunnen opslaan en dan weer openen, maar dit lijkt mij erg omslachtig en vooral ook een erge uitputting van je resources.

Is er een andere manier om het te doen?

[Janoz]

Kijk eens in de manual 2 functies onder 'createfromjpeg'

[Woy]

Pas trouwens ook even op met wat je doet. Op regel 9 van de voorbeeld code zit een query die nogal makkelijk misbruikt kan worden voor sql injectie

[Verwijderd]

Ik vind het persoonlijk handiger om bestanden niet op te slaan in een database. Redenen daarvoor zijn bijvoorbeeld:
- Het filesystem is sneller met het oplepelen van data dan een db.
- Als je db op een apparte server komt te staan levert dit onnodig verkeer op.
- en nog legio andere redenen.

Oftewel sla je bestand gewoon lekker op op je FS en sla enkel de locaties op in je db.

[Fuzzillogic]

Sla sowieso de resized afbeeldingen op (als een cache) ipv bij elke request te gaan resizen. Dat duurt veel te lang.

[Peter]

Ik zou ook afraden om plaatjes in de database te zetten, daar zijn de databases die jij gebruikt niet voor bedoeld. Er zijn wel speciale image-databases (waar bijv. ook google gebruik van maakt), maar die pakketten kosten zo gigantisch veel geld, dat wil je niet...

Ik ga met Mark mee, gewoon in een map opslaan, daar is het voor bedoeld

[Fuzzillogic]

Verwijderd schreef op donderdag 29 december 2005 @ 13:58:
Ik vind het persoonlijk handiger om bestanden niet op te slaan in een database. Redenen daarvoor zijn bijvoorbeeld:
- Het filesystem is sneller met het oplepelen van data dan een db.
- Als je db op een apparte server komt te staan levert dit onnodig verkeer op.
- en nog legio andere redenen.

Oftewel sla je bestand gewoon lekker op op je FS en sla enkel de locaties op in je db.

Een DB is, net als een FS, bij uitstek geschikt voor het oplepelen van data. Het ligt aan je toepassing, maar voor mij is DB opslag een stuk prettiger omdat je met 1 query gelijk een bult meta-data kunt opvragen, samen met de afbeelding.

Enfin, om te zeggen dat DB opslag per definitie slecht is, vind ik onzin. Het omgekeerde ook.

[trinite_t]

Ik heb beide gebruikt(file en database), en voor dit systeem moet er gewerkt worden vanuit de database. En om eerlijk te zijn, met firebird als database gaat het niet veel langzamer dan het filesystem.

[Peter]

Nexxennium schreef op donderdag 29 december 2005 @ 14:01:
[...]


Een DB is, net als een FS, bij uitstek geschikt voor het oplepelen van data. Het ligt aan je toepassing, maar voor mij is DB opslag een stuk prettiger omdat je met 1 query gelijk een bult meta-data kunt opvragen, samen met de afbeelding.

Enfin, om te zeggen dat DB opslag per definitie slecht is, vind ik onzin. Het omgekeerde ook.

Je hebt wel gelijk ja, máár, als je website een beetje succesvol wordt dan gaat je server het echt niet leuk vinden. Een puur apache request naar een plaatje op je HD is sneller en neemt minder geheugen in beslag, dan een request naar een PHP pagina die een verbinding met MySQL moet maken en je daarna pas het plaatje voorschoteld..

Citaat van http://www.yapf.net/faq.php?cmd=100&itemid=621 :

Stel je hebt een drukke image gallery site met 30 gelijktijdige bezoekers en je zet 25 plaatjes tegelijk op een pagina. Dat zijn 30 + 25*30 = 780 gelijktijdige processen op apache, en dus ook 780 php scripts die samen dus 780 verbindingen met de database maken. OP je database server heb je dan dus 780*2.5MB = 1950MB RAM nodig alleen om de verbindingen te kunnen maken. Dan moet de database nog van disk lezen en de resultaten verwerken, reken maar op een minimum van 4GB ram alleen voor de database.
MySQL's harde connection limiet is 1024, en met 780 kom je daar eng dicht in de buurt.

[ Voor 30% gewijzigd door Peter op 29-12-2005 14:05 ]

[Verwijderd]

Nexxennium schreef op donderdag 29 december 2005 @ 14:01:
Een DB is, net als een FS, bij uitstek geschikt voor het oplepelen van data. Het ligt aan je toepassing, maar voor mij is DB opslag een stuk prettiger omdat je met 1 query gelijk een bult meta-data kunt opvragen, samen met de afbeelding.

Enfin, om te zeggen dat DB opslag per definitie slecht is, vind ik onzin. Het omgekeerde ook.

Ten eerste ik zeg nergens dat ik het per definitie slecht vind. Ik zeg dat het niet handig is. Ten tweede: Zeker in dit geval levert het simpelweg een ongelooflijke load op je server. Wat je hier doet is je plaatjes volledig in memory laden voor elke request. Die stap is compleet onnodig. Een paar stringetjes oplepelen in die in een html context plaatsen vind je server een stuk fijner

En om je defenities even op te frissen:
Een DB is per definitie zeer geschikt voor het opslaan en selecteren van data.
Een filesystem is per definitie geschikt voor het oplepelen van data.

[Arnout]

Hangt er maar net vanaf hoeveel je ervoor over hebt. Zet een flinke server neer en je kan je plaatjes requests prima dynamisch doen (mits het bronplaatje in de database niet al te groot is).
Voordeel is dat je er dynamische plaatjes van kan maken, bijvoorbeeld "item tijdelijk uitverkocht" eroverheen.

[Verwijderd]

Arnout schreef op donderdag 29 december 2005 @ 14:07:
Hangt er maar net vanaf hoeveel je ervoor over hebt. Zet een flinke server neer en je kan je plaatjes requests prima dynamisch doen (mits het bronplaatje in de database niet al te groot is).
Voordeel is dat je er dynamische plaatjes van kan maken, bijvoorbeeld "item tijdelijk uitverkocht" eroverheen.

Het wel of niet opslaan van de complete binairy heeft helemaal niets van doen of je dynamisch een plaatje kunt tonen. Of je nu mappings of binaries opslaat maakt het niet meer of minder dynamisch.

[Fuzzillogic]

.Peter schreef op donderdag 29 december 2005 @ 14:04:
[...]
Citaat van http://www.yapf.net/faq.php?cmd=100&itemid=621 :

[...]

Apache 2 is multithreaded. Dus hooguit 2 processes. PHP kan ook multi-threaded draaien, afgezien van enkele libraries. En je gaat er al zomaar vanuit dat het een zeer populaire site wordt. Heb je daar redenen toe?

Als je afbeeldingen in het FS opslaat, zul je zelf voor ID's moeten zorgen en de overige huishoudelijke taken. Wat dacht je van het opruimen van caches? (als je die hebt). Bij mijn eigen gemaakte fotoalbumsysteem is een cache met 1 query weer opgeschoond.

In mijn hobby en professionele ervaring heb ik voor eenvoudige problemen wel FS-opslag gebruikt. Dat is evengoed snel in elkaar te zetten. Voor complexere zaken, zoals fotoalbum met caches e.d. gebruik ik toch echt veel liever een DB. Ook op mijn 800MHz Duron thuisservertje met een ancient MySQL heeft dat niet voor performance problemen gezorgd.

[Erkens]

Verwijderd schreef op donderdag 29 december 2005 @ 13:58:
Ik vind het persoonlijk handiger om bestanden niet op te slaan in een database. Redenen daarvoor zijn bijvoorbeeld:
- Het filesystem is sneller met het oplepelen van data dan een db.
- Als je db op een apparte server komt te staan levert dit onnodig verkeer op.
- en nog legio andere redenen.

Oftewel sla je bestand gewoon lekker op op je FS en sla enkel de locaties op in je db.

maar voor een backup/recovery procedure is het handiger om alles in je database te hebben, en dat voordeel vind ik meer opwegen dan dat het sneller is.
Als je een aparte server hebt moet kan je nog wel die afweging maken met de hoeveelheid traffic, maar vaak gaat dat over een lokaal rete snel netwerk dat je daar nauwelijks last van hebt.

[Verwijderd]

Erkens schreef op donderdag 29 december 2005 @ 14:15:
maar voor een backup/recovery procedure is het handiger om alles in je database te hebben, en dat voordeel vind ik meer opwegen dan dat het sneller is.
Als je een aparte server hebt moet kan je nog wel die afweging maken met de hoeveelheid traffic, maar vaak gaat dat over een lokaal rete snel netwerk dat je daar nauwelijks last van hebt.

Tsja ik noemde snelheid als twee punten omdat het twee hippe argumenten zijn die hier doorgaans snel aanslaan en daardoor zwaar tellen.

Backup zoals jij die stelt vind ik leuk voor een thuis projectje, maar ik zou daar een of andere raid configuratie voor gebruiken.

[Woy]

Verwijderd schreef op donderdag 29 december 2005 @ 14:22:
[...]

Tsja ik noemde snelheid als twee punten omdat het twee hippe argumenten zijn die hier doorgaans snel aanslaan en daardoor zwaar tellen.

Backup zoals jij die stelt vind ik leuk voor een thuis projectje, maar ik zou daar een of andere raid configuratie voor gebruiken.

Juist voor backup bij proffesionele doeleinden is het handig dat alles in een medium zit aangezien je dan veel makkelijker terug kunt stappen naar een situati op een bepaald moment. Als je verschillende backups moet maken ( een van de database en een van het filesystem ) en je wilt iets terug zetten dan krijg je bijna zeker weten een inconsistentie tussen je database en je filesystem aangezien ze niet precies van hetzelfde moment zijn.
Zelf zou ik echter wel eerder geneigd zijn om dingen op het file-system te zetten want ik ben er altijd een beetje bang voor dat de grote hoeveelheden data ook de rest van de performance van de database onderuit halen doordat ze onder andere de cache opvullen. Maar dat is meer een gevoel waar ik niet direct bewijzen voor heb aangezien ik me niet echt dagenlijks bezig hou met plaatjes opslaan/ophalen.

offtopic:
kijk zoals ik eerder zei nog eens naar de sql injection want als ik nou als artikelcode iets als

';DELETE FROM MFOTO WHERE '' = '

meegeef dan gaat het helemaal fout in je script

[ Voor 8% gewijzigd door Woy op 29-12-2005 14:47 ]

[Erkens]

Verwijderd schreef op donderdag 29 december 2005 @ 14:22:
Backup zoals jij die stelt vind ik leuk voor een thuis projectje, maar ik zou daar een of andere raid configuratie voor gebruiken.

raid != backup

Juist voor een thuisprojectje waar je vaak limitaties hebt aan resources zou ik gaan voor het opslaan in het filesystem.

[Verwijderd]

Erkens schreef op donderdag 29 december 2005 @ 14:46:
raid != backup

Prima, zo kun je het ook stellen. Maar in dat geval: wat wil je bereiken met je backup?

edit:
Ik ben in principe tegen periodiek backuppen. Ik ben voor continu backup. Zeker als het een website betreft die eigelijk gewoon 24/7 up moet zijn zonder verlies van data. Dat backuppen moet transparant gebeuren en mag dus geen limitaties op het ontwerp van de applicatie leggen.

[ Voor 41% gewijzigd door Verwijderd op 29-12-2005 14:50 ]

[Woy]

Verwijderd schreef op donderdag 29 december 2005 @ 14:47:
[...]

Prima, zo kun je het ook stellen. Maar in dat geval: wat wil je bereiken met je backup?

Dat je data veilig is en dat je in het geval van een brand of crash je data terug kunt krijgen. Daarbij is het natuurlijk wel de vraag hoe belangrijk je data voor je is en hoeveel effort je er in wilt stoppen om dat te kunnen garranderen.

[Erkens]

Verwijderd schreef op donderdag 29 december 2005 @ 14:47:
[...]

Prima, zo kun je het ook stellen. Maar in dat geval: wat wil je bereiken met je backup?

Data kunnen recoveren als er wat fout gaat, bijvoorbeeld een leuke crash van je server(s) waarmee je raid corrupt raakt.
Als je in een professionele omgeving alleen op raid vertrouwen als "backup" ben je niet slim bezig.
Om dit weer ontopic te halen, je hoeft dan alleen je applicatie opnieuw te deployen en je database terug te zetten en je bent weer online ipv eerst duizenden files te kopieren.

Verwijderd schreef op donderdag 29 december 2005 @ 14:47:
Ik ben in principe tegen periodiek backuppen. Ik ben voor continu backup. Zeker als het een website betreft die eigelijk gewoon 24/7 up moet zijn zonder verlies van data. Dat backuppen moet transparant gebeuren en mag dus geen limitaties op het ontwerp van de applicatie leggen.

hoezo zou files in een database een limitatie zijn voor (het ontwerp van) de applicatie?
Maar blijkbaar heb jij nog geen ervaring gehad met crashende servers waarbij je niks meer hebt aan je mooie redundant hd'tjes omdat de controller corrupte data heeft weg geschreven.
Je kan gewoon niet om periodieke backups heen.

[ Voor 38% gewijzigd door Erkens op 29-12-2005 14:56 ]

[Verwijderd]

rwb schreef op donderdag 29 december 2005 @ 14:50:
Dat je data veilig is en dat je in het geval van een brand of crash je data terug kunt krijgen.

In het geval van brand moet de data gebackupped zijn op een fysiek andere locatie, server mirroring lijkt me dan de oplossing. In het geval van een crash (ik denk dus nu dat je doelt op een hd crash) voldoet een geschikte raid configuratie.

[Verwijderd]

Erkens schreef op donderdag 29 december 2005 @ 14:54:
Data kunnen recoveren als er wat fout gaat, bijvoorbeeld een leuke crash van je server(s) waarmee je raid corrupt raakt.
Als je in een professionele omgeving alleen op raid vertrouwen als "backup" ben je niet slim bezig.
Om dit weer ontopic te halen, je hoeft dan alleen je applicatie opnieuw te deployen en je database terug te zetten en je bent weer online ipv eerst duizenden files te kopieren.

ik suggereer ook nergens dat je er bent met enkel een raid configuratie. Ik stel wel dat programma ontwerp laten afhangen van je backup methode verre van professioneel is.

en je maakt een beetje een rare vergelijking aangezien ongeacht welke methode je gebruikt je altijd je bestanden moet terug zetten. Of dat nu de "duizenden" zijn of die ene immens grote maakt voor de snelheid van de server productie klaar hebben niets uit.

Erkens schreef op donderdag 29 december 2005 @ 14:54:
hoezo zou files in een database een limitatie zijn voor (het ontwerp van) de applicatie?

Je laat de keuze om de bestanden in de database te stoppen afhangen van het feit welke backup methodiek je toepast. zondoende leg je een beperking op in het ontwerp van de applicatie

Erkens schreef op donderdag 29 december 2005 @ 14:54:
Maar blijkbaar heb jij nog geen ervaring [..]

Deze manier van discussieren geeft aan dat je door je argumenten heen bent. Als je het niet normaal kunt uitleggen waar de voor en nadelen zitten reageer dan niet.

[ Voor 29% gewijzigd door Verwijderd op 29-12-2005 15:06 ]

[Erkens]

Verwijderd schreef op donderdag 29 december 2005 @ 15:00:
ik suggereer ook nergens dat je er bent met enkel een raid configuratie. Ik stel wel dat programma ontwerp laten afhangen van je backup methode verre van professioneel is.

ben ik het niet mee eens, maar dat ligt meer aan het type applicatie
maar puur kiezen voor losse files omdat dat makkelijker is te maken is imo een slecht begin en geeft aan dat er niet over eventuele nadelen is nagedacht.

en je maakt een beetje een rare vergelijking aangezien ongeacht welke methode je gebruikt je altijd je bestanden moet terug zetten. Of dat nu de "duizenden" zijn of die ene immens grote maakt voor de snelheid van de server productie klaar hebben niets uit.

jawel dat maakt wel uit, kopieer maar eens duizenden kleine gifjes van de ene naar de andere directory, en vervolgens 1 grote file welke totaal dezelfde grote in bytes heeft En dat is alleen maar weer jouw puntje snelheid.
Met heel veel files zijn er nog tal van andere zaken die mis kunnen gaan zoals het kwijt raken van een file (om welke reden dan ook, vaak PEBCAK) waarbij je altijd weer een extra check moet doen in je applicatie om te zien of die file bestaat.
Ook zit je dan op gegeven moment tegen de limitaties van je filesystem aan over max aantal files in een directory.

[ Voor 7% gewijzigd door Erkens op 29-12-2005 15:06 ]

[Bosmonster]

Misschien heeft het wel beiden z'n voor- en nadelen?

Ondanks dat sommige mensen hier dit soort zaken nogal zwart-wit zien, zit de echte wereld wel eens een stuk complexer in elkaar..

[Verwijderd]

Erkens schreef op donderdag 29 december 2005 @ 15:05:
ben ik het niet mee eens, maar dat ligt meer aan het type applicatie
maar puur kiezen voor losse files omdat dat makkelijker is te maken is imo een slecht begin en geeft aan dat er niet over eventuele nadelen is nagedacht.

Jij tovert werkelijkwaar conclusies uit je mouw. Ik heb nergens gesproken over wat makkelijker te implementeren is De opmerking zelf is compleet irrelevant. Ik heb juist enkel gesproken over de voor en nadelen en welke mijns inziens mee moeten worden genomen in een dergelijke overweging.

Erkens schreef op donderdag 29 december 2005 @ 15:05:Met heel veel files zijn er nog tal van andere zaken die mis kunnen gaan zoals het kwijt raken van een file (om welke reden dan ook, vaak PEBCAK) waarbij je altijd weer een extra check moet doen in je applicatie om te zien of die file bestaat.
Ook zit je dan op gegeven moment tegen de limitaties van je filesystem aan over max aantal files in een directory.

Als het gevaar van het kwijtraken van een bestand een risico danwel een argument is verspreid ik dat risico graag over meerdere bestanden. Ik moet er niet aan denken dat mijn ene backup bestand corrupt raakt.

[Erkens]

Bosmonster schreef op donderdag 29 december 2005 @ 15:09:
Ondanks dat sommige mensen hier dit soort zaken nogal zwart-wit zien, zit de echte wereld wel eens een stuk complexer in elkaar..

met zo'n opmerking sluit je meteen alle vorm van discussie uit

Verwijderd schreef op donderdag 29 december 2005 @ 15:15:
Jij tovert werkelijkwaar conclusies uit je mouw. Ik heb nergens gesproken over wat makkelijker te implementeren is De opmerking zelf is compleet irrelevant. Ik heb juist enkel gesproken over de voor en nadelen en welke mijns inziens mee moeten worden genomen in een dergelijke overweging.

waar zeg ik dat dat mijn conclusie is

Als het gevaar van het kwijtraken van een bestand een risico danwel een argument is verspreid ik dat risico graag over meerdere bestanden. Ik moet er niet aan denken dat mijn ene backup bestand corrupt raakt.

offtopic:
backup's hoor je ook te verifieren

[Fuzzillogic]

Beetje off-topic allemaal hoor. Wat ik van de code van de TS zie blijkt dat het niet om een high-end geavanceerd webshop-app gaat dat volledig in OOP gemaakt is ofzo. Geen probleem, de KISS-aanpak is vaak de juiste Maar of de ene methode makkelijker te backuppen is dan de andere lijkt me niet relevant.

De oplossing voor zijn probleem is al gegeven, samen met wat argumenten om te kiezen voor DB dan wel FS opslag.

[Erkens]

Nexxennium schreef op donderdag 29 december 2005 @ 16:54:
Beetje off-topic allemaal hoor. Wat ik van de code van de TS zie blijkt dat het niet om een high-end geavanceerd webshop-app gaat dat volledig in OOP gemaakt is ofzo. Geen probleem, de KISS-aanpak is vaak de juiste Maar of de ene methode makkelijker te backuppen is dan de andere lijkt me niet relevant.

De oplossing voor zijn probleem is al gegeven, samen met wat argumenten om te kiezen voor DB dan wel FS opslag.

Conclusie we mogen niet verder discussieren over dat onderwerp? Wellicht dat er in de toekomst mensen naar dit topic komen via de search en dan is het handig als daar wat argumenten staan ipv "gebruik dit want dat andere zuigt!!!!11"

[t-x-m]

Je kunt natuurlijk ook voor een misschien iet wat complexere (tussen) methode kiezen, namelijk;

Je maakt een script en/of/en-dus-een beheer-module die een backup maakt van de database.
Dit script zoekt alle afbeeldingen-locaties/links die in de oude db zitten en plaatst deze echte afbeeldingen in een extra veld in de nieuwe backup database.

Er moet dan natuurlijk ook nog een backup-terugzet script komen.

Maar op die manier voorkom je ook inconsistentie!
Iets als dit lijkt me overigens ook geen overbodige in een (professionele) webshop