Database gebruiken of in mappen?

[GewoonNico]

Ik heb sinds kort een partywebsite gemaakt, hierop komen foto's van evenementen. (http://exilim-output.nl)

Binnenkort krijgen we een eigen server en ook een fotosysteem. Ik wil de foto's allemaal in een database plaatsen vanwege de snelheid. Ik weet alleen niet of dit wel zo efficient is en of de database hierdoor overbelast raakt.
Natuurlijk kan ik ze ook gewoon allemaal in mappen opslaan.


Wie kan mij helpen met de juiste keuze te maken.


De foto's zijn 100 a 200kb groot, en per week komen er zo'n 300 foto's.

Het gaat om de volgende foto's
http://www.people-and-dj.nl/foto%20-%2027-03-04.htm

Het gaat hierbij om PHP en een mysql database

[ Voor 12% gewijzigd door GewoonNico op 31-03-2004 08:29 ]

[pjvandesande]

In mappen lijkt mij beter. En je werkt toch gewoon met paths die je bijvoorbeeld uit de database leest. Dit werkt perfect, over images opslaan in de database zijn de meningen heel erg verdeelt over.

[DeverauX]

[rml][ Databases/ASP] Images in database op HD opslaan[/rml]

[gorgi_19]

PHP? MySQL Database? Afaik heeft PHP een vrij brakke of zelfs ontbrekende cache ondersteuning, dus lijkt mij in dit geval het opslaan op disk een betere optie en alleen de paden op slaan in de database.

[Verwijderd]

een andere factor die eventueel mee kan spelen waar je rekening mee moet houden is de security rondom de foto's, mag iedereen alle foto's zien? Binnen een db is de security (voor zover mijn ervaring reikt) makkelijker (misschien ook beter???) op te zetten dan bij het gebruik van het filesystem

[Creepy]

Verwijderd schreef op 31 maart 2004 @ 11:29:
een andere factor die eventueel mee kan spelen waar je rekening mee moet houden is de security rondom de foto's, mag iedereen alle foto's zien? Binnen een db is de security (voor zover mijn ervaring reikt) makkelijker (misschien ook beter???) op te zetten dan bij het gebruik van het filesystem

Vanuit PHP is dit net zo makkelijk te regelen (passtrough met foto's BUITEN je webroot). Een .htaccess bestand o.i.d. kan eventueel ook.

Welke extra security denk je dat een DB toevoegt?

[Verwijderd]

extra is misschien niet het juiste woord, maar je kan binnen een db volgens mij wel beter met users en roles werken en rechten geven op foto's en categorieën waar foto's inzitten. Maar goed zoals ik al zei: ik heb niet echt ervaring om zoiets op te zetten op een filesystem icm .htaccess oid

[edit]
doordat ik geen ervaring heb met filesystem en user/roles kan het zijn dat er geblaat staat... probeer alleen bij de topic starter aan te duiden datie misschien ook met security rekening moet houden...

[ Voor 29% gewijzigd door Verwijderd op 31-03-2004 11:41 ]

[lost95]

Verwijderd schreef op 31 maart 2004 @ 11:39:
extra is misschien niet het juiste woord, maar je kan binnen een db volgens mij wel beter met users en roles werken en rechten geven op foto's en categorieën waar foto's inzitten. Maar goed zoals ik al zei: ik heb niet echt ervaring om zoiets op te zetten op een filesystem icm .htaccess oid

[edit]
doordat ik geen ervaring heb met filesystem en user/roles kan het zijn dat er geblaat staat... probeer alleen bij de topic starter aan te duiden datie misschien ook met security rekening moet houden...

Ik denk dat je dat los van elkaar moet zien. Je images moeten denk ik toch op een of andere manier op een pagina serveren. Op die pagina kan je rechten regelen (en die rechten kan je wel via DB laten lopen).

Maar TS zegt 300 foto's per week. Is het uit upload oogpunt dan ook niet makkelijkers/sneller om het op disk te zetten ipv in een DB.

[Verwijderd]

lost95 schreef op 31 maart 2004 @ 12:04:
Is het uit upload oogpunt dan ook niet makkelijkers/sneller om het op disk te zetten ipv in een DB.

Dat denk ik wel...

[gorgi_19]

Verwijderd schreef op 31 maart 2004 @ 12:05:
[...]

Dat denk ik wel...

Niet per definitie, geziende mogelijkheden van PHP nu wel. Geen idee wat de toekomstige ontwikkelingen binnen PHP 5 zullen zijn.

[GewoonNico]

Ik vind het nog steeds een lastige keuze,

Ik krijg zojuist te horen dat ook een bestel system op de website komt. Zodat je je foto kunt bestellen en laten afdrukken. In dit geval is het makkelijk om met id's te werken(database)

Ook alleen leden mogen de foto's bekijken (ik werk met sessies) dus dan is het ook weer makkelijk om te werken met een database.

Ik heb nog een aantal vraagjes:
- Is een database sneller met laden, zoals ik vaker hoor?
- Raakt de database niet overbelast met al die foto's?

De website trekt momenteel per dag ongeveer 10 gig aan foto's

[ripexx]

partypas schreef op 06 april 2004 @ 10:58:
Ik vind het nog steeds een lastige keuze,

Valt wel mee

Ik krijg zojuist te horen dat ook een bestel system op de website komt. Zodat je je foto kunt bestellen en laten afdrukken. In dit geval is het makkelijk om met id's te werken(database)

Prima, een tabel met foto_id en path/filename

Ook alleen leden mogen de foto's bekijken (ik werk met sessies) dus dan is het ook weer makkelijk om te werken met een database.

Foto's opslaan buiten je webroot en dmv passthru enz beschikbaar maken

Ik heb nog een aantal vraagjes:
- Is een database sneller met laden, zoals ik vaker hoor?
- Raakt de database niet overbelast met al die foto's?

File system is sneller dan database en linux heeft een redelijk caching systeem, dus dat zit wel goed. Daarnaast is het wel zo dat je database behoorlijk groeit per week. Denk aan 30-60MB per week volgens jouw gegevens. Nu is dat opzich geen probleem maar mysql werkt het beste bij eenvoud.

De website trekt momenteel per dag ongeveer 10 gig aan foto's

Maak dan een test script wat de vergelijking doet, maar zorg er dan wel voor dat je dataset van database wel vergelijkbaar is.

Nogmaals welke explicite reden heb je om een database te gebruiken voor de opslag van je images.

[jpwaag]

als je een ge MD5()de naam voor je foto's gebruikt heb je het probleem dat mensen random foto's gaan downloaden ook zo goed als opgelost. Die naam moet je dan natuurlijk in je DB opslaan.