[Databases/ASP] Images in database op HD opslaan

[Verwijderd]

Als je gebruikers op een site files laat uploaden (over het algemeen foto's) dan kan je deze files saven in een Database (waar we op dit moment alle niet binaire data opslaan) of op de HD. Wat nu niet helemaal duidelijk is, dat is wat de beste manier is. Beide methoden hebben zo hun voor en nadelen.

Voordelen van opslaan op HD:

• Je kan zonder ASP script (of ander soort script welke met de database communiceert) de foto's in bijv. XSL of HTML script aanroepen middels IMG tag.
• Database blijft relatief klein doordat alleen text informatie in database wordt opgeslagen.
• De recordsets die van de database naar de client moeten gaan (via OLEDB) zijn zonder binaire informatie daardoor erg klein. Hierdoor heeft iedere gebruiker de database minder lang nodig om zijn informatie te krijgen.

Nadelen van opslaan op HD:

• Je hebt je data niet bij elkaar staan (het kan bijv. zo zijn dat een file bij een bepaalde record in de DB hoort.) waardoor beheersbaarheid niet optimaal is. (bijv. deleten van record is niet genoeg, je moet ook op de HD een file verwijderen)
• Files moeten in een soort directory structuur opgeslagen worden waarvan de applicatie die de files wil gebruiken het bestaan van kent. Hierdoor is het systeem minder eenbvoudig aan te spreken vanaf een ander software pakket wat anders alleen de database hoeft te kennen.

Voordelen van opslaan in database:

• Data alle data op 1 plaats te vinden is. (en te bewerken is)

Nadelen van opslaan in database:

• Recordsets zijn groter.
• Niet eenvoudig foto's in te laden vanaf een statische pagina als bijv. HTML

Wie heeft hier veel ervaring mee. (ook in projecten met grote hoeveelheden data)
Ik hoop dat we hier voor eens en altijd een goede oplossing voor kunnen vinden.

[gorgi_19]

Persoonlijk kies ik altijd de combinatie van de 2. Lokatie opslaan in de database, bestand opslaan op het FS. Beiden moeten doen waar ze goed in zijn.

[Verwijderd]

gorgi_19 schreef op 07 July 2003 @ 15:47:
Persoonlijk kies ik altijd de combinatie van de 2. Lokatie opslaan in de database, bestand opslaan op het FS. Beiden moeten doen waar ze goed in zijn.

En waarom is het Filesystem goed in het opslaan van files en de database niet dan
Niet dat ik het daar over wil hebben ofzo maar ik wil graag een discussie over waar we die files moeten laten

[ Voor 15% gewijzigd door Verwijderd op 07-07-2003 15:56 ]

[Yo-han]

Verwijderd schreef op 07 juli 2003 @ 15:52:
[...]


En waarom is het Filesystem goed in het opslaan van files en de database niet dan
Niet dat ik het daar over wil hebben ofzo maar ik wil graag een discussie over waar we die files moeten laten

Ben het met gorgi_19 eens. Heb ook wel eens geprobeerd binaire dat in blobs op te slaan maar kwam de snelheid zeker niet ten goede.
Url opslaan blijft tot nu toe ook voor mij de snelste en beste optie...

[gorgi_19]

Verwijderd schreef op 07 July 2003 @ 15:52:
[...]
En waarom is het Filesystem goed in het opslaan van files en de database niet dan

Waarom zouden ze anders een database hebben uitgevonden?
Die files kan je gewoon in een folder dumpen. Let wel op de aantallen files in een folder; na een x- aantal files wordt dit trager.

Blobs zijn sowieso traag.

En dan nu de dooddoener.. Betere forum performance: DB of FS?

(of evt. [rml][ BC3] Files oplaan in Database of Harddisk[/rml])

[ Voor 18% gewijzigd door gorgi_19 op 07-07-2003 16:13 ]

[Verwijderd]

Interesant alleen nog niet echt een winnaar naar mijn idee
Of zie iets over het hoofd?

[alienfruit]

Zelf maak ik gebruik een combinatie van gorgi_19's methode and implementatie van een resource manager; dit wordt de enigste aanspreekpunt voor alle resources. Hierdoor is het gemakkelijk om ook de fysieke bestand te deleten als je de record delete. Overigens zijn er nog andere extra's die dit meebrengen, makkelijk overstappen naar andere database dmv. het schrijven van een data provider (iets anders dan die in .NET).

[Not Pingu]

Verwijderd schreef op 07 July 2003 @ 15:42:

Nadelen van opslaan op HD:

• Je hebt je data niet bij elkaar staan (het kan bijv. zo zijn dat een file bij een bepaalde record in de DB hoort.) waardoor beheersbaarheid niet optimaal is. (bijv. deleten van record is niet genoeg, je moet ook op de HD een file verwijderen)
• Files moeten in een soort directory structuur opgeslagen worden waarvan de applicatie die de files wil gebruiken het bestaan van kent. Hierdoor is het systeem minder eenbvoudig aan te spreken vanaf een ander software pakket wat anders alleen de database hoeft te kennen.

1: hoeveel regels code scheelt dat? 1? en natuurlijk 1 database-aanroep EN een filesystem aanroep, maar dat is in principe niet zo'n belemmering aangezien je het werk verdeelt. delete 1 file, delete 1 record. ik denk dat je zult zien dat 1 datablob van misschien wel 15-25 kB deleten uit een database iets langer kost dan 1 klein record en 1 file. wat overigens niet wil zeggen dat databases langzamer zijn, ze zijn gewoon minder geschikt voor al te grote stukken data.

2: gebruik user Id's voor folder- en bestandsnamen, dan voorkom je elke verwarring.

een image is gewoon een file. als je die image wilt weergeven op een webpagina, zul je die ook als file moeten aanleveren. wat zou je hier beter voor kunnen gebruiken dan het filesystem? als je de url's in de database opslaat kun je bovendien makkelijk lijsten van url's genereren zonder dat je per image in het bestandssysteem moet gaan wroeten.

een DB doet waarvoor ie gemaakt is en is daarvoor ook geoptimaliseerd: het opslaan en snel toegankelijk maken van data (geen bestanden).
het file-system is weer gespecialiseerd in het opslaan van files (grote stukken data).
bovendien is IMHO een image niet een geldig datatype om in een database op te slaan.

[DeverauX]

Ook mijn voorkeur gaat zeker uit naar FileSystem
Afbeeldingen in een DB maakt de boel alleen trager en daarnaast ook minder flexibel. Ook is een db hier eigenlijk ook gewoon niet voor bedoelt.

De nadelen die jij noemt zijn echter wel op te lossen en daardoor ook niet echt een reden geen gebruik te maken van een filesystem-constructie.

[Verwijderd]

Prioriteiten stellen.

- Wat is het doel van de applicatie?
- Doe je huiswerk op voor -en nadelen.
- Weeg de voor -en nadelen af en vergeet hierbij
niet wat de prioriteiten zijn.
- Maak een keuze

[ Voor 6% gewijzigd door Verwijderd op 07-07-2003 16:53 ]

[Verwijderd]

Heb even gekeken in mijn SQLserver 7.0 boek (SQL-server 7.0 programming, isbn: 1-861002-31-9, goed boek trouwens) en daarin geeft de schrijver aan:

"BLOB's or Binary Large Objects are slow - very slow and big. Hey, did I mention they were slow?" ... enz enz..

Het komt er uiteindelijk op neer dat je dit beter als files op de HD kan saven.

[ Voor 4% gewijzigd door Verwijderd op 07-07-2003 16:57 ]

[Yo-han]

Verwijderd schreef op 07 July 2003 @ 16:56:
Heb even gekeken in mijn SQLserver 7.0 boek (SQL-server 7.0 programming, isbn: 1-861002-31-9, goed boek trouwens) en daarin geeft de schrijver aan:

"BLOB's or Binary Large Objects are slow - very slow and big. Hey, did I mention they were slow?" ... enz enz..

Het komt er uiteindelijk op neer dat je dit beter als files op de HD kan saven.

En zo als elke keer eindigt deze discussie weer op hetzelfde...

* Yo-han belt met MySQL over het afschaffen van de blob...

[gorgi_19]

dayoman schreef op 07 July 2003 @ 18:09:
[...]


En zo als elke keer eindigt deze discussie weer op hetzelfde...

* gorgi_19 belt met MySQL over het afschaffen van de blob...

Een blob kan zo ook z'n voordelen hebben..
(* gorgi_19 heeft een keer een class serialized en in een blob gemieterd, werkte erg goed)

[whoami]

gorgi_19 schreef op 07 July 2003 @ 18:13:
[...]

Een blob kan zo ook z'n voordelen hebben..
(* gorgi_19 heeft een keer een class serialized en in een blob gemieterd, werkte erg goed)

Waarom zou je dat willen doen?

[ontopic]
Ik ga akkoord met gorgi_19 en zo. Gewoon je images op je HD zetten, en in je DB het path bijhouden.
[/ontopic]

[ Voor 20% gewijzigd door whoami op 07-07-2003 19:54 ]

[gorgi_19]

whoami schreef op 07 July 2003 @ 19:17:
Waarom zou je dat willen doen?

Was alleen bedoeld als 'tijdelijke' opslag. Voor de rest werd de boel gecached, waardoor performanceverlies minimaal was. Tuurlijk zou het netjes zijn om alles netjes in de juiste kolommen te stoppen, maar in de database wordt geen enkele bewerking met deze zaken gedaan.
Verder minimaal performanceverlies.
Ook nog een hoop werk om het te maken.

Dus vandaar ook gekozen voor deze oplossing.

[whoami]

Op www.sql-server-performance.com zijn ze trouwens ook eenduidig:

klik

[Verwijderd]

Grappig dat bedrijven zoals Exact met hun pakket E-Synergy juist kiezen om alles (Word, Excel, Zip files, Powerpoint presentaties, alles wat je maar kan bedenken) in de SQL 2000 database te proppen.

Ik ben daar, als DBA'er, tegen maar je doet er helaas helemaal niks aan.

De database groeit uit zn voegen, het is niet mogelijk om even 1-2-3 een stuk history "af te stoten" want E-Synergy wilt alles vanaf het begin bewaren zodat elke klant op elke offerte kan worden nagesnuffeld.

Dus we weten dat het niet handig is en zeker niet snel, toch doen sommige groten der aarden het gewoon.

Doet Sharepoint Portal Server en Content Management Server ook niet zoiets? Maw: doet Microsoft dit niet?

[pistole]

Microsoft werkt natuurlijk naar het "database filesystem" (kan ff niet op de naam komen), dus ja.. Daar zullen ze vast een reden voor hebben?

Overigens: ik bewaar al mijn images (of eigenlijk alle files/etc) in de database.
Waarom?
-data blijft op 1 locatie -> backup etc is daardoor makkelijk. Scripts veranderen niet snel, database wel
-veiligheid. Als je toestaat bestanden naar je filesystem te uploaden creëer je m.i. een groot risico

[whoami]

pistole schreef op 07 juli 2003 @ 20:19:
Overigens: ik bewaar al mijn images (of eigenlijk alle files/etc) in de database.
Waarom?
-data blijft op 1 locatie -> backup etc is daardoor makkelijk. Scripts veranderen niet snel, database wel
-veiligheid. Als je toestaat bestanden naar je filesystem te uploaden creëer je m.i. een groot risico

De database groeit, en wordt traag en log.

Hoezo je creeërt een risico? Als je nu eens die images in 1 centrale directory zet, en je je rechten goed zet, dan valt dat allemaal zeer goed mee.

[pistole]

whoami schreef op 07 July 2003 @ 20:20:
[...]


De database groeit, en wordt traag en log.

Hoezo je creeërt een risico? Als je nu eens die images in 1 centrale directory zet, en je je rechten goed zet, dan valt dat allemaal zeer goed mee.

Databases kan je optimaliseren, defragmenteren en indexeren...

Overigens is dit wel een leuke discussie, maar zal uiteindelijk uitmonden in "smaak"; de een is linksdragend, de ander rechts.

[gorgi_19]

pistole schreef op 07 July 2003 @ 20:19:
-veiligheid. Als je toestaat bestanden naar je filesystem te uploaden creëer je m.i. een groot risico

Ik ben heel benieuwd naar de risico's... Afgezien van een systeembeheerder die z'n werk niet goed doet of een programmeur die niet weet waar hij mee bezig is. , zie ik namelijk weinig risico's.

pistole schreef op 07 July 2003 @ 20:22:
[...]

Databases kan je optimaliseren, defragmenteren en indexeren...

Erhm.. Ja? Maar daarom dus perfect geschikt om een lokatie in op te slaan? Je mist zo de conversieslag.

[ Voor 56% gewijzigd door gorgi_19 op 07-07-2003 20:32 ]

[pistole]

gorgi_19 schreef op 07 July 2003 @ 20:30:
[...]

Ik ben heel benieuwd naar de risico's... Afgezien van een systeembeheerder die z'n werk niet goed doet of een programmeur die niet weet waar hij mee bezig is. , zie ik namelijk weinig risico's.

In het geval van images == plaatjes: sois, geen risico. Als je echter mogelijkheden biedt files te uploaden (zonder restrictie qua type) moet je inderdaad zorgen dat de directory ofwel niet rechtstreeks te benaderen is danwel zodanige permissies daarop te zetten dat geuploade bestanden niet uitgevoerd kunnen worden (dus bv geen .asp of .php bestanden). Idealiter zou je dus m.i. de bestanden buiten je docroot opslaan en dmv een script de bestanden aanbieden. Hierdoor krijg je natuurlijk ook weer overhead.

Erhm.. Ja? Maar daarom dus perfect geschikt om een lokatie in op te slaan? Je mist zo de conversieslag.

Welke conversieslag bedoel je?

M.i. is een geuploade file "data" en dient dat gestructureerd te worden opgeslagen. Het liefst dus in een database. Of je database nu groot wordt of je filesystem meer ruimte inneemt is lood om oud ijzer. Okee; je zal wat overhead hebben als je het in je database opslaat...

[ Voor 16% gewijzigd door pistole op 07-07-2003 20:41 ]

[Verwijderd]

kijk er zijn natuurlijk wel duidelijk risico's als je de files niet in een database opslaat maar op het filesystem. bijv. MSSQL geadvanceerde security mogelijkheden die je alleen op het filesystem kan gebruiken als je security settings van iedere file aanpast. Gewoon geknoei eigenlijk. Het zou mooi zijn als MSSQL (en andere DB's) goed omgingen met files maar jammer genoeg moeten we toch uitwijken naar een 'houtje touwtje' oplossing door de files op het FS te gooien.

[whoami]

Verwijderd schreef op 07 July 2003 @ 22:18:
kijk er zijn natuurlijk wel duidelijk risico's als je de files niet in een database opslaat maar op het filesystem. bijv. MSSQL geadvanceerde security mogelijkheden die je alleen op het filesystem kan gebruiken als je security settings van iedere file aanpast.

Wat als je de security settings goed zet op directory niveau?

[gorgi_19]

whoami schreef op 07 July 2003 @ 22:21:
[...]

Wat als je de security settings goed zet op directory niveau?

En het SQL Server account niet te veel rechten geeft (lees: geen lid van Administrator Group / System account)

[oZy]

ik zit nu met hetzelfde dilemma, maar ben niet echt overtuigd door de posts hierboven

Mijn grootste punt is dat je de consistentie van de data niet kunt garanderen als je het gescheiden doet. M.a.w. de relatie tussen bestand en record bestaat niet aangezien je geen garantie daartoe hebt, waardoor je de kracht van een relationele database min of meer onderuit haalt.

Misschien een beetje overdreven, maar wie zegt jou dat er niemand (systeembeheerder) een file verwijderd heeft? Welke garantie heb je dat de file echt (volledig) in het FS te vinden is? Bijv. een virusscanner die het bestand verdacht vind en in een quarantaine map mikt.

