afbeeldingen opslaan

[ZeroXT]

Beste mensen

Ik heb een enkele korte vraag met misschien wel een lang antwoord. Voor een wallpaper site, is het dan handiger om de wallpapers fysiek op de harde schijf op te slaan of is het juist beter im deze allemaal in de database op te slaan?

de wallpapers zijn tussen de 200kb en 1.4mb groot en ik wilde graag jullie meningen weten!

[himlims_]

ik vind 1mb+ voor een wallpaper/achtergrond van de website too much, maar dat is mijn persoonlijke mening

ik zou ze in een folder plaatsen ipv in je DB, daar is een DB niet voor gemaakt (kan wel, maar is niet ideaal in mijn beleving)

[IceM]

Ik neem aan dat hij met een wallpaper site een site bedoeld waarop mensen wallpapers kunnen downloaden...

[himlims_]

onjuist geinterpeteerd

ik weet niet zeker maar ....; is het in dat geval niet 'veiliger' om via DB te doen? staat 't op server/folder is via eoa scriptje zo jouw pagina te kopieren ...

[DennusB]

himlims_ schreef op vrijdag 19 augustus 2011 @ 07:51:
onjuist geinterpeteerd

ik weet niet zeker maar ....; is het in dat geval niet 'veiliger' om via DB te doen? staat 't op server/folder is via eoa scriptje zo jouw pagina te kopieren ...

Ja en niet als het in de database staat en dat gewoon word uitgelezen ?
Het gaat hier denk ik vooral om performance, en als je een leuke storage hebt zou ik lekker voor de schijf gaan met eventueel caching in je webserver

[ibmos2warp]

DennusB schreef op vrijdag 19 augustus 2011 @ 08:05:
[...]


Ja en niet als het in de database staat en dat gewoon word uitgelezen ?
Het gaat hier denk ik vooral om performance, en als je een leuke storage hebt zou ik lekker voor de schijf gaan met eventueel caching in je webserver

Inderdaad, in de db opslaan doe je als je bijvoorbeeld bitwise wilt vergelijken. Als het gewoon bestanden voorschotelen is kan je dat veel sneller doen door gewoon gebruik te maken van je file system en die het laten afhandelen (daar is het ook voor bedoelt ).
Directories / bestanden zijn ook op allerlei manieren te beveiligen dat er niet zomaar gedownload kan worden. Heb je ook tutorials voor

[Remus]

ibmos2warp schreef op vrijdag 19 augustus 2011 @ 08:21:
[...]

Inderdaad, in de db opslaan doe je als je bijvoorbeeld bitwise wilt vergelijken. Als het gewoon bestanden voorschotelen is kan je dat veel sneller doen door gewoon gebruik te maken van je file system en die het laten afhandelen (daar is het ook voor bedoelt ).
Directories / bestanden zijn ook op allerlei manieren te beveiligen dat er niet zomaar gedownload kan worden. Heb je ook tutorials voor

Aan de andere kant: opslaan in de database betekent dat je alles op één plek hebt en backups dus en de (meta)data en de bestanden in één keer heeft.

Overigens bitwise vergelijken van blobs doe je bijna nooit, ook niet in de database.

[Naranya]

Als je flink wilt groeien gebruik dan een CDN voor je static content.

[DennusB]

Remus schreef op vrijdag 19 augustus 2011 @ 08:29:
[...]

Aan de andere kant: opslaan in de database betekent dat je alles op één plek hebt en backups dus en de (meta)data en de bestanden in één keer heeft.

Overigens bitwise vergelijken van blobs doe je bijna nooit, ook niet in de database.

Ja dat klopt wel, maar een database om plaatjes van 1mb t/m 5mb op te gaan halen is niet echt handig. Dan heb je op den duur een heel flink database cluster nodig. Terwijl je dit prima met een file system af kan handelen, en waar nodig je nog caching in kan zetten Stuk sneller en rendabeler!

[McKaamos]

