[MSSQL] file structure of database opslag

[dmnq]

Ik heb de search gebruikt, maar kon geen bevredigend antwoord vinden...dus:

We zitten hier met een project waarbij we duizenden plaatjes willen opslaan op onze server (Win2000, ASP en MS SQL server).

Nou vragen we ons af wat efficienter is. Alle plaatjes als BLOB in de database knallen of als bestand in een aparte map op de server zetten?

Graag voordelen en nadelen voor beide?

Mijn voorkeur gaat uit naar de databaseopslagmethode (leuk scrabblewoord)

Alvast bedankt!

[dusty]

Plaatje fijn als file opslaan en alleen de link in de database opslaan. Redenen zie zoek.

[Nielsz]

Op maandag 15 oktober 2001 11:36 schreef dusty het volgende:
Plaatje fijn als file opslaan en alleen de link in de database opslaan. Redenen zie zoek.

Dat had ik ook gedaan, ging er mooi een punt vanaf, omdat de leraar het er niet mee eens was..

[dusty]

Op maandag 15 oktober 2001 11:37 schreef Nielsz het volgende:
Dat had ik ook gedaan, ging er mooi een punt vanaf, omdat de leraar het er niet mee eens was..

Had je mij erbij moeten roepen

[Nielsz]

Op maandag 15 oktober 2001 11:38 schreef dusty het volgende:

[..]

Had je mij erbij moeten roepen

Wist ik veel dat ik ook plaatjes erin op kon slaan
Hehe, nog geen jaar geleden was ik echt een complete n00b qua programmeren.

_{nee je hoeft hier geen antwoord op te geven}

[dusty]

Op maandag 15 oktober 2001 11:41 schreef Nielsz het volgende:
Hehe, nog geen jaar geleden was ik echt een complete n00b qua programmeren.

Nu niet meer dan?

_{nee je hoeft hier geen antwoord op te geven}

Doe ut stiekum toch!

[Verwijderd]

plaatje opslaan in BLOB is qua code niet efficient, want je moet telkens met appendchunk() datablokken wegschrijven en ophalen. Qua beheer is het wel efficient, want je backupt slechts de catalog en klaar ben je.

Performance technisch maakt het voor SQLServer niet echt uit, maar bij veel blobs kan het efficienter zijn ze op te slaan in een filesystem ivm de sqlserver cache.

En geef die leraar van je maar een slechte beoordeling aan het eind van het jaar. Of had hij goede argumenten waarom je het PER SE als blob moest opslaan?

[raptorix]

Daarnaast heb je vaak nog het practische probleem dat je enorme backup files krijgt bij veel/grote images.

Die leraar verdient een dikke min, en als ie dapper is gaat ie in dit forum zijn mening verdedigen

[Nielsz]

Op maandag 15 oktober 2001 12:34 schreef raptorix het volgende:
Daarnaast heb je vaak nog het practische probleem dat je enorme backup files krijgt bij veel/grote images.

Die leraar verdient een dikke min, en als ie dapper is gaat ie in dit forum zijn mening verdedigen

Whehe, is dat ik van school ben, maar anders had ik 'm erop gewezen

[dusty]

Op maandag 15 oktober 2001 12:35 schreef Nielsz het volgende:
Whehe, is dat ik van school ben, maar anders had ik 'm erop gewezen

Hij zal vast nog wel een email adres hebben waarop je hem kunt bereiken.

[Dope-E]

Welke school is dat?

[Nielsz]

Op maandag 15 oktober 2001 12:39 schreef Dope-E het volgende:
Welke school is dat?

Kan er maar een zijn
TCE (hoe heet die prutser ook al weer? Veldman is het )

[Crazy D]

Op maandag 15 oktober 2001 11:51 schreef Otis het volgende:
plaatje opslaan in BLOB is qua code niet efficient, want je moet telkens met appendchunk() datablokken wegschrijven en ophalen. Qua beheer is het wel efficient, want je backupt slechts de catalog en klaar ben je.

op zich is dat denk ik wel een goeie reden. Geen gezeur met plaatjes die je mist omdat je bent vergeten die dir ook te kopieëren en zo. Synchronizen tussen db's die op verschillende lokaties staan is 't op zich ook wel handig voor (zeker als het fysiek verschillende lokaties zijn, waarbij je vanaf db2 geen verbinding hebt met de server waar de plaatjes opstaan).

Heeft er iemand tijd/zin om eens te kijken of het qua performance echt scheelt, oplaatjes uit db lezen en tonen i.p.v. alleen de filenames opslaan?

[dusty]

Op maandag 15 oktober 2001 13:56 schreef CrazyD_at_work het volgende:
Heeft er iemand tijd/zin om eens te kijken of het qua performance echt scheelt, oplaatjes uit db lezen en tonen i.p.v. alleen de filenames opslaan?

Ooit al eens gedaan,

Hoe meer plaatjes, des te trager wordt de database. (En een index hierop heeft hier natuurlijk een averechtse werking )

[Crazy D]

Op maandag 15 oktober 2001 15:18 schreef dusty het volgende:

Ooit al eens gedaan,

Hoe meer plaatjes, des te trager wordt de database. (En een index hierop heeft hier natuurlijk een averechtse werking )

tenzij je wilt zoeken welke bestanden een bepaald bitje hebben

Kun je iets zeggen over hoeveel trager ie wordt? Met andere woorden, kon je uit jouw test(je?) iets zeggen van nou, tot 1000 plaatjes gaat het wel, maar daarboven (en vooral als het vet veel meer wordt dan die 1000) is het echt bagger?
(ok zal we een stuk meer dan 1000 zijn....)
(gefrustreerde flamemode: testte Exact maar eens wat voordat ze het gaan schrijven....)

[dusty]

Op maandag 15 oktober 2001 15:39 schreef CrazyD_at_work het volgende:
tenzij je wilt zoeken welke bestanden een bepaald bitje hebben

Ligt eraan op welk besturings-systeem

Kun je iets zeggen over hoeveel trager ie wordt? Met andere woorden, kon je uit jouw test(je?) iets zeggen van nou, tot 1000 plaatjes gaat het wel, maar daarboven (en vooral als het vet veel meer wordt dan die 1000) is het echt bagger?
(ok zal we een stuk meer dan 1000 zijn....)

