Lagre .doc- og .pdf-filer i MYSQL-database?

[Xqtor]

Jeg holder på å lage en enkel bug-database og tenkte jeg skulle ha med mulighet for å kunne lagre vedlegg, i tillegg til bare beskrivelse av en feil.

 

Er det noe som tilsier at man ikke burde lagre disse filene i en MySQL-database?

[-morten]

Så vidt jeg har fått med meg regnes det som dårlig praksis å lagre hele filer i databasen, fram for å lagre filene i filsystemet, og filnavnene i databasen. Men det er ikke sikkert det spiller så stor rolle i ditt tilfelle..

[ilpostino]

tror nok det å ha en peker til filen (filnavnet) i databasen for så å lagre selve filen på hardisken.

[ofredstie]

Jeg holder på å lage en enkel bug-database og tenkte jeg skulle ha med mulighet for å kunne lagre vedlegg, i tillegg til bare beskrivelse av en feil.

 

Er det noe som tilsier at man ikke burde lagre disse filene i en MySQL-database?

7363102[/snapback]

 

Backup/flytting av databasen blir enklere hvis du lagrer filene i databasen.

Med en gang du peker til eksterne filer (lagrer filnavnet) så beveger du deg bort fra prinsippet at en database skal være uavhengig fra andre filer/programmer/systemer.

(Si at alle filene blir lagret i mappen /db/bugs/, hvis du senere bestemmer deg for at filene egentligt burde lagres i /database/bugs/ så må alle filnavnene i databasen endres.)

M.a.o. så er det dårlig database-design å ikke lagre filene i databasen.

 

Det betyr ikke at det er raskere å kun lagre filnavnene, men database-systemer som Oracle, MS-SQL o.l. har avanserte metoder for å optimalisere henting og lagring av informasjon (database optimalisering) og man bør bruke disse metodene istedenfor å f.eks. lagre filene i eksterne mapper.

[Manfred]

Dårlig database-design å ikke lagre filene i databasen? Jeg får grøsninger bare jeg tenker på å skulle legge masse filer i databasen.

[ilpostino]

*snip*

 

her er en artikkel som ikke akkurat taler din sak. Av all den utdannelsen og praktisk erfaring jeg har så er dette første gangen jeg har hør tat det er god databasedesign å lagre filer direkte i databasen...

[Manfred]

...dessuten er det vel ingenting som tilsier at du skal lagre hele filstien i databasen? Jeg lagrer kun filnavn. Skal du ha det veldig enkelt å flytte på, kan du ha en systemtabell, som bl.a. inneholder filsti til opplastede bilder, og plutselig var det ikke så vanskelig å flytte alle filene likevel...

[roac]

Backup/flytting av databasen blir enklere hvis du lagrer filene i databasen.

Med en gang du peker til eksterne filer (lagrer filnavnet) så beveger du deg bort fra prinsippet at en database skal være uavhengig fra andre filer/programmer/systemer.

7385174[/snapback]

Mer viktig er kanksje likevel den negative konsekvensen: TTR (Time To Recover) øker drastisk ved databasecrash, siden du må restore alle dokumentene også. Det er ikke uten grunn at Microsoft SharePoint kan være et sant ... på enkelte områder, f eks backup/restore.

 

Og om noen skulle tenke på faren for at filer blir slettet på et filsystem: Det er forstatt lov til å sette rettigheter på filsystemet

[gxi]

En database og et filsystem har veldig mange likheter, i tillegg til at en vanlig SQL-databaseserver bruker filsystemet til lagring. I teorien er et filsystem og en database det samme, i.o.m at begge er laget for å lagre data. Filer er bare et begrep som gjør det lettere for brukeren å administrere sin database. En fil er på lik linje med omtrendt en hvilken som helst databasepost, en samlig med data. Jeg kan ikke se noe problem med dette, såfremst ressursene er tilgjengelig på databaseserveren. Det er gjerne en grunn til databaseservere er laget slik at de kan lagre flere GB med data.

[ofredstie]

her er en artikkel som ikke akkurat taler din sak.

 

Som sagt, det kan godt være at å kun lagre filnavnene i databasen er raskere, men det er dårlig database-design fordi databasen vil da ikke være "data independent".

M.a.o. så vil disse eksterne filene være utenfor databasen sin kontroll, hvis f.eks. en fil blir slettet så vil databasen "peke" til en fil som ikke eksisterer (med mindre man går inn op oppdaterer databasen (les: ekstra-arbeid)).

 

Ang. den artikkelen så synes jeg en del av argumentene mot å lagre filer i databasen er relativt svake:

 

