---

Er der nogen her der har erfaringer med hvad fordele og ulemper der er
ved at have billeder i database. I forhold til bare at gemme filnavnet
i databasen og ligge filen på disken.

---

"Phreak" <phreak@mail1.stofanet.dk> wrote in message
news:3b23dc63.1791165@news.stofanet.dk...
> Er der nogen her der har erfaringer med hvad fordele og ulemper der er
> ved at have billeder i database. I forhold til bare at gemme filnavnet
> i databasen og ligge filen på disken.

Det kommer meget an på hvilken database det er:

Hvis det er et ægte DBMS så er det helt fint at have billeder i databasen.
Hvis det derimod er ms-acceess som er filbaseret så er det lidt noget skidt,
da databasen bliver alt for tung at håndtere.

--
Jakob Andersen
FAQ for webdesign gruppen på
<http://www.usenet.dk/oss/dk.edb.internet.webdesign>
"Det er rart at være vigtig, men det er vigtigere at være rar "

---

Phreak wrote:
>
> Er der nogen her der har erfaringer med hvad fordele og ulemper der er
> ved at have billeder i database. I forhold til bare at gemme filnavnet
> i databasen og ligge filen på disken.

Jeg kan ikke komme på en eneste fordel ved at have dem i databasen.

--
Lauritz

---

"Lauritz Jensen" <lauritz2@hotmail.com> wrote in message
news:3B23DD4D.5A33EEF0@hotmail.com...
> Jeg kan ikke komme på en eneste fordel ved at have dem i databasen.

Dovenskab?

--
Jakob Andersen
FAQ for webdesign gruppen på
<http://www.usenet.dk/oss/dk.edb.internet.webdesign>
"Det er rart at være vigtig, men det er vigtigere at være rar "

---

Jakob Andersen wrote:
>
> "Lauritz Jensen" <lauritz2@hotmail.com> wrote:
> > Jeg kan ikke komme på en eneste fordel ved at have dem i databasen.
>
> Dovenskab?

Det er da mere besværligt, at lægge filen ind og efterfølgende hive den
ud igeng og sende del til browseren, end bare at gemme den på disken og
linke til den... så det kan da ikke være dovenskab?

--
Lauritz

---

"Lauritz Jensen" <lauritz2@hotmail.com> wrote in message
news:3B23E1D2.82709370@hotmail.com...
> Det er da mere besværligt, at lægge filen ind og efterfølgende hive den
> ud igeng og sende del til browseren, end bare at gemme den på disken og
> linke til den... så det kan da ikke være dovenskab?

Ok.. Når man først har lavet det en gang før så virker det... Men der er
lige den hvis et billede via et CMS system skal slettes så skal det både
slettes i databasen og filsystemet.

--
Jakob Andersen
FAQ for webdesign gruppen på
<http://www.usenet.dk/oss/dk.edb.internet.webdesign>
"Det er rart at være vigtig, men det er vigtigere at være rar "

---

"Lauritz Jensen" <lauritz2@hotmail.com> wrote in message
news:3B23DD4D.5A33EEF0@hotmail.com...
> Phreak wrote:
> >
> > Er der nogen her der har erfaringer med hvad fordele og ulemper der er
> > ved at have billeder i database. I forhold til bare at gemme filnavnet
> > i databasen og ligge filen på disken.
>
> Jeg kan ikke komme på en eneste fordel ved at have dem i databasen.
>
Forestil dig et scenarie med flere webservere og en bagvedliggende sql
server
(Fysiske maskiner)
Hvor ville du lægge dine images - fx billeder i et varekatalog, der bliver
opdateret jævnligt?

mvh/Peter Lykkegaard

---

Peter Lykkegaard wrote:
>
> Forestil dig et scenarie med flere webservere og en bagvedliggende
> sql server
> (Fysiske maskiner)
> Hvor ville du lægge dine images - fx billeder i et varekatalog, der
> bliver opdateret jævnligt?

I filsystemet og så enten lave noget replikering af filerne eller lægge
dem på en fælles filserver. Det vil simpelthen være synd og skam at
bruge database serveren til det. Den har som regel travlt nok i forvejen
og den kan jo ikke så nemt skaleres ud (kun op).

--
Lauritz

---

"Lauritz Jensen" <lauritz2@hotmail.com> wrote in message
news:3B24B1F8.D3C4DC25@hotmail.com...
> Peter Lykkegaard wrote:
> >
> > Forestil dig et scenarie med flere webservere og en bagvedliggende
> > sql server
> > (Fysiske maskiner)
> > Hvor ville du lægge dine images - fx billeder i et varekatalog, der
> > bliver opdateret jævnligt?
>
> I filsystemet og så enten lave noget replikering af filerne eller lægge
> dem på en fælles filserver.

Med hesyntagen til at IUSR_<servername> (en local account på webserveren)
skal have adgang til den faelles filserver
dvs man kommer til at bruge en domain account til anonymous access for at få
det til at virke

>Det vil simpelthen være synd og skam at
> bruge database serveren til det. Den har som regel travlt nok i forvejen
> og den kan jo ikke så nemt skaleres ud (kun op).
>
MSSQL arbejder ganske fint med images/dokumenter osv
Har ikke oplevet problemer i den retning
Men det er da klart at den skal arbejde lidt mere for føden

mvh/Peter Lykkegaard

---

Peter Lykkegaard wrote:
> "Lauritz Jensen" wrote:
> > Peter Lykkegaard wrote:
> > > Forestil dig et scenarie med flere webservere og en
> > > bagvedliggende sql server
> >
> > I filsystemet og så enten lave noget replikering af filerne
> > eller lægge dem på en fælles filserver.
>
> Med hesyntagen til at IUSR_<servername> (en local account på
> webserveren) skal have adgang til den faelles filserver
> dvs man kommer til at bruge en domain account til anonymous access
> for at få det til at virke

Det skulle heller ikke give problemer bag firewallen, at åbne for guest
på et enkelt share, men replikeringen behøver jo heller ikke at
autentificere via nt kontoer.

> >Det vil simpelthen være synd og skam at
> > bruge database serveren til det. Den har som regel travlt nok i
> > forvejen og den kan jo ikke så nemt skaleres ud (kun op).
> >
> MSSQL arbejder ganske fint med images/dokumenter osv
> Har ikke oplevet problemer i den retning
> Men det er da klart at den skal arbejde lidt mere for føden

Spild af god server (og transaction log).

--
Lauritz

---

"Lauritz Jensen" <lauritz2@hotmail.com> skrev i en meddelelse
news:3B24D906.5D130B51@hotmail.com...
> Peter Lykkegaard wrote:
> > "Lauritz Jensen" wrote:
> > > Peter Lykkegaard wrote:
> > > > Forestil dig et scenarie med flere webservere og en
> > > > bagvedliggende sql server
> > >
> > > I filsystemet og så enten lave noget replikering af filerne
> > > eller lægge dem på en fælles filserver.
[KLIP]
> > >Det vil simpelthen være synd og skam at
> > > bruge database serveren til det. Den har som regel travlt nok i
> > > forvejen og den kan jo ikke så nemt skaleres ud (kun op).
> > >
> > MSSQL arbejder ganske fint med images/dokumenter osv
> > Har ikke oplevet problemer i den retning
> > Men det er da klart at den skal arbejde lidt mere for føden
>
> Spild af god server (og transaction log).

Hej Lauritz
Du bør ikke afvise det at ligge billeder i SQL serveren så kategorisk:
- Hvad med synkronisering og transaktionsstyring ?
- Hvis din database crasher og skal restores hvordan får du så genoprettet
det rigtige billede af de filer du havde til at ligge på dine frontends ?
- Hvad hvis den ene frontend er nede i 5 minutter og der i mellemtiden er
blevet oprettet 500 billeder og slettet 300 andre ?
- Hvad med at installere en helt ny frontend ?
- Hvordan tager du backup af dine billeder ?
- Hvordan vil du lave begrænset adgang til visse billeder baseret på et
brugersystem du har i databasen ? (security through obscurity ?)

Ved at ligge billederne i SQL Server får du alle de ting forærende:
- clustering og failover
- transaktioner og synkronisering
- backuprutine er på plads
- mulighed for fuld kontrol over adgang til enkelte billeder

Alt i alt kommer det an på hvor vigtige dine billeder er for dig, hvis
ændringer i billederne er ensartede og du mener at have styr på at replikere
dem rundt på dine frontends, og det ikke er den store kartastrofe hvis der
mangler et enkelt billede eller der er et det ikke bliver slettet, så
repliker dem rundt på dine frontends.

Hvis du vil være 100% sikker på ensartethed og dataintegritet, eller har
brug for fuld kontrol over adgangen til dine billeder så er det en god idé
at kaste dem i din SQL Server.

I min erfaring kan man hurtigt komme til at bruge mange ressourcer på
udviklere og driftsproblemer pga. replikeringsfejl, for slet ikke at snakke
om hvad brugeren synes om at der mangler billeder på ens website.
Når man ser det i lyset af at det du i realiteten forsøger at gøre er at
simulere en database, med ensartet backup, den samme kopi af billederne
tilgængeligt på alle frontends kan det give god mening at investere lidt
ekstra i SQL serveren. Det kan nemt sparer både tid og penge og gøre din
løsning mere robust, for slet ikke at snakke om at spare dine udviklere og
driftsfolk for dybest set meningsløst arbejde. Den ekstra tid kunne fx
bruges på at optimere databasen og data access laget.

Det kommer alt sammen an på opgaven og pengepungen.

MVH
Allan Ebdrup, 10-4 ApS
www.ti-fire.dk

---

"Allan Ebdrup" <ebdrup@ti-fire.dk> wrote in message
news:9g4ong$qhq$1@news.cybercity.dk...
>
> Hej Lauritz

[Klip - en længere fin forklaring]

> Det kommer alt sammen an på opgaven og pengepungen.
>
Lauritz vil gerne over åen efter vand for at slippe for at lægge binære
filer ind på et RDMS

Typisk kan et RDBMS være mere effektivt end et native WinNT filsystem
Der samme gør sig muligvis ikke gældende i forb med *nix miljøer

Som du selv er inde på, så er spørgsmålet blot at skalere databaseserveren
så den kan det den skal bruges til

mvh/Peter Lykkegaard

---

Peter Lykkegaard wrote:
>
> Som du selv er inde på, så er spørgsmålet blot at skalere
> databaseserveren så den kan det den skal bruges til

Det er det, der er hele humlen. Du kan jo ikke "blot" skalere
databaseserveren, for den kan kun skaleres op og ikke ud. Webservere kan
du have ligeså mange af, du har lyst til.

--
Lauritz

---

"Lauritz Jensen" <lauritz2@hotmail.com> skrev i en meddelelse
news:3B2664D9.CCF7531@hotmail.com...
> Peter Lykkegaard wrote:
> >
> > Som du selv er inde på, så er spørgsmålet blot at skalere
> > databaseserveren så den kan det den skal bruges til
>
> Det er det, der er hele humlen. Du kan jo ikke "blot" skalere
> databaseserveren, for den kan kun skaleres op og ikke ud. Webservere kan
> du have ligeså mange af, du har lyst til.

Det ville nu være ret nemt at partitionere billederne. Eller sågar proppe
dem på en seperat server, med COM+ har du stadig transaktioner og rollback.

MVH
Allan Ebdrup

---

Allan Ebdrup wrote:
> "Lauritz Jensen" <lauritz2@hotmail.com> skrev:
> > Peter Lykkegaard wrote:
> > > MSSQL arbejder ganske fint med images/dokumenter osv
> > > Har ikke oplevet problemer i den retning
> > > Men det er da klart at den skal arbejde lidt mere for føden
> >
> > Spild af god server (og transaction log).
>
> Du bør ikke afvise det at ligge billeder i SQL serveren så
> kategorisk:
Det gør jeg egentlig heller ikke. Jeg siger, at jeg ikke kan komme på
situationer, hvor det er en fordel at lægge billeder i databasen (altså
hvor fordelene ikke bliver udvejet af ulemperne).

> - Hvad med synkronisering og transaktionsstyring ?
Som jeg har sagt før i tråden, så ville jeg enten replikerer filerne
mellem webserverene eller lægge dem på en filserver. Jeg kan ikke se
hvor der opstår problemer, da de fleste filsystemer kan låse filer, der
skrives til og billederne typiskt vil blive læst mere end de bliver
skrevet.

