/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
MySQL og billeder.
Fra : Søren


Dato : 15-02-02 09:18

Jeg skal lave en database over nogle ejendomme i MySQL og selve indhold og
opbygningen af databasen er ikke det store problem, men når jeg kalder
oplysningerne frem om en bestemt ejendom vil jeg også gerne have mulighed
for at se et billed af ejendommen. Jeg har i forvejen en række billeder,
hvor en stor del er læst digitalt ind og er som .jpg filer nogle få som .bmp
filer. Hvordan håndtere jeg billeder i MySQL for jeg kan vel ikke sætte dem
ind i en tabel ?

Jeg anvender MySQL, har jdbc driver da jeg vil tilgå databasen med java.
Operativsystemet er win xp.

Venlig hilsen
Søren



 
 
Troels Arvin (15-02-2002)
Kommentar
Fra : Troels Arvin


Dato : 15-02-02 11:21

On Fri, 15 Feb 2002 09:18:23 +0100, "Søren" <sorenh@gmx.net> wrote:

> Hvordan håndtere jeg billeder i MySQL for jeg
> kan vel ikke sætte dem ind i en tabel ?

Du kan i og for sig sagtens have endog vældigt store billeder liggende i
en database. I MySQL ville man benytte BIGBLOB datatypen.

Alternativet er kun at have filnavne liggende i databasen, som så
refererer til filer på filsystemet, som kan ses af folk på webbet.

Første metode kræver en eller anden form for caching system; ellers
bliver det meget tungt selv ved behærsket trafik. Hvor jeg arbejder
benytter vi en såkaldt reverse proxy (også benævnt "http accelerator")
til dette.

--
Greetings from Troels Arvin, Copenhagen, Denmark

Mogens Meier Christe~ (15-02-2002)
Kommentar
Fra : Mogens Meier Christe~


Dato : 15-02-02 23:19

"Troels Arvin" <troels@arvin.dk> wrote in message
news:a4ine8$enf$1@sunsite.dk...

> Du kan i og for sig sagtens have endog vældigt store billeder liggende i
> en database. I MySQL ville man benytte BIGBLOB datatypen.

IMHO er det misforstået udnyttelse af databasen. Det er det mest "rene" men
også det mest ineffektive.

> Alternativet er kun at have filnavne liggende i databasen, som så
> refererer til filer på filsystemet, som kan ses af folk på webbet.

Det var sådan jeg ville anbefale det. Det er dog ikke så "database-korrekt":
Billederne kan ikke hentes via databasen alene. Jeg synes dog at når det
drejer sig om webdesign at der må komme en vis del af virkelighed ind i
database-designet på et tidspunkt ;)

> Første metode kræver en eller anden form for caching system; ellers
> bliver det meget tungt selv ved behærsket trafik. Hvor jeg arbejder
> benytter vi en såkaldt reverse proxy (også benævnt "http accelerator")
> til dette.

Hmm, med mine dynamisk generede billeder er det da nok bare at sende f.eks.

Header('Cache-Control: max-age=604800, must-revalidate');

604800 er vildt mange sekunder, men det skyldes den måde jeg laver det på:
Jeg kan garantere at et billede med en bestemt URI ikke på nogen måde bliver
ændret med mindre dets "filnavn" bliver.

Jeg lærte det ved at skimme http://www.mnot.net/cache_docs/#CONTROL - som
jeg kan anbefale!


--
Mvh. Mogens
B.Sc. i datalogi. Søger IT-job på Fyn!
www.momech.dk



Troels Arvin (19-02-2002)
Kommentar
Fra : Troels Arvin


Dato : 19-02-02 09:33

On Fri, 15 Feb 2002 23:19:21 +0100, "Mogens Meier Christensen"
<mmc@nospam.dk> wrote:

> Hmm, med mine dynamisk generede billeder er det da nok bare at sende
> f.eks.
>
> Header('Cache-Control: max-age=604800, must-revalidate');

Fint, men du har misforstået pointen med en reverse proxy, AKA
"HTTP-accelerator". Formålet med en sådan er så at sige at gennemtvinge
caching mellem web-server og web-client. Derfor er det ikke nødvendigvis
"nok" at gøre, som du skriver; det kommer an på éns setup og hvor man
ønsker de forskellige delprocesser løst. _Hvis_ man vælger at proppe
billeder i databasen er det - som jeg skrev - afgørende at få aflastet
web-serveren, så den ikke hele tiden skal stå og request'e nogle
potientielt meget store dataklumper.

> Jeg kan garantere at et billede med en bestemt URI ikke på nogen måde
> bliver ændret med mindre dets "filnavn" bliver.

I så fald er der ingen grund til "must-revalidate".

- Og hvis man vælger at benytte "must-revalidate" bør behov for HTTP
validatorer i øvrigt nævnes, se afsnit 13.3 på
http://rfc.sunsite.dk/rfc/rfc2616.html
Ellers bliver "must-revalidate" reduceret til i praksis at
betyde "no-cache", så vidt jeg forstår HTTP-protokollen.


FUT -> dk.edb.internet.webdesign.serverside

--
Greetings from Troels Arvin, Copenhagen, Denmark

Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408928
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste