Archief - PHP: afbeelding uit database

Vraagje: Hoe haal ik met PHP een afbeelding uit mijn database, en hoe steek ik een afbeelding erin.
Ik heb namelijk een formulier gemaakt, waarmee men een paar velden kan invullen en ook evenuteel een afbeelding erbij kan posten. Maar ik weet niet hoe ik deze afbeelding in mijn database kan opslaan of eruit halen. Iemand een oplossing?


2de vraag: hoe kan ik uit een veld enkel het Jaargetal halen?


Merci alvast

Greetz

1. Hier klikken.

2. Bedoel je met dat veld een veld in je formulier, of een veld in je database ? Bij beiden speelt het een rol hoe een datum daar wordt ingegeven.

afbeeldingen mag je toch niet steken in database?
toch enkel de link?

(wegens veel te traag)

Mogen is veel gezegd. Blob -> binary field. Het is mogelijk maar ik zou het niet meteen doen.

Best uw afbeelding uploaden naar ne bepaalde folder en de link daarnaartoe bewaren in uw mysql

njah, das zo een typische webdevelopers discussie he...

Iedereen is daar zo hard tegen, tegen die 'blobs' voor binaire bestandne in uw db. Ikzelf steek ook altijd links naar de file in de db.

Maar uiteindelijk.
Blobs hebben ook wel veel voordelen eigelijk.
* Meestal is het sneller uit de database, dan uit een folder in het filesysteem. Raar maar waar wijzen benchmarks da uit blijkbaar. Denk eerlijk gezegd da het ni veel ga schelen. (ge moet natuurlijk ook ni 'select * from tableMet500000Images' gaan doen he)

* gemakkelijker om te backuppen (enkel de db backuppen). En geen problemen bij het verplaatsen van mappen, fouten bij het overzetten van een image, ... ) aangezien het links zijn anders he.

* Gemakkelijker om uw 'integriteit' te behouden: files verwijderen bij het verwijderen van uw record. Eigeijk is dees ook wel dike zever, want da doet ge zelf, via een goede database en code.

* Naar het schijnt zouden uw bestanden minder plaats innemen in de database, dan puur in een folder.

Volges mij makat het totaal ni uit.
Maar ik zet ook links, puur en alleen omdat iedereen het 'afraadt'. Terwijl niemand daar blijkbaar echt goede redenen voor blijkt te hebben.
En zo krijgde zo ne vieze cirklel

Als het bij images blijft zal dit idd nog wel lukken.
Ik heb ook al altijd alles opgeslagen in filesystem, er van overtuigd geweest dat dat de beste oplossing was, maar misschien moet ik dat nog maar eens opnieuw overwegen.

Mogelijk nadeel dat ik zie als je een grote selectie bestandformaten gaat toelaten : hoe ga je je header mime types correct zetten, zelfs browsers doen maar een gok ernaar afhankelijk van de extensie bij het uploaden, en dat kan van browser tot browser schillen. Voor embedded video die in alle browsers correct afspeelt enzo lijkt mij dat wel eens problemen te kunnen geven, moest het niet zo zijn : go ahead.

infeite zou je nu zelfs uw image links niet meer in de db mogen opslaan maar in een xml file, zodat ge niet telkens een connectie moet maken met de database...
database is en blijft enkele voor data, niet voor afbeeldingen en zo, maar zoals PsyKi zeg, dit blijft een discussie die niet opgelost zal raken

PsyKi zei:

Maar uiteindelijk.
Blobs hebben ook wel veel voordelen eigelijk.
* Meestal is het sneller uit de database, dan uit een folder in het filesysteem. Raar maar waar wijzen benchmarks da uit blijkbaar. Denk eerlijk gezegd da het ni veel ga schelen. (ge moet natuurlijk ook ni 'select * from tableMet500000Images' gaan doen he)

* gemakkelijker om te backuppen (enkel de db backuppen). En geen problemen bij het verplaatsen van mappen, fouten bij het overzetten van een image, ... ) aangezien het links zijn anders he.

* Gemakkelijker om uw 'integriteit' te behouden: files verwijderen bij het verwijderen van uw record. Eigeijk is dees ook wel dike zever, want da doet ge zelf, via een goede database en code.

* Naar het schijnt zouden uw bestanden minder plaats innemen in de database, dan puur in een folder.

Klik om te vergroten...

uw eerste en laatste argument kan ek nogal moeilijk geloven, aangezien de database uiteindelijk ook wel zen data ruw in het filesystem opslaat en daar dan nog een layer tussenzit.