> - Hvis din database crasher og skal restores hvordan får du så
> genoprettet det rigtige billede af de filer du havde til at ligge
> på dine frontends ?
Det er jo netop kun et problem hvis dine billeder ligger i databasen.

> - Hvad hvis den ene frontend er nede i 5 minutter og der i
> mellemtiden er blevet oprettet 500 billeder og slettet 300 andre ?
Som jeg har sagt før i tråden, så ville jeg enten replikerer filerne
mellem webserverene eller lægge dem på en filserver. Jeg kan ikke se
hvor der opstår problemer. (har du læst mine indlæg?)

> - Hvad med at installere en helt ny frontend ?
Som jeg har sagt før i tråden, så ville jeg enten replikerer filerne
mellem webserverene eller lægge dem på en filserver. Jeg kan ikke se
hvor der opstår problemer, da de fleste filsystemer kan låse filer, der
skrives til og billederne typiskt vil blive læst mere end de bliver
skrevet.

> - Hvordan tager du backup af dine billeder ?
Her virker det som om du antyder, at du ikke ved hvordan man tager
backup af en disk. Det ved du sikkert godt, så hvorfor spørger du?

> - Hvordan vil du lave begrænset adgang til visse billeder baseret
> på et brugersystem du har i databasen ? (security through
> obscurity ?)
Enten via obscurity (passwords er jo blot en anden form for obscurity)
eller via et script, der kan læse filerne fra et katalog uden for
webroden og sende dem til browseren (der findes asp komponenter til det,
hvis man ikke vil ud i isapi extentions, og samtidigt vil have lidt fart
på).

> Ved at ligge billederne i SQL Server får du alle de ting forærende:
> - clustering og failover
> - transaktioner og synkronisering
> - backuprutine er på plads
> - mulighed for fuld kontrol over adgang til enkelte billeder
Jo tak, jeg ved godt hvad en database er. Men det er blot ikke en stor
nok fordel i dette tilfælde.

> Det kommer alt sammen an på opgaven og pengepungen.
Ja, og hvor mange besøgene du har.

--
Lauritz

---

"Lauritz Jensen" <lauritz2@hotmail.com> skrev i en meddelelse
news:3B26640E.15364B5F@hotmail.com...
> Allan Ebdrup wrote:
[KLIP]
> > - Hvad med synkronisering og transaktionsstyring ?
> Som jeg har sagt før i tråden, så ville jeg enten replikerer filerne
> mellem webserverene eller lægge dem på en filserver. Jeg kan ikke se
> hvor der opstår problemer, da de fleste filsystemer kan låse filer, der
> skrives til og billederne typiskt vil blive læst mere end de bliver
> skrevet.
Låsning af filsystemet er ikke nok, du har antaget ting om systemet. Hvad
med et system hvor brugeren selv opretter, opdaterer og sletter billeder?

> > - Hvis din database crasher og skal restores hvordan får du så
> > genoprettet det rigtige billede af de filer du havde til at ligge
> > på dine frontends ?
> Det er jo netop kun et problem hvis dine billeder ligger i databasen.
Nej, du har derimod for mange filer på dine frontends, filer der ikke er
referet i databasen. (med et "billede" mener jeg et snapshot af hvilke
billed-filer der ligger på serveren)

> > - Hvad hvis den ene frontend er nede i 5 minutter og der i
> > mellemtiden er blevet oprettet 500 billeder og slettet 300 andre ?
> Som jeg har sagt før i tråden, så ville jeg enten replikerer filerne
> mellem webserverene eller lægge dem på en filserver. Jeg kan ikke se
> hvor der opstår problemer. (har du læst mine indlæg?)

Lauritz, ja jeg har læst dine indlæg, men jeg kan godt se at du ikke er til
at hugge eller stikke i så jeg bliver nød til at udspecificere hvad jeg
mener:

1) En filserver giver single point of failure og er dyr, derudover giver du
din systemadministrator een ting mere at holde styr på og tage backup af.

2) Ved replikering har du problemer med transaktionsstyring, du har ikke
ACID som en database giver dig og derfor kan der opstå situationer hvor du
enten har filer liggende på en frontend der ikke er i databasen længere
eller hvor du har filer i database der ikke er på nogen frontend - det er
både logisk og indlysende. Spørgsmålet er om det er et problem man vil vælge
at leve med.