Kleine tip, enigzinds verwant aan het opslagverhaal: Zorg voor een script dat de afbeelding kan resizen. Zorg voor 2 high reso versies van het plaatje in widescreen en 4:3 aspect ratio (of alleen widescreen, gezien iedereen dat heeft en 4:3 optioneel) en laat de wallpaper runtime scalen naar wat de gebruiker wil hebben.
Scheelt een hoop opslagruimte zodat je geen tig resoluties moet gaan opslaan.
Plus dat cachen dan nog sneller wordt omdat je dan steeds maar 1 plaatje aanspreekt en er dus maar 1 gecached hoeft te worden.

[Melodic Metal]

Wallpapers van boven de 1 MB zou ik alleen ter download aanbieden, niet voor weergave in de site.
Ook is het niet slim om het in de database op te slaan, ik zie nog wel eens sites die dat doen.
En even een backup of een mirror van de site draaien voor development is dan echt niet leuk.
Die databases kunnen makkelijk 1+ GB worden, dus effe een export script draaien lukt vaak al niet meer.

Laat de bestanden gewoon op de hardeschijf, gebruik apache om deeplinking(?) tegen te gaan.
Gebruik veel thumbnails en de database om de bestandpaden op te slaan.

[YopY]

Stiekem is een filesystem ook gewoon een database, en dan eentje die een stuk eenvoudiger werkt dan het weg proberen te schrijven van een bestand in een database.

Gewoon op FS opslaan, da's vele malen eenvoudiger. Een webserver is ook veel beter in het serveren van statische bestanden.

[Nibble]

Ik zou ze opslaan op een fileserver en de filenaam bv een hashtag of ander uniek id geven(niet het db id) en die koppelen in de database met de bijbehorende meta informatie. Dat is volgens mij ook de netste manier. Op die manier kun je je bestandgegevens altijd uitbreiden en zit je ook niet snel met dubbele bestandsnamen.

Suc6!

[Cartman!]

McKaamos schreef op vrijdag 19 augustus 2011 @ 08:50:
en laat de wallpaper runtime scalen naar wat de gebruiker wil hebben. Scheelt een hoop opslagruimte zodat je geen tig resoluties moet gaan opslaan. Plus dat cachen dan nog sneller wordt omdat je dan steeds maar 1 plaatje aanspreekt en er dus maar 1 gecached hoeft te worden.

Oneens, over het algemeen is opslag een stuk goedkoper dan rekenkracht. Als iemand een variant opvraagt die je nog niet op je filesystem hebt zou ik em genereren en daarna opslaan (cache), de 2e keer pak je meteen de cache-versie.

[joppybt]

YopY schreef op vrijdag 19 augustus 2011 @ 09:32:
Stiekem is een filesystem ook gewoon een database, en dan eentje die een stuk eenvoudiger werkt dan het weg proberen te schrijven van een bestand in een database.

Eindelijk iemand die het snapt.

[418O2]

Cartman! schreef op vrijdag 19 augustus 2011 @ 10:35:
[...]

Oneens, over het algemeen is opslag een stuk goedkoper dan rekenkracht. Als iemand een variant opvraagt die je nog niet op je filesystem hebt zou ik em genereren en daarna opslaan (cache), de 2e keer pak je meteen de cache-versie.

Slaat sowieso nergens op. Wallpapers kan je niet 'blind' croppen, resizen wil wel, maar croppen kan je niet blind.

Je kan de bestanden gewoon opslaan op een deel waartoe nooit iemand toegang heeft. Deze lees je dan uit met een script en dat gooi je naar de client. Die ziet dan nooit een bestandslocatie.

[Cartman!]

Wie heeft het over croppen?

[Osiris]

Catch22, als enige in 't hele topic

himlims_ schreef op vrijdag 19 augustus 2011 @ 07:51:
ik weet niet zeker maar ....; is het in dat geval niet 'veiliger' om via DB te doen? staat 't op server/folder is via eoa scriptje zo jouw pagina te kopieren ...

Je kunt altijd probleemloos een scriptje gebruiken om alle 'veiligheidschecks' te doen, maar het alsnog van het FS halen i.p.v. uit een DB.

[ Voor 112% gewijzigd door Osiris op 19-08-2011 11:41 ]