---

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

---

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

---

"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

---

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