killgore zei:

uw eerste en laatste argument kan ek nogal moeilijk geloven, aangezien de database uiteindelijk ook wel zen data ruw in het filesystem opslaat en daar dan nog een layer tussenzit.

Klik om te vergroten...

Voor laatste punt:
Kan volgens mij wel kloppen. Als je een bestand opslaat zit je nl steeds met overhead. Doe eens de test: maak een .txt bestandje aan op je WinXP/Win2k PC: het zal (indien std config) 4KB groot zijn/plaats innemen, ook al staat er geen letter text in.

Dit komt door de grootte van de (logische) blocks op je HD/partitie, en is dus ook afhankelijk van het gebruikte bestandsysteem.

Die blobs worden allemaal in dezelfde tabel opgeslagen = 1 file (nuja, 3, but you get the point), dus maximaal verlies is hier 4KB ongeacht het aantal files je toevoegd..


Voor eerste punt:
vind ik ook raar, maar ik bedenk wel: je moet sowiezo de connectie maken met de DB om de link in het filessystem op te vragen.

stel
je hebt alles geupload naar

/images/map1/
en
/images/map1/thumbs


via welke code kan je dan de thumbs laten tonen in een html pagina?

<tr><td><img src="

en dan iets als een PHP lus? until EOF?


(als je alles mooi benaamd, zoals 1.jpg, 2.jpg, ...)

blackrabbit zei:

Voor laatste punt:
Kan volgens mij wel kloppen. Als je een bestand opslaat zit je nl steeds met overhead. Doe eens de test: maak een .txt bestandje aan op je WinXP/Win2k PC: het zal (indien std config) 4KB groot zijn/plaats innemen, ook al staat er geen letter text in.

Dit komt door de grootte van de (logische) blocks op je HD/partitie, en is dus ook afhankelijk van het gebruikte bestandsysteem.

Die blobs worden allemaal in dezelfde tabel opgeslagen = 1 file (nuja, 3, but you get the point), dus maximaal verlies is hier 4KB ongeacht het aantal files je toevoegd..

Klik om te vergroten...

Dat is enkel zo aangezien je geen rekening houdt met het feit dat een DB intern doorgaans ook met pages gaat werken. Dat de fragmentatie van BLOBs kleiner is zal dus enkel kloppen indien :
a). de DB geen pages gebruikt voor BLOBs (wat elke bewerking op de DB gigantisch gaat vertragen) of
b). de DB zijn pages voor BLOBs kleiner zijn dan de paginagrootte van het filesystem (en/of de clustersize van het medium) waarop je de data gaat opslaan


Het eerste punt, dat een DB sneller zou zijn om de data op te halen zou mij ten zeerste verwonderen, die benchmarks zullen wellicht niet degelijk zijn opgesteld. Het laden van de BLOB uit de DB is op zich nl. al trager dan het rechtstreeks uitlezen van een bestand op het filesystem (er moet op z'n minst 1 seek extra gebeuren).

KoenDK zei:

stel
je hebt alles geupload naar

/images/map1/
en
/images/map1/thumbs


via welke code kan je dan de thumbs laten tonen in een html pagina?

<tr><td><img src="

en dan iets als een PHP lus? until EOF?


(als je alles mooi benaamd, zoals 1.jpg, 2.jpg, ...)

Klik om te vergroten...

als je geen links opgeslagen hebt in een db gebruik je http://php.net/open_dir
en anders gebruik je je opgeslagen links uit de db natuurlijk (aanrader!)

edit:
nog vergeten te antwoorden op de thread zelf
2 redenen om ze NIET in de db zelf op te slaan:

- Als je meerdere malen dezelfde afbeelding gebruikt voor verschillende records dan is enkel de link ernaar hetzelfde en heb je het bestand zelf maar 1 keer staan. Als je daartegen je afbeeldingen in de db zelf opslaat en je hebt bv 10 records met dezelfde afbeelding dan zit je met 10x dezelfde data, nutteloze plaatsverspilling imo.

- Vroeger was er een trend bij hosting bedrijven om de db ruimte te gaan beperken op bv 10Mb (waarde is relatief). Voor tekst is dit vrij veel, je kan al een hoop data opslaan. Ga je daarnaast je afbeeldingen ook in je db gaan plaatsen zal je 10Mb rap vol zitten. Tegenwoordig is dat probleem wel wat uit de mist. Ze gaan nu gewoon je db grootte gaan meerekenen in je totale hosting ruimte.