Het was zelfs onder de 1000. (waren wel grote foto's)

(gefrustreerde flamemode: testte Exact maar eens wat voordat ze het gaan schrijven....)

Exact zorgt ervoor dat hun software werkt en letten er voornamelijk op dat alle getalletjes juist zijn. die prioriteit ligt bij hun namelijk hoger dan het efficient programmeren.

[Crazy D]

Op maandag 15 oktober 2001 16:12 schreef dusty het volgende:
Het was zelfs onder de 1000. (waren wel grote foto's)

Da's wel heel snel

Exact zorgt ervoor dat hun software werkt en letten er voornamelijk op dat alle getalletjes juist zijn. die prioriteit ligt bij hun namelijk hoger dan het efficient programmeren.

Ja en dat is dus mijn probleem (ik zit alleen maar op bestandsniveau met Exact te werken). Debiteurnr (altijd numeriek) rechts uitgelijnt in een char veld
Naja zal verder maar niet flamen, want de getalles kloppen idd (meestal) wel...

[bartvb]

BTW zie hiervoor ook b.v. de MySQL mailinglist.. De developers van MySQL raden STERK aan alleen links op te slaan en de werkelijke plaatjes op je filesystem te zetten. Dit is performancewise VEEL efficienter. De hele bedoeling van je FS is het ophalen en cachen van bestanden op een zo snel en effectief mogelijke manier. Databases zijn voor heel andere dingen gemaakt..

Verder heb je ook zo goed als niets aan caching als je alles in een DB propt..

[Nielsz]

Op maandag 15 oktober 2001 19:49 schreef bartvb het volgende:
BTW zie hiervoor ook b.v. de MySQL mailinglist.. De developers van MySQL raden STERK aan alleen links op te slaan en de werkelijke plaatjes op je filesystem te zetten. Dit is performancewise VEEL efficienter. De hele bedoeling van je FS is het ophalen en cachen van bestanden op een zo snel en effectief mogelijke manier. Databases zijn voor heel andere dingen gemaakt..

Verder heb je ook zo goed als niets aan caching als je alles in een DB propt..

Ik zeg 1 woord:

MSSQL

[[ti]]

Op maandag 15 oktober 2001 12:44 schreef Nielsz het volgende:
Kan er maar een zijn
TCE (hoe heet die prutser ook al weer? Veldman is het )

NEEEEE! [flame] TCE ZUIGT! [/flame] .. die lui kunnen enorm niks. De intranet site van hun (intranet.a12.nl) was zo slecht beveiligd dat ik zo als Bredeveld (algemeen directeur) daar kon inloggen (beetje creatief met username doen ). Alle gegevens van leerlingen/leraren en budgetering lagen op straat te grabbel.. En hun jou vertellen hoe je met sql moet omgaan? mwuahah ik heb d'r trouwens ook op school gezeten.. trieste bedoeling daar (opleiding nooit afgemaakt)

[Nielsz]

Op maandag 15 oktober 2001 21:10 schreef [ti] het volgende:

[..]

NEEEEE! [flame] TCE ZUIGT! [/flame] .. die lui kunnen enorm niks. De intranet site van hun (intranet.a12.nl) was zo slecht beveiligd dat ik zo als Bredeveld (algemeen directeur) daar kon inloggen (beetje creatief met username doen ). Alle gegevens van leerlingen/leraren en budgetering lagen op straat te grabbel.. En hun jou vertellen hoe je met sql moet omgaan? mwuahah ik heb d'r trouwens ook op school gezeten.. trieste bedoeling daar (opleiding nooit afgemaakt)

Ach, ik weet het password van mijn moeder dus jah
En je wilt niet geoven met wat voor afstudeerproject ik toch nog een zeven heb gehaald. Dat wil je niet weten.
[ok . Een HEEL simpel ecardsysteem, wat ik in 2 dagen heb kunnen afmaken en waar ze 3 maanden voor hadden geloof ik.. ]

[xshredx]

op de zend site staat een stukje over het opslaan van files in een database of niet, en de voor-nadelen...

conclusie: bij hun testen was het opslaan van plaatjes in de database 23% trager dan wanneer enkel de link naar de plaatjes werd opgeslagen, en de file zelf dan van de disk kwam...

http://www.zend.com/zend/trick/tricks-sept-2001.php

[Sjaaky]

Zoals er ook al als reactie op de Zend site staat is de test niet helemaal eerlijk. Als je namelijk referenties naar plaatjes opneemt in de database zul je die referenties er wel met een database query uit moeten halen. Dat is in deze test niet gebeurd.

[ACM]

Ik heb ooit een heeel korte test uitgevoerd. Met relatief kleine plaatjes (23KB ofzo) en daarbij was het met een php script als:

PHP:

<?
readfile($file);
?>

(die uiteraard nog iets meer toeters en bellen had)

Een stuk sneller dan het uit de mysql-db te plukken (factor 5 of 6)

Ook na enkele honderden keren (lang leve ab )

Overigens denk ik dat het relatief minder traag zal zijn met een "krachtiger DB" en misschien dat het met postgresql's oplossing zelfs veel minder uitmaakt (ze slaan in prinicipe de blobdata in een losse file op, zoiets als Oracle's BFILE (?) type)

Maar ik heb nooit de behoefte gehad, dat te testen

[Victorio]

Hey dmnq!
Xie dat BBB weer up is. Hehehe
Werksuh! Mzzl!

[chem]

Op dinsdag 16 oktober 2001 13:31 schreef Victorio het volgende:
Hey dmnq!
Xie dat BBB weer up is. Hehehe
Werksuh! Mzzl!

bedankt voor je toegevoegde waarde

btw het is niet voor niets zo dat databases die bestanden (binary blobs) WEL opslaan daar juist in gespecialiseerd zijn... neem een inoculus (zo heet-ie toch?) etc.

je zou zelfs erin kunnen zoeken (in de binaire data) bij bv. afbeeldingen (ok, dit gaat wat ver) naar een kleur...

Maar goed, in je doorsnee-database wil je NIET je db volproppen met dit soort [nutteloze] data...

[dmnq]

Op dinsdag 16 oktober 2001 13:31 schreef Victorio het volgende:
Hey dmnq!
Xie dat BBB weer up is. Hehehe
Werksuh! Mzzl!

yep...en dit is voor KC