Hej.

Har ett problem som jag behöver hjälp med att klura ut bästa lösningen på.

Det har diskuterats flera gånger här på Pellesoft fast jag är ändå inte riktigt säker...

Jag undrar hur bör man spara filer i ett system. Som fysiska filer på webservern (ev en extern maskin) och bara information om filerna i DB, eller binärt i databasen.
(SQL-Server)

Naturligtvis är det en fråga om mängd, storlek mm. Samtidigt en fråga om vilken typ av åtkomst man behöver...

Klart är att ADO.NET eller ADO kommer att vara inblandade då det handlar om en webapplikation. Klart är också att det kommer vara många filer inblandade. De skall vara sökbara mm.

Vad finns det för fördelar/nackdelar med lagring i databasen?
Blir HELA databasen seg för att EN tablell innehåller filerna?
(Sökningar kan man göra in relaterade tabeller)
Erfarenheter av backup, administration mm??

Det är ett stort vägval känner jag. Minsta lilla erfarenhet är av intresse.
Hur skall jag tänka??

//fredda

Som jag ser det handlar det helt och hållet om vad behoven är i just detta specifika fall. Bägge sätten har sin för- och nackdelar, och jag anser att de som hävdar att man aldrig ska lagra binära filer i databasen har fel.

Frågor som du ska ställa dig är t ex:

- Ska filerna backas upp? Isf, blir det en extra arbetsbörda för DBAn att filmässigt ta backup på filerna om de ligger utanför databasen, eller förenklar det hans jobb? Det beror helt på vad DBAn har för kunskaper samt framförallt vilka rättigheter som är inblandade.

- Hur ska filerna skyddas? Får de användare som har tillgång till maskinen även ha tillgång till filerna, eller är det helt styrt av användarna i databasen? Isf, blir det enklare att administrera säkerheten i systemet med allt i databasen eller blir det enklare med filerna utanför dbn?

- Hur mycket filer handlar det om? Finns det risk att den diskkapacitet som SQL Server har tillgång till inte räcker till pga att man lagrar filer i databasen? Naturligtvis ska du se till att lagra filerna smart även om du har dem i databasen, gärna på en egen disk, men det kan kanske ändå bli problem.

- Vilka administrativa arbeten kommer att utföras på maskinen? Vissa arbeten kan ta längre tid även om det bara är en tabell som innehåller filer.

Hela databasen kommer normalt inte att bli seg bara för att du lagrar binära filer i den, men om du inte gör det rätt kan det bli bekymmer. Ett exempel är om du lagrar filerna under samma diskcontroller som övriga databasen, då kan I/O bli lidande när du läser/skriver filerna. Lagrar du filerna utanför databasen måste du tänka på de transaktionella bitarna när du kör dina lagringar, men beroende på hur du gör en databasintegrerad lösning kan du förstås behöva det även i det fallet.

Mycket att tänka på, men det viktigaste är att göra det rätt vilket sätt du än väljer.

Tack för svaret!

Då är jag inte helt fel ute i alla fall.
Jag bestämmer mig för att lagra filerna i databasen.

Några fler idéer, kommentarer eller erfarenheter?? Någon?

//fredda

Jag tycker nog inte riktigt som Christofer..
Så gott som aldrig ska stora filer lagras i sqlservern.

Enda tillfället jag verkligen önskat att bilderna låg i databasen var när jag
skulle göra en dynamisk produktkatalog i Crystal Reports.

Eftersom CR inte klarar visa länkade bilder gick det åt skogen
och jag gjorde den slutligen i Excel istället. Tog betydligt längre tid och
var inte lika snyggt layoutmässigt men å andra sidan fick jag in tuffare
funktioner eftersom jag kunde programmera vba.

Men varför tycker jag så här:

För det första är det inget vidare smidigt att ladda in bilder i databasen
Till detta måste byggas nån form av gränssnitt för den stackars
användaren. Synd om den som helt plötsligt får ett nytt produktsortiment
eller nya bilder på samma produkter som ska bytas ut.

Det här kan ju lösas väldigt smidigt genom t.ex. produktnummer i
databasen är samma som bildnamnet. Så har många leverantörer sina
bilder lagrade. Smidigt och lätt att byta ut.


Datastorleksmässigt bör man tänka sig noga för innan man slänger in en
massa stora filer i sqlservern. SQL är inte direkt kända för att spara på
utrymmet genom att pressa in så mycket som möjligt på varje page.

Men men.. Om man ändå vill ha bilder, dokument eller andra filer i sin
databas på ett blob fält. Tänk då på att skapa en SEPARAT tabell med
dessa objekt och referera till dom med ett nummer från din
kontaktpersonstabell, produkttabell eller vad det nu kan vara.

Annars blir det en himla massa information i ditt fina register och du
kommer lida rätt bra prestandamässigt.


Detta är vad jag tycker och tror. Vet gör jag ju inte riktigt så det
överlämnar jag till nästa talare..

Mvh
Rickard

Kommentar: Såg när jag läste lite noggrannare i Christofers inlägg att
han redan behandlat mina åsikter. Men det kan det väl vara på plats att
säga det igen.

> Så gott som aldrig ska stora filer lagras i sqlservern.

Precis den utgångspunkt jag tycker är fel, som sagt tycker jag det beror på många orsaker.

> För det första är det inget vidare smidigt att ladda in bilder i databasen

Nej, det är väl sant att det är inte så smidigt som att lägga in 'vanlig' data i den. Men det är inte så värst svårt heller iofs, framförallt inte med nyare versioner av ADO (>2.5).

> Till detta måste byggas nån form av gränssnitt för den stackars
> användaren. Synd om den som helt plötsligt får ett nytt produktsortiment
> eller nya bilder på samma produkter som ska bytas ut.

Förstår inte riktigt vad du menar? Om du menar om användaren ska lägga in en massa produkter med bilder på en gång så tycker jag det är ointressant. Antingen får han väl göra det manuellt produkt för produkt (ingen skillnad om man har bilder eller ej, i eller utanför databasen), eller så har man något importverktyg som importerar alla produkter från den datakälla produktsortimentet finns i. Även i det andra fallet kvittar det väl om bilder ligger i eler utanför databasen, det hanteras ju av importverktuget så för användaren kvittar det rätt mycket.

> Det här kan ju lösas väldigt smidigt genom t.ex. produktnummer i
> databasen är samma som bildnamnet. Så har många leverantörer sina
> bilder lagrade. Smidigt och lätt att byta ut.

Visst, snygg och enkel lösning, men den kan vara oduglig beroende på de möjliga krav jag nämner ovan, ex. backup-strategi samt säkerhetsmässigt. Tänk på att det behöver inte vara just bilder, kan ju t ex vara word-filer eller andra binära filer som kanske inte ska kunna editeras av vem som helst med filaccess till maskinen.

> Datastorleksmässigt bör man tänka sig noga för innan man slänger in
> en massa stora filer i sqlservern. SQL är inte direkt kända för att spara
> på utrymmet genom att pressa in så mycket som möjligt på varje page.

Que? SQL Server sparar så många rader den får plats med på varje sida. Det har inget med blobs att göra. Har man en BLOB-kolumn i en tabell så lagras en 16-bytes pekare i denna kolumn på varje rad (undantaget om man utnyttjar 'text in row'-alternativet i SQL Server 2000). Så visst, varje rad blir 16 byte större och därmed får man inte plats med lika många rader per sida, men å andra sidan lär väl en sökväg till en fil i filsystemet vara mer än 16 tecken lång.

> Men men.. Om man ändå vill ha bilder, dokument eller andra filer i sin
> databas på ett blob fält. Tänk då på att skapa en SEPARAT tabell med
> dessa objekt och referera till dom med ett nummer från din
> kontaktpersonstabell, produkttabell eller vad det nu kan vara.
> Annars blir det en himla massa information i ditt fina register och
> du kommer lida rätt bra prestandamässigt.

Nja, du behöver inte lida så där extremt hårt, som jag skrev ovan så lagras inte mer än en pekare till BLOBen tillsammans med övriga raden, så om man bara behöver den övriga datan för raden och låter bli att returnera BLOB-kolumnen så behöver man inte lida så hårt. Men dock, jag håller med dig, som jag skrev ovan bör man lagra dem i en egen tabell för att kunna ha denna i en egen filgrupp, för att i sin tur kunna ta backup på denna för sig. Annars kan du förlora prestanda t ex när du ska ta backup eftersom denna kan ta längre tid då.

Observera att jag med detta inlägg inte vill säga att man alltid eller ens oftast ska binära filer i databasen istället för bara sökvägen, jag vill bara påpeka att det finns situationer då man ska lagra dem i databasen och det finns situationer då de bör lagras utanför databasen.

Under tiden jag skrev detta kom jag på ett annat fall där man behöver lagra filerna i databasen. Om man använder Full-Text Search så kan man i SQL Server 2000 indexera annat än ren textdata, även vissa binära format kan indexeras (word, excel, powerpoint, pdf m fl). Men för att göra detta ska den binära datan med texten man vill indexera ligga i databasen, den kan inte läsa i filer i filsystemet.