- when your database really goes south, to the point where even the backup is useless, you still have the files on the filesystem (though their usefulness is questionable, depending on how much related data was kept in the database). Which is arguably better than losing all of your data *and* all of your files.

Dette blir bare for dumt, hvis hele databasen ryker så er det ett fett om du har filene eller ei.. du vil uannsett ha et stort problem. F.eks. si at dette er en database for et medisinsk system hvor x-ray bildene blir lagret eksternt, hvis man mister all data som er inni databasen så vil nok ofte disse bildene være totalt ubrukelige fordi man ikke vet hvilke db-innlegg de enkelte bildene er relatert til.

 

Siden man er inne på temaet backup:

Hvis man lagrer bildene inni databasen så trenger man å "kun" ta backup av selve databasen, slipper å måtte ta backup av databasen og et eksternt filsystem.

 

- with some databases, e.g. Access and MSDE, the data inside is limited to 2 GB (SQL Server Express 2005, as of July 2004, is planned to support 4 GB), whereas the file system is only restricted by the size of the volume. Also, most hosts charge a premium for SQL Server storage space, so in that case it would be cheaper to store them in the file system.

Jeg mener at Access ikke er en fullverdig database (kan ikke sammenliknes med Oracle, MS-SQL, PostgreSQL o.l.) og derfor blir det for dumt å dra dette inn i diskusjonen.

[ofredstie]

En database og et filsystem har veldig mange likheter, i tillegg til at en vanlig SQL-databaseserver bruker filsystemet til lagring. I teorien er et filsystem og en database det samme, i.o.m at begge er laget for å lagre data. Filer er bare et begrep som gjør det lettere for brukeren å administrere sin database. En fil er på lik linje med omtrendt en hvilken som helst databasepost, en samlig med data. Jeg kan ikke se noe problem med dette, såfremst ressursene er tilgjengelig på databaseserveren. Det er gjerne en grunn til databaseservere er laget slik at de kan lagre flere GB med data.

7393539[/snapback]

 

I teorien er ikke et filsystem og en database det samme fordi databasen tar seg av lagringen av informasjonen, ikke du. Den lagrer informasjonen i filer, det stemmer, men ikke en fil pr datapost, det er feil.

[gxi]

Spørsmålet er vel også, hvorfor skal databasen ryke? Er det ikke omtrendt like sansynlig at filsystemet også kan ryke?

[ofredstie]

Stemmer det, uannsett hva som ryker, så lenge man ikke har backup-løsninger skikkeligt implementert, så vil man ha et stort problem.

Endret 30. november 2006 av ofredstie

[roac]

Spørsmålet er vel også, hvorfor skal databasen ryke? Er det ikke omtrendt like sansynlig at filsystemet også kan ryke?

7393804[/snapback]

Med godt design vil filene og databasen ikke ligge på samme disk array, hvilket vil si at du sannsynligvis slipper med å restore en av delene, og derved får kortere restore tid.

[roac]

Som sagt, det kan godt være at å kun lagre filnavnene i databasen er raskere, men det er dårlig database-design fordi databasen vil da ikke være "data independent".

M.a.o. så vil disse eksterne filene være utenfor databasen sin kontroll, hvis f.eks. en fil blir slettet så vil databasen "peke" til en fil som ikke eksisterer (med mindre man går inn op oppdaterer databasen (les: ekstra-arbeid)).

7393756[/snapback]

Det er flere løsninger på dette. En del kan være at dette håndteres i applikasjonen, og hvis det f eks er en webapplikasjon så går det riktig så bra. En annen løsning på dette problemet (men som vel ikke fungerer i MySQL enda) er å la databasen ta seg av filhåndteringen. Det er fult mulig, og du får det beste fra begge verdener. Dette lar seg i hvert fall greit gjøre i SQL Server 2005 og såvidt jeg kan se i nyeste versjon av henholdsvis Oracle og DB2 også.

 

Ellers synes jeg det blir for dumt å snakke om at databaseserveren har kontroll i denne sammenhengen, for du har ingen måte å ivareta kontroll mot dokumentet som sådan, men mot dokumentets metadata. Dette gjelder samtlige databaseservere jeg har sett. Eneste unntak er evt bruk av datatypen xml i SQL Server 2005 eller DB2 9, men det blir jo noe litt annet igjen.

[ofredstie]

Med godt design vil filene og databasen ikke ligge på samme disk array, hvilket vil si at du sannsynligvis slipper med å restore en av delene, og derved får kortere restore tid.

7393863[/snapback]

