Grote aantallen plaatjes

[WH-Tim]

Bij een profielensite bijvoorbeeld, is het daar slimmer om de geuploade plaatjes in de database te zetten (BLOB als ik me niet vergis), of is het slimmer om

<?php
$sNaam = md5sum($sPlaatje);
?>

te doen en het plaatje gewoon in de $webroot/images/ te zetten ($webroot/images/$sNaam.jpg)?

[Triloxigen]

Plaatje in de database zetten heeft gen enkele zin en raad ik je daarom ook af.
Het vervuilt je database en maakt hem onnodig groot.

[PlanPro]

De redenatie waarom het de database vervuilt als je de plaatjes in de database zet kan ik niet helemaal volgen.

Als alle andere informatie van de gebruiker al wel in de database staat kan het plaatje daar ook bijgeblobt worden. Als je MS SQL server gebruikt dan maakt het nauwelijks in performance uit. Het grote voordeel van de plaatjes in je database blijft dat als record verwijderd wordt of gebruiker past plaatje aan alles bijgewerkt is. (consistentie)

[froggie]

Wanneer je gebruik maakt van MySQL en een flink aantal records met binaries hebt dan ga je dat zeker merken.
Ik zou gewoon het plaatje ergens in de webroot wegzetten en het pad opslaan in het record van de betreffende persoon. Het is niet zo'n heel groot probleem om dat consistent te houden.

[Triloxigen]

Bijkomend ding is dat nu ieder plaatje geparsed moet worden.
Dat is dus een bijkomend nadelig gevolg, als je weinig plaatje sne weinig bezoekers hebt maakt dit niet gek veel uit.
Maar bij iets als ene profielen site kan dit hard gaan.

[HBCS]

ik heb de zelfde vraag als ts
ik heb ook een 2 tal sites met meer dan 2000 foto's
die is erg traag met laden om dat te versnellen wilde ik het ook in een database hebben maar mij lukte het niet
dus als de ts een oplossing gemaild of via pm krijgd houd ik mij aanbevolen

[Stefan Mensink]

Het handigst heb ik het volgende ervargen:

- Het basissysteem werkt op basis van SQL
- De afbeeldingen sla je bijv. op in een ../images/ directory op basis van het row-id in de images-tabel.

Eventueel kan je er nog voor kiezen om een ../images-scaled/ directory erbij aan te maken waar de geschaalde afbeeldingen staan. Het voor elk request scalen (met bijv. gd) kost ongelooflijk veel meer power dan dat eenmalig te doen.

[Triloxigen]

Origineel geplaatst door HBCS
ik heb de zelfde vraag als ts
ik heb ook een 2 tal sites met meer dan 2000 foto's
die is erg traag met laden om dat te versnellen wilde ik het ook in een database hebben maar mij lukte het niet
dus als de ts een oplossing gemaild of via pm krijgd houd ik mij aanbevolen

Uiteraard versnelt dit het niet.
Bij een link hoeft alleen de link uit de database gehaald te worden en dan wordt de rest clientside afgehandeld.
Als het plaatje in de database staat moet het plaatje eerst uit de database gehaald worden, daarna moet ht geparsed worden door bijv. PHP en dan kan de client het pas afhandelen.

[mguilmot]

Op onze profielensite hebben wij 2200 users in totaal, aantal foto's: iets meer dan 10.000.

Deze staan gewoon onder fotos/username. In de db staat enkel de naam van de foto (bvb mijnfoto.jpg) die bij welke user past. Tabel met 2 veldjes dus

[WH-Tim]

wat ik tot nu toe heb gedaan met fotosystemen is de md5sum gepakt en die als md5sum.$ext opgeslagen, maar bij een profielensite zoals hierboven aangegeven is dit inderdaad ivm consistentie niet aan te raden(1 user verwijdert hem en de andere gebruiker had hetzelfde plaatje op zijn profiel), dus denk ik wel dat ik md5($user).md5sum(plaatje).$ext ga gebruiken, maar ik krijg het niet voor mekaar om die plaatjes buiten de webroot te zetten (../images/) .. waarschijnlijk iets met de rechten ofzo
Thumbnails gebruik ik zobiezo, al is het alleen maar al om datatraffic te besparen

[V. Kleijnendorst]

Waarom een md5() en niet gewoon het insert_id() van de rij?
MD5 maakt niets uniek, je zit alleen met een langere string.

[WH-Tim]

Origineel geplaatst door V. Kleijnendors
Waarom een md5() en niet gewoon het insert_id() van de rij?
MD5 maakt niets uniek, je zit alleen met een langere string.

is ook goed mogelijk

[lifeforms]

Waarom een md5() en niet gewoon het insert_id() van de rij?

Dan kan een sluwe gebruiker de foto's aftellen en allemaal downloaden, 1.jpg 2.jpg etc

[V. Kleijnendorst]

Wat is het probleem van het downloaden van thumbs als die ook gewoon op een pagina staan?

Als je het wilt beveiligen, dan zet je ze in een map buiten de webroot en haal je ze met een PHP scriptje op. De bestandsnaam md5-en is ook niet direct veilig. Pak een willekeurig nummer, md5 het en probeer het als bestandsnaam. Werkt het, dan kun je een lager of hoger nummer md5-en en ook die downloaden, etc, etc.

[lifeforms]

Dat moet TS weten. Het kan zijn dat hij geld vraagt voor het zien van grote versies van pics, dat profiles (deels) prive kunnen zijn, etc.

Daarom md5 je ook niet op nummer alleen, maar je doet er bijvoorbeeld een rekensommetje op en plakt er bijvoorbeeld een paar geheime strings voor en achter.

Het kan natuurlijk zijn dat de privacy van de plaatjes niet zo belangrijk is voor TS, maar zoals mijn collega Ali zegt, "als je er maar over hebt nagedacht"

De plaatjes via een PHP-scriptje serveren is een goed idee, dan kun je cookies, memberstatus e.d. live checken. Voor de load is dat op zich geen pretje maar het heeft zeker voordelen.