Fil eller BLOB?
Martin Bekkelund
Jeg holder på med en applikasjon som blant annet skal kunne lagre bilder
knyttet til en post i en database. Kunne derfor tenke meg innspill på
fordeler og ulemper med følgende alternativer:
1. Lagre bildene som en BLOB i databasen
2. Lagre bildene i et filsystem med en referanse fra databasen
--
Martin Bekkelund, Røyken, Buskerud, Norway
http://www.bekkelund.net/
The road to hell is paved with spacer gifs and nested tables
Lasse G. Dahl
> Jeg holder på med en applikasjon som blant annet skal kunne lagre bilder
> knyttet til en post i en database. Kunne derfor tenke meg innspill på
> fordeler og ulemper med følgende alternativer:
>
> 1. Lagre bildene som en BLOB i databasen
> 2. Lagre bildene i et filsystem med en referanse fra databasen
Altså, jeg er ikke noen databasemann utover at jeg misbruker dem mye, og
har et par vekttall i normalisering. Men jeg greier ikke å fri meg fra
idéen om at å lagre bilder i databaser er unødig komplisert. Hovedgrunnen
til dette, er vel at jeg ikke ser fordelen.
Fordelen med en database, er at alle data er lett tilgjengelige og mulige
å finne ut fra en rekke kriterier (altså ulike spørringer). Et bilde
inneholder ikke noen slik informasjon. Det tar derimot enormt stor plass,
og en database hvor bildene er lagret som data, vil veldig mye fortere
oppnå uhåndterlig størrelse enn hvis du lad dem ligge i filer.
--
Lasse G. Dahl <URL: http://www.lassedahl.com/ >
I'm a citizen of Legoland travellin' incommunicado
Martin Bekkelund
> Altså, jeg er ikke noen databasemann utover at jeg misbruker dem mye, og
> har et par vekttall i normalisering.
Omtrent som meg, da. :-)
> Men jeg greier ikke å fri meg fra
> idéen om at å lagre bilder i databaser er unødig komplisert. Hovedgrunnen
> til dette, er vel at jeg ikke ser fordelen.
Omtrent som meg, her også. På jobben har vi derimot eksperimentert med
begge varianter, og jeg klarer ikke å finne det ene alternativet bedre
enn det andre, ettersom vi ikke har hatt nevneverdige problemer med noen
av alternativene. Derav spørsmålet.
> Fordelen med en database, er at alle data er lett tilgjengelige og mulige
> å finne ut fra en rekke kriterier (altså ulike spørringer). Et bilde
> inneholder ikke noen slik informasjon. Det tar derimot enormt stor plass,
> og en database hvor bildene er lagret som data, vil veldig mye fortere
> oppnå uhåndterlig størrelse enn hvis du lad dem ligge i filer.
Dette med tilgjengelighet er et godt poeng i seg selv, ettersom et bilde
ikke kan spørres etter, annet enn ved å spørre etter data i andre felter
i oppføringen.
For enkelte kunder vil størrelse være en utfordring, hvilket leder meg
inn på et annet spørsmål (som for øvrig hører hjemme i en annen gruppe).
Er det vanlig praksis å ha begrensning på databasestørrelser hos ISP-er?
De jeg har vært borti bruker kun totalstørrelse, dvs. e-post, filer,
database sett under ett. For andre kunder er dette ikke relevant, da de
allerede har databaser på flere hundre GB.
Tor Arne Hegna
> Hei,
>
> Jeg holder på med en applikasjon som blant annet skal kunne lagre bilder
> knyttet til en post i en database. Kunne derfor tenke meg innspill på
> fordeler og ulemper med følgende alternativer:
>
> 1. Lagre bildene som en BLOB i databasen
Er vel kun å foretrekke på grunn av replikering, backup og copyright
siden å linke til filen er noe mer trikki.
> 2. Lagre bildene i et filsystem med en referanse fra databasen
Mitt førstevalg siden basen ikke blir enorm ( = tregt system) og filene
er lett tilgjengelig for endring etter at de er registrert (ja, det
hender at man trenger det).
--
Tor Arne Hegna
Info: http://www.newsergalleriet.no/user.php?name=Tor+Arne+Hegna
Kim Steinhaug
> Hei,
>
> Jeg holder på med en applikasjon som blant annet skal kunne lagre bilder
> knyttet til en post i en database. Kunne derfor tenke meg innspill på
> fordeler og ulemper med følgende alternativer:
>
> 1. Lagre bildene som en BLOB i databasen
> 2. Lagre bildene i et filsystem med en referanse fra databasen
På samme måte som det kan være spennende å URLencode alle filer inn i en
og samme PHP fil som man plukker ut de grafiske elementene med
parametre, så blir en dette tregt straks man har mye besøk eller store
mengder grafiske elementer.
Eks, jeg hadde en plugin for en WYSIWYG som inneholdt 500 smileys, dette
var upraktisk for en rekke forhandlere å laste opp når det kom nye
versjoner ettersom det tok lang tid. Så tenkte jeg at det kunne være
smart å koke sammen hele filstrukturen til en og samme PHP fil, hvor man
hentet frem bildene noe slik :
bildearkiv.php?fil=001.gif
Iden virker bra, men straks man skal hente mange bilder merket jeg at
PHP ikke var gunstig til å skanne gjennom en 2MB fil hver bidige gang
for å hente frem det lille bildet.
jeg vil tro at om du lager et PHP script som spytter ut dem korrekte
headere mtå cache og slikt, muligens også med ETAG - at man kan
forhindre at man må slå opp i databasen hver bidige gang man skal se
bildet. PHP har en tendens til å ikke cache, noe som betyr en enorm load
på MySQL databasen, og får man da besøk på siden er det kjørt.
Fordelen med MySQL og BLOB så langt jeg kan se er bare en :
Om applikasjonen du skal benytte er tiljgengelig fra flere brukere (les.
installasjoner fordelt på forskjellige webhotell / servere) så er det
praktisk - ettersom alle har da tilgang til samme bildemateriale.
Jeg ville uansett ha laget en cache løsning som trakk ut alle bildene
fra databasen og lagret dem som rene filer i en egen cache mappe. Dette
kan man også gjøre rimelig dynamisk via Apache og 404, hvor man har en
mappe som ved 404 slår opp i databasen og henter ut filen. På denne
måten er man sikret at alle nettlesere cacher filen korrekt, samt man
slipper å generere cachen manuellt.
Håper du ble klokere av dette.
Kim Steinhaug
http://www.steinhaug.no/