Ik weet gewoon dat als ik een bestand in de database zet, dat je er ook vanuit kunt gaan dat het daar, in goede staat, terug te vinden is.

[gorgi_19]

oZy schreef op 03 september 2003 @ 11:38:
ik zit nu met hetzelfde dilemma, maar ben niet echt overtuigd door de posts hierboven

Mijn grootste punt is dat je de consistentie van de data niet kunt garanderen als je het gescheiden doet. M.a.w. de relatie tussen bestand en record bestaat niet aangezien je geen garantie daartoe hebt, waardoor je de kracht van een relationele database min of meer onderuit haalt.

Misschien een beetje overdreven, maar wie zegt jou dat er niemand (systeembeheerder) een file verwijderd heeft? Welke garantie heb je dat de file echt (volledig) in het FS te vinden is? Bijv. een virusscanner die het bestand verdacht vind en in een quarantaine map mikt.

Ik weet gewoon dat als ik een bestand in de database zet, dat je er ook vanuit kunt gaan dat het daar, in goede staat, terug te vinden is.

In jouw voorbeeld; wat heeft een viruszoeker dan daar te zoeken in die folder? Sowieso kan je, als je je server niet vertrouwd ook via de Task Scheduler een taak definieren, welke dagelijks de bestanden controleert op consistentie.