Vel, det er derfor store databaser som Oracle støtter f.eks. partisjonering, denormalisation og clustering, sånn at administratoren kan optimalisere databasen uten å tenke på nøyaktig hvor og hvordan dataene blir lagret (dette tar databasen seg av).

Endret 30. november 2006 av ofredstie

[ofredstie]

Ellers synes jeg det blir for dumt å snakke om at databaseserveren har kontroll i denne sammenhengen, for du har ingen måte å ivareta kontroll mot dokumentet som sådan, men mot dokumentets metadata. Dette gjelder samtlige databaseservere jeg har sett. Eneste unntak er evt bruk av datatypen xml i SQL Server 2005 eller DB2 9, men det blir jo noe litt annet igjen.

7393920[/snapback]

 

Kanskje "kontroll" er feil ord-valg, men det jeg mener med det er at når det f.eks. blir tatt backup av databasen så vil filene også bli kopiert, hvis jeg legger inn en link/peker til f.eks. en annen server så kan ikke databasen ta backup av denne eller kontrollere (sånn uten videre) at denne filen i det hele tatt eksisterer. Pga dette blir da databasen "avhengig" av eksterne systemer for å fungere skikkeligt og det er bl.a. dette Codd var interessert i å unngå når han utviklet relasjons-modellen.

 

Relasjons-databaser har en viss overhead, det vil det alltid ha men fordelene med å la databasen ta seg av detaljene rundt hvordan dataene blir lagret er at man slipper å bekymre seg over dette selv.. så lenge man har backup av databasen så er man safe.

 

 

Fant denne infoen hos Oracle:

"Images stored in the database can be directly linked with metadata. In the one transaction an image can be manipulated, a thumbnail of that image created and all associated metadata modified. Related information is kept in sync. If an image is stored in a file system, then it is possible for external processes to delete or modify that image, causing the image itself to either become orphaned or lose synchronicity with its corresponding relational data. Another common issue is web quality images losing their associated thumbnails, meaning web page displays become broken."

Endret 30. november 2006 av ofredstie

[gxi]

Spørsmålet er vel også, hvorfor skal databasen ryke? Er det ikke omtrendt like sansynlig at filsystemet også kan ryke?

7393804[/snapback]

Med godt design vil filene og databasen ikke ligge på samme disk array, hvilket vil si at du sannsynligvis slipper med å restore en av delene, og derved får kortere restore tid.

7393863[/snapback]

Hvorfor ikke bare bruke det andre arrayet til å lagre en hel backup av alle data istedet for å fordele det utover to arrayer? Er det ikke bedre å få tilbake alle data, istedet for et enten-eller-system?

[roac]

Vel, det er derfor store databaser som Oracle støtter f.eks. partisjonering, denormalisation og clustering, sånn at administratoren kan optimalisere databasen uten å tenke på nøyaktig hvor og hvordan dataene blir lagret (dette tar databasen seg av).

7393935[/snapback]

Partisjonering går på å faktisk HA kontroll på hvor dataene ligger, denormalisering går kun på tabellstruktur i databasen, og clustering på høytilgjengelighet. Det du tenker på derimot heter tablespaces i Oracle og storage groups i SQL Server.

[Xqtor]

Ja, det får man si - her fikk man virkelig snøballen til å rulle!

 

Men interessant og nyttig med med all input.

 

 

Jeg bør kanskje spesifisere litt nærmere hva jeg har planer om å snekre sammen:

 

- En enkel bug-database - altså med andre ord noe som ikke er virksomhetskritisk på noen som helst måte

 

- Bruk av MySQL-database (Oracle, MS SQL, DB2 etc. skal ikke brukes)

 

- Vedleggene (.doc - og .pdf-filene) som vil bli lagret vil etter all sannsynlighet ikke være store ( < 1 MB)

 

- 'Applikasjonen' skal være web-basert

 

 

Hovedgrunnen til at jeg tenkte det enkleste vil være å lagre vedleggene i databasen, er at jeg er usikker på hvordan man best kan håndtere muligheten for at vedleggene som lagres faktisk har like navn (i.e. flere vedlegg heter Doc.1)

 

Hvis alle vedlegg lagres i samme mappe er det ikke noe problem å håndtere muligheten for flytting/endring av stien til denne mappen - i allefall så lenge man ikke hardkoder denne flere steder i koden.

 

Hva backup angår:

Dette bør ikke være kriteriet for hvordan man velger å lagre vedleggene; løsningen vil uansett bestå av både database og eksterne filer/kode, så man vil uansett være prisgitt at backup av begge deler blir tatt hånd om og koordinert.

Endret 1. desember 2006 av Xqtor