> > - Hvad med at installere en helt ny frontend ?
> Som jeg har sagt før i tråden, så ville jeg enten replikerer filerne
> mellem webserverene eller lægge dem på en filserver. Jeg kan ikke se
> hvor der opstår problemer, da de fleste filsystemer kan låse filer, der
> skrives til og billederne typiskt vil blive læst mere end de bliver
> skrevet.
Ekstra arbejde.

> > - Hvordan tager du backup af dine billeder ?
> Her virker det som om du antyder, at du ikke ved hvordan man tager
> backup af en disk. Det ved du sikkert godt, så hvorfor spørger du?

Jeg skrev måske så jeg trode det kunne læses mellem linierne men lad mig
udspecificere:
Hvis din database crasher og du restorer den får du ikke rullet dine filer
tilbage - det kan betyde at slettede filer bliver liggende på frontenden
eller at filen er forkert hvis det er blevet opdateret i mellemtiden. Der
kan opstå problemer med synkronisering mellem database og frontends.
Derudover kan der opstå situationer hvor replikering går i ged pga
netværksfejl, servernedbrud osv. og pludseligt mangler det nogle filer der
stadig ligger i databasen.

Hvi du lige har haft problemer med netværket og alle dine frontends, hvordan
ved du så hvilken frontend der har det rigtige sæt af filer? Eller hvad hvis
det rigtige sæt af filer er spredt ud på alle frontends og du i realiteten
bliver nød til at sammenstykke et billede fra alle frontends for at få noget
nøjagtigt ? Eller hvis der er fejl i nogle af filerne pga diskfejl, eller
.....

Du kan ikke være sikker på at få et fornuftigt billede gendannet - det kan
du med en SQL Server, og det koster ikke ekstra arbejde.

> > - Hvordan vil du lave begrænset adgang til visse billeder baseret
> > på et brugersystem du har i databasen ? (security through
> > obscurity ?)
> Enten via obscurity (passwords er jo blot en anden form for obscurity)
> eller via et script, der kan læse filerne fra et katalog uden for
> webroden og sende dem til browseren (der findes asp komponenter til det,
> hvis man ikke vil ud i isapi extentions, og samtidigt vil have lidt fart
> på).

Nu ligger SQL serveren som regel bag en firewall og dens sikkerhed er
(forhåbentligt) taget hånd om, at du slipper for at skrive et komponent er
også værd at tage med - slev om vi godt kan blive enige om at det ikke vejer
så tungt på vægtskålen.

> > Ved at ligge billederne i SQL Server får du alle de ting forærende:
> > - clustering og failover
> > - transaktioner og synkronisering
> > - backuprutine er på plads
> > - mulighed for fuld kontrol over adgang til enkelte billeder
> Jo tak, jeg ved godt hvad en database er. Men det er blot ikke en stor
> nok fordel i dette tilfælde.

Igen vil jeg sige at du ikke bør afvise det kategorisk, når den diskussion
vi har handler om to måder at gøre det samme på og der ikke er et
endegyldigt "svar" på hvilken metode der er den bedste.

> > Det kommer alt sammen an på opgaven og pengepungen.
> Ja, og hvor mange besøgene du har.

Det lyder somom vi begge taler om systemer med mange besøgende, så den køber
jeg ikke uden ydeligere argumenter.
På små systemer med en eller to servere (og kun een frontend) kan det
selvfølgeligt være meget nemt at ligge tingene på filsystemet.

At du sidder med et system hvor du mener at det giver god mening at
replikere billed-filer til frontends er jeg ikke i tvivl om, men du har ikke
argumenteret for at det er en god løsning udover postulater om et det er
dyrt at bruge en SQL server. Jeg fristes til at spørge: har du prøvet det ?
At ligge billeder på filsystemet er western metoden, den der skyder først
skyder bedst, de seriøse problemer opstår når man en enkelt gang rammer ved
siden af og man skal forklarer kunderne at der skal bruger en uges manuelt
arbejde for at gendanne et fornuftigt billede.

MVH
Allan Ebdrup

---