[alienfruit]

Trouwens Oracle heeft er het perfecte oplossing voor: BFILE

[gorgi_19]

alienfruit schreef op 03 september 2003 @ 11:54:
Trouwens Oracle heeft er het perfecte oplossing voor: BFILE

Klopt, maar bijvoorbeeld MS Access in een Memoveld is pure mishandeling..

[oZy]

Dan nog, het is toch een risico voor je consistentie? Het voordeel van een database oplossing is dat de database je die consistentie kan garanderen (zo niet, dan is je DB kapot).

Er zijn geen andere programma's die toegang hebben tot die database/tabel, bijna alle programma's hebben toegang tot het FS. Natuurlijk kun je dat oplossen met security settings van je FS maar dat is nooit waterdicht.

[oZy]

alienfruit schreef op 03 September 2003 @ 11:54:
Trouwens Oracle heeft er het perfecte oplossing voor: BFILE

geen ervaring mee, ik werk met SQL Server 2000

[ACM]

't Is een kwestie van prioriteiten, als consistentie erg belangrijk is moet je zeker het nadeel van je FS-DB-integriteit meewegen, als het "niet zo belangrijk" is, dan minder.
Als het een absoluut vereiste is, dan valt je FS al bijna helemaal af...

Als je doel vooral een handige koppeling tussen een applicatie en de files is en het niet zo erg is als een file (in theorie iig) zomaar weg kan zijn, dan zal de DB+FS versie een stuk aantrekkelijker zijn.
De performance is vaak toch wel wat beter, maar dat hangt ook weer van allerlei factoren af.

