goede middag,
Weet iemand een tut over hoe ik foto in en uit een databse kan krijgen.
hans
1.233 views
Er staat er toch een op phphulp? Gebruik de zoekfunctie...
Wanneer jij de foto als een BLOB in de database hebt opgeslagen en wilt weergeven op jouw site, zul je de juiste header() moeten meegeven.
Voorbeeldje:
<?php
// ophalen en fetchen van de data en dan:
header("Content-type: image/jpg");
echo $row['image'];
?>
Nu krijgt de browser eerst de header, weet dus wat er aan gaat komen, en dan de foto.
Voorbeeldje:
<?php
// ophalen en fetchen van de data en dan:
header("Content-type: image/jpg");
echo $row['image'];
?>
Nu krijgt de browser eerst de header, weet dus wat er aan gaat komen, en dan de foto.
als je hem letterlijk IN de database zet, kan je beter stoppen met zoeken. Dat is best fout wat je met een database kan doen namelijk.
@Terence: Ben ik niet volledig met je eens. Een beetje database (dus géén MySQL!) kan uitstekend foto's opslaan en ze ook nog eens snel ter beschikking stellen. Ik heb echter wel het idee dat dit pas een goed plan is wanneer je vele duizenden tot miljoenen foto's wilt gaan opslaan.
Tot die tijd zou ik gewoon een verwijzing naar de foto in de database opslaan en de foto zelf in een directory zetten.
Tot die tijd zou ik gewoon een verwijzing naar de foto in de database opslaan en de foto zelf in een directory zetten.
het gaat om +/- 4000 foto,s
Die zou ik ín de database zetten en niet in (diverse) directories. Gebruik dan wel een goede database zoals bv. PostgreSQL.rientsma schreef op 10.03.2007 15:10het gaat om +/- 4000 foto,s
Het maken van een backup is dan ook eenvoudiger, een backup van de database is voldoende. Daar staat tenslotte alles in.
Nadeel is wel dat je database enorm veel ruimte in gaat nemen, waardoor het snel backuppen van je database wat ingewikkelder word. En bij kleine hostingpakketjes ga je tegen wat beperkingen aanlopen.
@Arjan: Ruimte in de directory of ruimte in de database maakt niet zo veel verschil. Dit maakt dus voor het hostingpakket dus ook niet uit.
Het backuppen moet je wel even goed naar kijken, dat kan inderdaad een flinke aanslag op de server zijn. De tijdsduur zal voornamelijk liggen aan de omvang van de database (in MB/GB/TB) en de snelheid van de server. In de meest ideale situatie gebruik je database replicatie met een andere server. Mocht de master er uit klappen, dan gaat de slave gewoon verder. Zie hiervoor Slony.
4000 x 2,5 MB (formaat van de foto's die ik schiet in hoogste .jpeg-kwaliteit) = 10000 MB => 10 GB. 10 GB is voor PostgreSQL geen enkel probleem, stelt nog niets voor, 1 tabel kan tot 32 TB groot zijn. De omvang van de database is onbeperkt. Althans, 'onbeperkt' vanuit PostgreSQL gezien, je moet natuurlijk wel voldoende schijfruimte hebben :p
Het backuppen moet je wel even goed naar kijken, dat kan inderdaad een flinke aanslag op de server zijn. De tijdsduur zal voornamelijk liggen aan de omvang van de database (in MB/GB/TB) en de snelheid van de server. In de meest ideale situatie gebruik je database replicatie met een andere server. Mocht de master er uit klappen, dan gaat de slave gewoon verder. Zie hiervoor Slony.
4000 x 2,5 MB (formaat van de foto's die ik schiet in hoogste .jpeg-kwaliteit) = 10000 MB => 10 GB. 10 GB is voor PostgreSQL geen enkel probleem, stelt nog niets voor, 1 tabel kan tot 32 TB groot zijn. De omvang van de database is onbeperkt. Althans, 'onbeperkt' vanuit PostgreSQL gezien, je moet natuurlijk wel voldoende schijfruimte hebben :p
Ik wil dit ook gaan doen voor een project waar ik al een poosje mee bezig ben. Dit heb ik toen ook hier gepost. Ik kreeg toen veel reacties dat mysql hier niet voor gebouwd is en dat dit absoluut geen goede oplossing was.
Ik vond pas een artikel met resultaten over images in een database, met de snelheden e.d. Dit was getest met een java based systeem, maar de resultaten waren dermate goed (kwam overeen met een file server) dat ik dit zeker nog overweeg.
@Frank: Is vooral het backuppen een probleem? Wat denk jij hier over?
Ik vond pas een artikel met resultaten over images in een database, met de snelheden e.d. Dit was getest met een java based systeem, maar de resultaten waren dermate goed (kwam overeen met een file server) dat ik dit zeker nog overweeg.
@Frank: Is vooral het backuppen een probleem? Wat denk jij hier over?
@Crispijn: Wanneer jij op een sharedhosting-pakket 10GB wilt gaan backuppen en dat vervolgens ook nog eens veilig wilt stellen op een andere server, dan heb je over het algemeen wel een probleem. Er is dan vrijwel altijd te weinig processorkracht om even snel een backup te maken en te weinig bandbreedte om de backup naar een andere server te sturen. (backup op dezelfde server is zinloos) Het duurt dus veel te lang en al die tijd loop jij een risico.
Wanneer je met databasa-replicatie aan de slag gaat, heb je permanent een actuele backup van het origineel. Per INSERT, UPDATE of DELETE-query wordt er maar een beperkte hoeveel data van de master naar de slave (= backup) gestuurd. Uiteraard stuur je de data wel via SSL naar de andere server, anders zou iedere halfgare idioot jouw data kunnen verkloten.
Wanneer je met databasa-replicatie aan de slag gaat, heb je permanent een actuele backup van het origineel. Per INSERT, UPDATE of DELETE-query wordt er maar een beperkte hoeveel data van de master naar de slave (= backup) gestuurd. Uiteraard stuur je de data wel via SSL naar de andere server, anders zou iedere halfgare idioot jouw data kunnen verkloten.