"Allan Ebdrup" <ebdrup@ti-fire.dk> wrote in message
news:9g5uen$2qjp$1@news.cybercity.dk...
> "Lauritz Jensen" <lauritz2@hotmail.com> skrev i en meddelelse
> news:3B26640E.15364B5F@hotmail.com...
> > Allan Ebdrup wrote:
> [KLIP]
> > > - Hvad med synkronisering og transaktionsstyring ?
> > Som jeg har sagt før i tråden, så ville jeg enten replikerer filerne
> > mellem webserverene eller lægge dem på en filserver. Jeg kan ikke se
> > hvor der opstår problemer, da de fleste filsystemer kan låse filer, der
> > skrives til og billederne typiskt vil blive læst mere end de bliver
> > skrevet.

> Låsning af filsystemet er ikke nok, du har antaget ting om systemet. Hvad
> med et system hvor brugeren selv opretter, opdaterer og sletter billeder?
>
Det kan være at vi alle har snakket lidt forbi hinanden her
Muligvis tænker Lauritz på de alm billeder der altid ligger og flyder på et
website
Her vil det være naturligt at have dem liggende i filsystemet på webserveren

Jeg snakker om systemer hvor brugerne uploader binære filer af forsk slags,
om det er billeder, film, grafik, tekstdokumenter er egentlig underordnet

Skulle man bruge replikering, så kræves det at maskinerne står og replikerer
konstant, og fx worddocs fylder som bekendt en del

Tager man et program som fx SuperOffice så lægges dokumenterne i filsystemet
Og det er efterfølgende et lille helvede at holde database og filsystem
synkront, også selvom det hele ligger på den samme server
Dette gøres primært ved at krydse fingre - ikke særligt spændende

Et andet scenario kunne fx være Exchange hvor vedhæftede filerne ligger i
databasen

Disse eksempler et brugt for overskuelighedens skyld og har såmæn ikke så
meget med ASP at gøre

Mht til at skalere MSSQL ud, så er der ganske fine værktøjer til at
replikere databaserne mellem flere servere
Et scenarie kunne være destinationer i forsk lande
Sætter dog lidt krav til WAN

mvh/Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hot.mail.com> skrev i en meddelelse
news:yODV6.19$DH.2172@news.get2net.dk...
> "Allan Ebdrup" <ebdrup@ti-fire.dk> wrote in message
> news:9g5uen$2qjp$1@news.cybercity.dk...
> > "Lauritz Jensen" <lauritz2@hotmail.com> skrev i en meddelelse
> > news:3B26640E.15364B5F@hotmail.com...
> > > Allan Ebdrup wrote:
> > [KLIP]
> > > > - Hvad med synkronisering og transaktionsstyring ?
> > > Som jeg har sagt før i tråden, så ville jeg enten replikerer filerne
> > > mellem webserverene eller lægge dem på en filserver. Jeg kan ikke se
> > > hvor der opstår problemer, da de fleste filsystemer kan låse filer,
der
> > > skrives til og billederne typiskt vil blive læst mere end de bliver
> > > skrevet.
>
> > Låsning af filsystemet er ikke nok, du har antaget ting om systemet.
Hvad
> > med et system hvor brugeren selv opretter, opdaterer og sletter
billeder?
> >
> Det kan være at vi alle har snakket lidt forbi hinanden her
> Muligvis tænker Lauritz på de alm billeder der altid ligger og flyder på
et
> website
> Her vil det være naturligt at have dem liggende i filsystemet på
webserveren
>
> Jeg snakker om systemer hvor brugerne uploader binære filer af forsk
slags,
> om det er billeder, film, grafik, tekstdokumenter er egentlig underordnet
>
> Skulle man bruge replikering, så kræves det at maskinerne står og
replikerer
> konstant, og fx worddocs fylder som bekendt en del

Hej Peter
For en god ordens skyld:
Ja, de alm.- billeder på et website vil nok aldrig kunne betale sig at ligge
i en database, de opdateres kontrolleret og "sjældent".
Ja, det er også rigtigt at vi sagtens kan tale om andre filtyper end bare
billeder når vi snakker om filer der med fordel kan ligges i SQL Server,
(jeg vill holde det så simpelt så muligt).
Ja, jeg taler også om applikationer hvor brugerne selv uploader filer, men
brugerne kan også være en flok in-house indtastere der fx indtaster annoncer
dagen lang og uploader billeder med disse.

MVH
Allan Ebdrup