Backups van je database zijn vaak ook veel mooier consistent, je hebt geen geklooi met rechten op files, etc.
Maar zoals gezegd, 't is meestal wat slomer, niet perse _erg_ sloom, magoed. 't Blijft een kwestie van voordelen vs nadelen in combinatie met de eisen en wensen van jouw applicatie.
Zonder die eisen en wensen kun je alle voor- en nadelen gelijkstellen kwa zwaarte en zal het gauw de combinatie DB+FS worden die het wint.

[slm]

Een aantal mensen hebben het hier over backuppen en dat dit makkelijker zou zijn als alles op 1 plek zou staan, namelijk de database, maar dan gaat men er toch maar even vanuit dat men de databaseserver in eigen beheer heeft en dus een backup kan maken van de database-bestanden in tegenstelling tot het maken van een dumpfile van de database.

Bij de meeste providers kom je alleen bij je database dmv phpmyadmin en met hoge uitzondering via telnet/ssh.

Als je alleen een backup kan maken via een dumpfile van phpmyadmin, kan je dus maar beter die blobjes vergeten denk ik.

Daarnaast vind ik het erg omslachtig om je images (of andere bestanden) uit een database te trekken, aangezien je daarvoor altijd weer een apart script nodig hebt, tenzij je de image mimencoded opslaat wat ook weer de nodige nadelen heeft. Bestanden opslaan in je database betekent ook weer dat er (veel) meer sessies op je database worden geopend wat weer nadelig is voor je performance.

Beter is om de locatie van het bestand in de database te proppen (of gebruik te maken van userid's zodat de locatie altijd bekend is) en zelf een beheerprogje te schrijven die zorgt voor de consistentie.

[ Voor 12% gewijzigd door slm op 03-09-2003 14:25 ]

[Verwijderd]

Bij een MSSQL applicatie heb ik 't alsvolgt opgelost:
- Database met 1 tabel, puur voor de blobs (3 velden, locatie, ID en data).
- Een view naar die tabel in de "echte" database.

Je hoofddatabase wordt daar niet trager van, bij een backup hoef je niet iedere keer niet-kritische dingen (in mijn geval bevestigingsbrieven, mailings, etc.) mee te nemen, en je voorkomt dat de blobs (c.q. bestanden) gemakkelijk van buitenaf te wijzigen zijn.

[slm]

Is natuurlijk aardig zo'n view, maar heb het nog niet in MySQL kunnen ontdekken en daar werk ik voornamelijk mee. Daarnaast ben ik van mening dat je datgene moet gebruiken waar het voor gemaakt is. Je kan een lepel ook als een verkapt soort mes gebruiken maar echt snijden doet het niet... Daarentegen werkt het perfect om soep mee op te lepelen

En vwb dat databasebackup-argument van mij is dit [rml][ mysql] Mysql importeren lukt niet :([/rml] natuurlijk een mooi voorbeeld van iemand die een leuke export heeft, maar het niet (geheel vlekkeloos) terug kan zetten.

[we_are_borg]

Is het niet mogelijk om het beste van twee werelden te hebben. Kan je niet een script schrijven die als je een record verwijderd uit de database ook netjes de des betrefende file van de HD afgooit, en kan die script ook niet voor zorgen dat een file in de database wordt opgenomen als het noodzakelijk is. Volgens mij mag dit geen probleem zijn.

In hoevere wordt een database onhandelbaar hoeveel gegevens moet erin zitten voordat hij traag wordt.

[ACM]

slm: De gene die het topic kickte had het over MSSQL 2000...

[slm]

hmm.. had niet in de gaten dat dat de 'topickicker' was (in zijn 1e post stond het niet namelijk).

[gorgi_19]

Toevallig net http://www.asp.net/Forums...?tabindex=1&PostID=326823 ook tegen gekomen, welke ongeveer over hetzelfde onderwerp gaat.