[PHP] plaatje uit mysql database

[Verwijderd]

Hoi,

Ik heb een plaatje in een database staan, en die wil ik weergeven op een htmlpagina.
Eerst heb ik het getest in een pagina waar als niets anders in staat als:

code:

    $result = mysql_query("SELECT * FROM artikelen WHERE nummer='8998900'");

    echo mysql_result($result, 0, "foto");

Hier werkt het prima.

Maar nu wil ik het plaatje weergeven in een tabel.
Ik gebruik de zelfde code, maar nu krijg ik:

code:

ÿØÿàJFIFHHÿÛC       ÿÛC  ÿÀ)ÿÄÿÄT“aÑÿÄÿÄR‘ÿÚ ?Ùô³]wýúTxwvËÕ£—W\|4³]wý8wvËÓ—W\|4³]wý8wvËÓ—W\|[KPèZA®KPZ+’ÔŜî.UEjÊÁ\•P²W%T,•Ôo¥2Ä>$…sÿMrÎø’ÄÛOBQ€ÿÙ

Weet iemand waar dit aan ligt?

[jurri@n]

Misschien wel omdat een plaatje altijd een extern bestand moet zijn, en niet de ruwe data in je HTML-file?

Je zult een apart php-filetje moeten maken die dienst doet als plaatje.

[Michali]

een apart php script dus die je aanroept vanuit een img tag (of iets anders)

code:

[img]"plaatje.php?id=123"/[/img]

plaatje.php:

PHP:

header("Content-Type: image/gif");

echo $bin_gif_plaatje;

[Verwijderd]

ff verder uitgewerkt:

code:

[img]"plaatje.php?id=123"/[/img]

plaatje.php:

PHP:

include('connect.php');
if(!is_numeric($_GET['id'])) { die('GEEF EEN GETAL ALS ID!'); }
header("Content-Type: image/gif");
$res = mysql_query("SELECT foto FROM artikelen WHERE nummer = ".$_GET['id']) or die(mysql_error());
echo mysql_result($res,0,'foto');

Zo dus... Maar dit zou je toch echt zelf moeten kunnen..

[Michali]

nog ff verder uitgewerkt:
plaatje.php:

PHP:

<?

include('connect.php');

if ( empty($_GET['id']) || !is_numeric($_GET['id']) )
{
    die('GEEF EEN GETAL ALS ID!');
}

$query = "
    SELECT
        foto,
        mime_type
    FROM
        artikelen
    WHERE
        nummer = " . $_GET['id'] . "
";

$res = mysql_query($query) or die(mysql_error());

if ( mysql_num_rows($res) == 0 )
{
    die("Dude, die foto bestaat niet!");
}

$rs = mysql_fetch_assoc($res);

header("Content-Type: " . $rs['mime_type']);

echo $rs['foto'];

?>

[Verwijderd]

Bedankt voor de gedetailleerde informatie, de eerste reply was echter wat ik zocht

[tjerkw]

Ik weet dat je er niet om vraagt maar ik meld het toch even:

Binary-data, zoals images opslaan in een database is traag. Je kunt beter een path naar het bestandje opslaan in de database zodat het plaatje rechtstreeks van de disc kan worden gelezen.
Dus het plaatje in een bepaalde map stoppen.

[Erkens]

tjerkw schreef op woensdag 23 februari 2005 @ 23:43:
Ik weet dat je er niet om vraagt maar ik meld het toch even:

Binary-data, zoals images opslaan in een database is traag. Je kunt beter een path naar het bestandje opslaan in de database zodat het plaatje rechtstreeks van de disc kan worden gelezen.
Dus het plaatje in een bepaalde map stoppen.

hoezo is dat traag?
hoe heb je dat gemeten

[tjerkw]

Erkens schreef op woensdag 23 februari 2005 @ 23:45:
[...]

hoezo is dat traag?
hoe heb je dat gemeten

Je hoeft het niet te meten, redeneren is genoeg

Webservers cachen bestanden die vaak worden gerequested. Zoals plaatjes. Een cache is een stuk sneller dan de harde schijf. Als je je bestand in een database propt en geen rekening hiermee houdt dan
zul je merken dat je wat performance verliest.
Ook de client-side (browser) zal dynamische pagina's niet cachen.

Daarnaast zijn relationele database niet ontworpen voor het opslaan van blobs.. zoeken door een tabel gaat dan ook langszamer

Er zijn wel bepaalde gevallen dat een keuze voor een image blob in je database een goede is [bijvoorbeeld kleine icoontjes]

[Erkens]

tjerkw schreef op donderdag 24 februari 2005 @ 00:20:
Je hoeft het niet te meten, redeneren is genoeg

dat is nog geen bewijs dat het traag is

Webservers cachen bestanden die vaak worden gerequested. Zoals plaatjes. Een cache is een stuk sneller dan de harde schijf. Als je je bestand in een database propt en geen rekening hiermee houdt dan
zul je merken dat je wat performance verliest.

database servers cachen (en weet je wat, die servers hebben hun database ook als files opgeslagen dus wordt het dubbel gecached ) Daarnaast kan een database met goede indexen sneller een file opzoeken dan dat je filesystem dat kan

Ook de client-side (browser) zal dynamische pagina's niet cachen.

o? gewoon juiste headers meesturen
onzin dus

Daarnaast zijn relationele database niet ontworpen voor het opslaan van blobs.. zoeken door een tabel gaat dan ook langszamer

indexen

Er zijn wel bepaalde gevallen dat een keuze voor een image blob in je database een goede is [bijvoorbeeld kleine icoontjes]

o, en dan plotseling wel

offtopic:
overigens gebruik ik zelf gewoon losse files, maar dat is meer voor het onderhoud en backup, welke ik belangrijker vind dan een eventuele traagheid

[T-MOB]

Erkens schreef op donderdag 24 februari 2005 @ 00:25:
...

Het ligt dus aan de hoeveelheid plaatjes die je in de db stopt. Als je tabel met plaatjes groter wordt dan de hoeveelheid geheugen valt er weinig te optimaliseren door gebruik te maken van caching. Een kleine tabel met verwijzingen naar losse bestanden is dan wel degelijk te prefereren (wordt het populairste plaatje in elk geval gecached door het FS).
De enige tabel waarbij je echt zeker bent dat hij nooit zo groot wordt is die met icoontjes. Maar goed ook dan ben ik van mening dat het niet te onderhouden is...

[Janoz]

Dat het geheugen vol kan raken geldt natuurlijk ook voor het filesystem. Bedenk daarnaast ook dat een DB een speciaal geoptimaliseerd type heeft voor grote stukken binaire data. Dit betekend dat het helemaal niks uitmaakt voor de verwerkingssnelheid of er grote of kleine plaatjes in staan.

Bedenk dat een database bedoeld is om gegevens op te slaan en efficient hier weer uit te halen. Ik kan me heel goed voorstellen dat een database zelfs significant sneller is met het teruggeven van een plaatje waneer er in een tabel met duizenden images gezocht wordt op een geindexeerde integer. Het doorlopen van de FAT op zoek naar de juiste bestandslokatie zal dan langer duren.

Daarnaast is er 1 belangrijk argument wat nog niet is genoemd:
Waneer je al je content in de database opslaat heb je alles bij elkaar. Van elkaar afhankelijke content is niet gescheiden opgeslagen. Waneer je een database hebt en de plaatjes los in een directory hebt staan kun je afhankelijkheden niet meer afdwingen. Backups kunnen finaal de mist in gaan omdat plaatjes en database op een ander tijdstip worden gebackuped. Plaatjes kunnen gewist worden van de schijf terwijl ze nog wel in de db staan (en andersom).

Ik ben erg benieuwd waarom jij vindt dat een tabel met plaatjes niet te onderhouden is. Ik zie namelijk meer onderhouds moeilijkheden bij gescheiden opslag.

[Erkens]

Ik weet niet hoe mysql (in dit geval) dit soort dingen optimaliseerd enzo, maar wat ik duidelijk probeerde te maken is dat je niet zomaar iets moet roepen als er geen "bewijs" voor is
En wellicht is het namelijk zo dat juist bij veel plaatjes het sneller werkt via de DB. Ik weet dat niet, niet getest.

[marty]

Hier wat bewijs:

http://www.zend.com/zend/...=2033&open=1&anc=0&view=1

Volgens de schrijver/onderzoeker verlies je ongeveer een derde in performance door het uit de (MySQL) database op te halen

[Janoz]

Ik kan me niet geheel vinden in de test van die persoon. Ten eerste wordt daar 1 plaatje getest. Daarnaast wordt een passthrough vergeleken met het opzetten van een complete database verbinding. Dat laatste is uiteraard wat voor te zeggen, maar waneer je zelf ook nog wat rechten checks via de db wil doen of uit de db het contenttype haalt, zou het best kunnen dat je ook in je filesystem gebaseerde script nog een database verbinding nodig hebt. Als je echt het stukje 'lezen uit db' vs 'lezen van schijf' wilt testen hoort in beide scripts het opzetten van de connectie niet bij.

Daarnaast wordt in de test niet gekeken naar de voordelen die het zou kunnen hebben bij het zoeken op een geindexeerd veld bij grote hoeveelheden plaatjes.

[tjerkw]

Erkens schreef op donderdag 24 februari 2005 @ 00:25:
[...]

dat is nog geen bewijs dat het traag is

Nou in principe wel.. Logisch redeneren heet dat.

[...]

database servers cachen (en weet je wat, die servers hebben hun database ook als files opgeslagen dus wordt het dubbel gecached ) Daarnaast kan een database met goede indexen sneller een file opzoeken dan dat je filesystem dat kan

haha, weet je wel hoe filesystems zijn geimplementeerd. Op linux bijvoorbeeld gaat het zoeken naar een file een stuk sneller dan eerst zoeken naar de database file op de disc, en vervolgens daarin nog te zoeken naar de informatie die je zoekt. (nu liet ik even de cache weg)

Je hebt gelijk een database kan ook cachen.. maar dan nog moet er in de cache gezoekt worden naar het plaatje. Bij een filesystem gaat dit significant sneller dmv bijvoorbeeld inodes.

[...]

o? gewoon juiste headers meesturen
onzin dus

ok daar heb je me

[...]

indexen

indexen vergroote de snelheid naar het zoeken van bepalde dingen.. maar dat weegt niet op tegen de grootte van plaatjes dat doorzocht moet worden

[...]

o, en dan plotseling wel

offtopic:
overigens gebruik ik zelf gewoon losse files, maar dat is meer voor het onderhoud en backup, welke ik belangrijker vind dan een eventuele traagheid

het is in het geval van icoontjes verdedigbaar...

trouwens.. er zullen vast wel databases bestaan (oracle bijvoorbeeld) die net zo ver zijn geoptimiliseerd voor binary data dat het super snel gaat.

shit nu geef ik je uiteindelijk toch nog gelijk

[T-MOB]

Janoz schreef op donderdag 24 februari 2005 @ 08:38:...

Ik doelde niet op een database met "grote plaatjes", maar het geval waarin je tabel met plaatjes groter wordt dan de beschikbare hoeveelheid geheugen. Voor zover ik weet gooit mysql tabellen in een enkel bestand. Dan heb je dus een performance probleem wanneer er table lookups moeten worden gedaan of wanneer zowel het eerste als het laatste plaatje populair zijn. Met een tabel met referenties naar bestanden hou je zowel je tabel gecached als de laatst opgevraagde plaatjes.

Qua onderhoud heb je wel een punt denk ik, alhoewel je met de juiste rechten op de plaatjes kunt voorkomen dat ze "per ongeluk" gewist worden. Met een simpel backup-scriptje kun je verder afdwingen dat ze "op hetzelfde moment" worden geback-upped.
Mijn opmerking was verder vrij subjectief omdat ik er niet aan moet denken om database queries uit te voeren als ik een plaatje wil wijzigen.

Een laatste punt wat min of meer los staat van platte opslag zijn de filesystem- en imagefuncties in PHP. Door je plaatjes in een tabel te gooien wordt het omslachtig om deze aan te spreken. Dat komt er op neer dat je van te voren de nuttige eigenschappen van de bestanden die je wil opvragen moet opslaan in je db. Wil je later functionaliteit toevoegen aan je applicatie en je hebt daar extra gegevens over het plaatje bij nodig dan heb je een probleem. Nou ja, als het om veel plaatjes gaat in elk geval een leuke klus om je database te updaten.

[Erkens]

tjerkw schreef op donderdag 24 februari 2005 @ 11:37:
Nou in principe wel.. Logisch redeneren heet dat.

logisch redeneren en de praktijk zijn twee heel aparte dingen die vaak nog wel eens willen verschillen...

haha, weet je wel hoe filesystems zijn geimplementeerd. Op linux bijvoorbeeld gaat het zoeken naar een file een stuk sneller dan eerst zoeken naar de database file op de disc, en vervolgens daarin nog te zoeken naar de informatie die je zoekt. (nu liet ik even de cache weg)

Je hebt gelijk een database kan ook cachen.. maar dan nog moet er in de cache gezoekt worden naar het plaatje. Bij een filesystem gaat dit significant sneller dmv bijvoorbeeld inodes.

uiteraard weet ik hoe filesystems werken, maar het grote voordeel is juist het vinden van dat plaatje, de grote (in bytes) maakt niet uit want als het goed is weet je database waar het plaatje begint en waar hij eindigt, je hoeft maar 1 file te openen, naar het juiste punt seeken en x bytes uitlezen.
Ik denk dat in totaliteit het weinig uitmaakt in performance welke manier je gebuikt. Heb alleen geen tijd/zin om dit uit te werken met een mooi voorbeeld

indexen vergroote de snelheid naar het zoeken van bepalde dingen.. maar dat weegt niet op tegen de grootte van plaatjes dat doorzocht moet worden

Dat is ook het hele punt, je moet het snel kunnen vinden.
de grote van het plaatje maakt bij het zoeken juist helemaal niet uit, je gaat immers niet in het plaatje zoeken

trouwens.. er zullen vast wel databases bestaan (oracle bijvoorbeeld) die net zo ver zijn geoptimiliseerd voor binary data dat het super snel gaat.

shit nu geef ik je uiteindelijk toch nog gelijk

[tjerkw]

Erkens schreef op donderdag 24 februari 2005 @ 13:45:
[...]

logisch redeneren en de praktijk zijn twee heel aparte dingen die vaak nog wel eens willen verschillen...

Als je in de praktijk waarneemt dat A sneller gaat dan B.. dan hoeft dat nog niet te kloppen. Om echt een uitspraak te doen over wat sneller is moet je logisch redeneren. Maar ok, de praktijk geeft een goede indicatie

[...]

uiteraard weet ik hoe filesystems werken, maar het grote voordeel is juist het vinden van dat plaatje, de grote (in bytes) maakt niet uit want als het goed is weet je database waar het plaatje begint en waar hij eindigt, je hoeft maar 1 file te openen, naar het juiste punt seeken en x bytes uitlezen.
Ik denk dat in totaliteit het weinig uitmaakt in performance welke manier je gebuikt. Heb alleen geen tijd/zin om dit uit te werken met een mooi voorbeeld

ok dat klopt. maar de groote van het plaatje is wel van belang

[...]

Dat is ook het hele punt, je moet het snel kunnen vinden.
de grote van het plaatje maakt bij het zoeken juist helemaal niet uit, je gaat immers niet in het plaatje zoeken

Volgens mij is grootte wel van belang. Wat gaat sneller:: en klein plaatje of een groot plaatje uit een database halen?? een klein plaatje. Een hardeschijf is veel beter (er zijn uitzonderingen) in het ophalen van grote hoeveelheden data.

[Erkens]

tjerkw schreef op vrijdag 25 februari 2005 @ 17:07:
Als je in de praktijk waarneemt dat A sneller gaat dan B.. dan hoeft dat nog niet te kloppen. Om echt een uitspraak te doen over wat sneller is moet je logisch redeneren. Maar ok, de praktijk geeft een goede indicatie

iets wat logisch is/lijkt hoeft dat niet te zijn

Volgens mij is grootte wel van belang. Wat gaat sneller:: en klein plaatje of een groot plaatje uit een database halen?? een klein plaatje. Een hardeschijf is veel beter (er zijn uitzonderingen) in het ophalen van grote hoeveelheden data.

volgens mij spreekt iemand hier zichzelf tegen

[tjerkw]

Erkens schreef op vrijdag 25 februari 2005 @ 17:14:

[...]

volgens mij spreekt iemand hier zichzelf tegen

Hoezo dan? Een harde schijf is beter dan een database in het ophalen van grote bestanden.. maar ook sneller in het ophalen van kleine plaatjes. Hoezo spreek ik mezelf tegen?

[CH4OS]

Erkens schreef op donderdag 24 februari 2005 @ 00:25:
dat is nog geen bewijs dat het traag is

Kan ik net zo goed een wedervraag stellen... Kan jij bewijzen, dat het sneller is?

Erkens schreef op vrijdag 25 februari 2005 @ 17:14:
iets wat logisch is/lijkt hoeft dat niet te zijn

Iets wat logisch is (en dus bewezen logisch te zijn) hoeft niet logisch te zijn?

Verder vraag ik me eigenlijk af, wat de waarheden en niet-waarheden zijn, omtrent binary data in een database. Er zijn dan wel datatypes voor en zo, maar maakt dat het voor de database stukken beter? Is het echt sneller of beter dan gewoon los op de filesystem? Enigste voordeel die ik eruit kan halen, is dat het makkelijker is, qua beheer en zo...

[Verwijderd]

Ik heb het idee dat plaatjes uit een database halen behoorlijk traag kan worden.
Als je de plaatjes in een database hebt staan, dan moet je altijd een scriptje maken dat via een query (+ db verbinding) het plaatje ophaalt.

Stel je voor dat je een foto-gallery hebt met 25 plaatjes.Dan moet je eerst 25 keer dat scriptje aanroepen waar je dat plaatje ophaalt.(+ de db verbinding). En als je dan veel bezoekers krijgt op hetzelfde moment dan krijg je wel erg veel queries.Met het gevolg dat het traag wordt.

Ik geef toe dat als je erg veel plaatjes in een directory zet, het dan traag wordt.Maar dit kun je dan oplossen met subdirectories.

[CH4OS]

Verwijderd schreef op zaterdag 26 februari 2005 @ 13:27:
Ik heb het idee dat plaatjes uit een database halen behoorlijk traag kan worden.
Als je de plaatjes in een database hebt staan, dan moet je altijd een scriptje maken dat via een query (+ db verbinding) het plaatje ophaalt.

Databases zijn in mijn ogen dan ook niet bedoelt, om binary data in op te slaan, want daar kan je ook heel makkelijk (en misschien zelfs beter) je filesystem voor gebruiken...

Stel je voor dat je een foto-gallery hebt met 25 plaatjes.Dan moet je eerst 25 keer dat scriptje aanroepen waar je dat plaatje ophaalt.(+ de db verbinding). En als je dan veel bezoekers krijgt op hetzelfde moment dan krijg je wel erg veel queries.Met het gevolg dat het traag wordt.

Plus dat het ergens ook wel overkill is, om überhaupt zo'n scriptje te maken, voor 25 plaatjes...

Ik geef toe dat als je erg veel plaatjes in een directory zet, het dan traag wordt.Maar dit kun je dan oplossen met subdirectories.

Het zal allicht altijd sneller zijn, dan plaatjes uit een database, omdat het selecteren dan ook langer zal duren (tijd naar bepaalde record word langer) en het is afhankelijk van de grootte die het gebruikt in de DB... Plus het type van het plaatje is ook wel een factor denk ik (denk aan veel compressie, of juist niet)

[Verwijderd]

Ik ben in principe tegen plaatjes in database, omdat binaire _meestal_ niet in een database thuis hoort.(zijn een paar uitzonderingen)

GJ-tje schreef op zaterdag 26 februari 2005 @ 15:35:
[...]
Databases zijn in mijn ogen dan ook niet bedoelt, om binary data in op te slaan, want daar kan je ook heel makkelijk (en misschien zelfs beter) je filesystem voor gebruiken...

Mee eens.

[...]
Het zal allicht altijd sneller zijn, dan plaatjes uit een database, omdat het selecteren dan ook langer zal duren (tijd naar bepaalde record word langer) en het is afhankelijk van de grootte die het gebruikt in de DB... Plus het type van het plaatje is ook wel een factor denk ik (denk aan veel compressie, of juist niet)

Ben ik niet helemaal met je eens.
Een grote database met de juiste indexen kan in principe wel sneller zijn dan het filesystem.Het duurt namelijk wel even voordat het file system de hele FAT heeft doorzocht.(Volgens mij is dit al eerder genoemd in dit topic)
Maar als je het dan opdeelt in subdirectories moet het in principe wel weer sneller worden.

Nog een voordeel van plaatjes in een database is dat je gebruik kan maken van de functies van de database. Transactions kunnen soms erg handig zijn. Maar ik blijf bij mijn standpunt.

[Erkens]

GJ-tje schreef op zaterdag 26 februari 2005 @ 12:46:
[...]
Kan ik net zo goed een wedervraag stellen... Kan jij bewijzen, dat het sneller is?

ik heb reeds al gezegt dat ik niet in staat ben om een test omgeving te bouwen, maar ik heb ook niet gezegt dat het ook sneller is. Ik vind alleen dat je dergelijke uitspraken niet kan doen alleen maar omdat je het logisch vind. Ik vind het namelijk logisch dat informatie die geindexeerd en gegroepeerd is snel terug gehaald kan worden en dus zou het dus in theorie sneller kunnen zijn

Iets wat logisch is (en dus bewezen logisch te zijn) hoeft niet logisch te zijn?

o god, we vallen weer over 1 woordje
haal dat woordje eens weg en lees opnieuw

Verwijderd schreef op zaterdag 26 februari 2005 @ 13:27:
Ik heb het idee dat plaatjes uit een database halen behoorlijk traag kan worden.
Als je de plaatjes in een database hebt staan, dan moet je altijd een scriptje maken dat via een query (+ db verbinding) het plaatje ophaalt.

database verbinding heb je al dus dat is gewoon onzin. En als je plaatjes wilt afschermen voor bijvoorbeeld niet ingelogde gebruikers dan moet je dat (bijna) altijd al via een scriptje doen dus dat is geen argument.

Stel je voor dat je een foto-gallery hebt met 25 plaatjes.Dan moet je eerst 25 keer dat scriptje aanroepen waar je dat plaatje ophaalt.(+ de db verbinding). En als je dan veel bezoekers krijgt op hetzelfde moment dan krijg je wel erg veel queries.Met het gevolg dat het traag wordt.

zie hierboven.

Ik geef toe dat als je erg veel plaatjes in een directory zet, het dan traag wordt.Maar dit kun je dan oplossen met subdirectories.

dan moet je dus die directory structuur doorzoeken, ook niet echt handig

GJ-tje schreef op zaterdag 26 februari 2005 @ 15:35:
[...]
Databases zijn in mijn ogen dan ook niet bedoelt, om binary data in op te slaan, want daar kan je ook heel makkelijk (en misschien zelfs beter) je filesystem voor gebruiken...

wat betekend voor jou een "database"

Plus dat het ergens ook wel overkill is, om überhaupt zo'n scriptje te maken, voor 25 plaatjes...

afscherming

Het zal allicht altijd sneller zijn, dan plaatjes uit een database, omdat het selecteren dan ook langer zal duren (tijd naar bepaalde record word langer) en het is afhankelijk van de grootte die het gebruikt in de DB... Plus het type van het plaatje is ook wel een factor denk ik (denk aan veel compressie, of juist niet)

wat heeft de compressie van een plaatje nu te maken met de snelheid? waar zit het verschil tussen 200kb op het FS of 200kb in een database als we over hetzelfde plaatje spreken

Overigens weet een databaseengine als het goed is door gebruik van indexen op welk exact punt bepaalde data te vinden is dus kan er in 1x daar naar toe "gesprongen" worden. itt tot een filesystem die vaak meerdere handelingen nodig heeft om de file te vinden.

Verwijderd schreef op zaterdag 26 februari 2005 @ 17:09:
Ik ben in principe tegen plaatjes in database, omdat binaire _meestal_ niet in een database thuis hoort.(zijn een paar uitzonderingen)
[...]
Mee eens.

onderbouw eens

Ben ik niet helemaal met je eens.
Een grote database met de juiste indexen kan in principe wel sneller zijn dan het filesystem.Het duurt namelijk wel even voordat het file system de hele FAT heeft doorzocht.(Volgens mij is dit al eerder genoemd in dit topic)
Maar als je het dan opdeelt in subdirectories moet het in principe wel weer sneller worden.

lijkt me juist niet, door gebruik van subdirectories heb je meer files om te doorzoeken (een directory is ook een file)

Nog een voordeel van plaatjes in een database is dat je gebruik kan maken van de functies van de database. Transactions kunnen soms erg handig zijn. Maar ik blijf bij mijn standpunt.

koppig dus

[Verwijderd]

Het lijkt me interessanter als "logisch redeneren" wordt onderbouwd met benches. Het backup punt wat Janos aangaf is iets wat gewoon sterk is. Met het juiste model kun je de database functies zoals foreign keys (naar een tabel met binaire data) goed gebruiken zodat je relaties afdwingt. Op www.content.nl worden ook alle afbeeldingen uit de database geserveerd en echt traag kan ik het niet noemen.

[ Voor 19% gewijzigd door Verwijderd op 27-02-2005 01:31 ]

[T-MOB]

Verwijderd schreef op zondag 27 februari 2005 @ 01:30:
Het lijkt me interessanter als "logisch redeneren" wordt onderbouwd met benches. Het backup punt wat Janos aangaf is iets wat gewoon sterk is. Met het juiste model kun je de database functies zoals foreign keys (naar een tabel met binaire data) goed gebruiken zodat je relaties afdwingt. Op www.content.nl worden ook alle afbeeldingen uit de database geserveerd en echt traag kan ik het niet noemen.

Je noemt hier twee verschillende zaken... Ten eerste het benchen van de hele handel wat puur op performance aankomt. Mijn punt in deze discussie is dat het voordeel van de database ophoudt als je geheugen op is. Kleinere "chunks" winnen het zodra je geaggregeerde database-tabel groter wordt dan de grootte van je geheugen.
Ten tweede noem je secundaire voordelen als het back-uppen van de hele handel. Alhoewel ik van mening ben dat je met de juiste rechten in een filessystem ook een heel eind komt, vind ik ook dat je andere aspecten mee moet nemen. Een database is in zoverre statisch dat je bij het ontwerp moet bepalen wat er in komt. Met een filesystem-implementatie kun je op een later tijdstip besluiten om wat met exif-data te gaan doen, of wat dan ook mogelijk is met een handige functie in de taal waarmee je werkt. Met een database-impementatie moet je daarvoor óf "dure" queries uitvoeren óf je database aanpassen. Kortom als backup-mogelijkheden een argument zijn, dan is flexibiliteit dat ook...

[Wolfboy]

T-MOB schreef op zondag 27 februari 2005 @ 02:52:
Een database is in zoverre statisch dat je bij het ontwerp moet bepalen wat er in komt. Met een filesystem-implementatie kun je op een later tijdstip besluiten om wat met exif-data te gaan doen, of wat dan ook mogelijk is met een handige functie in de taal waarmee je werkt. Met een database-impementatie moet je daarvoor óf "dure" queries uitvoeren óf je database aanpassen. Kortom als backup-mogelijkheden een argument zijn, dan is flexibiliteit dat ook...

Het ontwerp is wel statisch ja, maar flexibiliteit lijkt me in dit geval geen geldig argument aangezien je zoiets niet regelmatig zal veranderen en je op het moment dat het veranderd moet worden toch al een heel aantal dingen zal moeten aanpassen.
Een databaseverandering zal in dat geval hoogst waarschijnlijk niet zo'n groot probleem zijn.

[Verwijderd]

Erkens schreef op zondag 27 februari 2005 @ 00:23:

[...]

onderbouw eens

Met databases kun je meestal fijn zoeken, met binaire data vervalt die functie.
In de meeste databases kun je bijv niet zeggen: geef alle plaatjes met een blauw vierkantje erin.

[...]

lijkt me juist niet, door gebruik van subdirectories heb je meer files om te doorzoeken (een directory is ook een file)

Als je een plaatje uit een grote directory haalt met bijvoorbeeld 10000 plaatjes lijkt me slomer dan als je een directory opsplitst in 10 stukken. En vervolgens een plaatje gaat selecteren.

[...]

koppig dus

Nee verstandig :-)

De makers van mysql raden het zelfs af:

When using a normal Web server setup, images should be stored as files. That is, store only a file reference in the database. The main reason for this is that a normal Web server is much better at caching files than database contents, so it's much easier to get a fast system if you are using files.
Bron: http://dev.mysql.com/doc/mysql/en/tips.html

Even voor de duidelijkheid: Dit is alleen mysql.

Ik heb in principe geen bewijs, omdat ik geen benchmarks heb gedaan. Maar ik wel een sterk idee dat het het slomer maakt. Hier een paar modjes die het een keer geprobeerd hebben:
http://gathering.tweakers...message/10671036#10671036
http://gathering.tweakers...message/10663398#10663398

Het veranderen van een plaatje lijkt me ook niet echt prettig als ze in een db staan.

[ Voor 2% gewijzigd door Verwijderd op 27-02-2005 09:26 . Reden: quote-probleem ]

[Erkens]

Verwijderd schreef op zondag 27 februari 2005 @ 08:34:
[...]

Met databases kun je meestal fijn zoeken, met binaire data vervalt die functie.
In de meeste databases kun je bijv niet zeggen: geef alle plaatjes met een blauw vierkantje erin.

en een filesystem kan dat wel?
lijkt me wel interessant, heb je een voorbeeldje, want zoiets kan ik goed gebruiken

Als je een plaatje uit een grote directory haalt met bijvoorbeeld 10000 plaatjes lijkt me slomer dan als je een directory opsplitst in 10 stukken. En vervolgens een plaatje gaat selecteren.

moet je wel eerst die directory openen, daar de file opzoeken etc
met een database heb je direct het juiste plaatje wat je zo door kan sturen.

Het veranderen van een plaatje lijkt me ook niet echt prettig als ze in een db staan.

daar heb je een mooi punt ja, maar aan de andere kant, dat doe je meestal alleen bij het inserten .

[Verwijderd]

Verwijderd schreef op zondag 27 februari 2005 @ 08:34:
When using a normal Web server setup, images should be stored as files. That is, store only a file reference in the database. The main reason for this is that a normal Web server is much better at caching files than database contents, so it's much easier to get a fast system if you are using files.
Bron: http://dev.mysql.com/doc/mysql/en/tips.html

Zo doe ik hem momenteel ook. Het plaatje hernoemen met dezelfde ID als in de database. Zo blijft het bestand uniek en hoef je helemaal niet het filesysteem te doorzoeken ook al staan er 1000 bestanden in de directory. Want als het in de database steekt dan staat het ook op de harde schijf. Tenzij er natuurlijk iets misgelopen is. Maar het voordeel van backup werd al aangehaald voor de database implementatie.

[tjerkw]

Verwijderd schreef op zaterdag 26 februari 2005 @ 17:09:
[knip]

Ben ik niet helemaal met je eens.
Een grote database met de juiste indexen kan in principe wel sneller zijn dan het filesystem.Het duurt namelijk wel even voordat het file system de hele FAT heeft doorzocht.(Volgens mij is dit al eerder genoemd in dit topic)

Wat hebben jullie toch met FAT ??? FAT is oud en slecht. Er zijn tegenwoorden veel betere file-systems. zoals NTFS en de linux EXT3, daar gaat het zoeken naar een file snel.

Maar als je het dan opdeelt in subdirectories moet het in principe wel weer sneller worden.

dat ligt aan de implementatie van het filesystem

[Verwijderd]

Erkens schreef op zondag 27 februari 2005 @ 12:03:
[...]

en een filesystem kan dat wel?
lijkt me wel interessant, heb je een voorbeeldje, want zoiets kan ik goed gebruiken

Je begrijpt toch wel dat onder andere de handigheid van een database is dat je heel gemakkelijk dingen kunt selecteren op een criteria. Bij plaatjes is dit niet het geval.

[...]

daar heb je een mooi punt ja, maar aan de andere kant, dat doe je meestal alleen bij het inserten .

Ja maar flexibiliteit telt ook mee.

Waarom reageer je trouwens niet op de becnhmarks en het afraden van MySql?

tjerkw schreef op zondag 27 februari 2005 @ 14:40:
[...]
Wat hebben jullie toch met FAT ??? FAT is oud en slecht. Er zijn tegenwoorden veel betere file-systems. zoals NTFS en de linux EXT3, daar gaat het zoeken naar een file snel.

Nog een reden om gebruik te maken van het file-system.

[Erkens]

Verwijderd schreef op zondag 27 februari 2005 @ 16:19:
[...]

Je begrijpt toch wel dat onder andere de handigheid van een database is dat je heel gemakkelijk dingen kunt selecteren op een criteria. Bij plaatjes is dit niet het geval.

tuurlijk, maar je moet geen appels met peren vergelijken

Ja maar flexibiliteit telt ook mee.

uiteraard, maar dat zijn dingen die mee tellen bij het ontwerpen van je database structuur etc. Als je van te voren weet dat het niet nodig is hoef je dat niet mee te nemen in je argumenten

Waarom reageer je trouwens niet op de becnhmarks en het afraden van MySql?

geen tijd voor gehad om te lezen, maar die benchmarks stellen niks voor, ACM doet hier een readfile en een connectie naar een database/select/close database, ja dan is een readfile ook sneller, maar meestal heb je al een open verbinding
Dan die van dusty, ja leuk, kan ik ook schrijven, dat hun nick een andere kleur is betekend niet dat ze meteen god zijn ofzo
Het afraden van MySQL is alleen als tip ivm caching en zal enkel in bepaalde gevallen zo zijn, het is niet een afraden, maar een tip dus

[tjerkw]

Verwijderd schreef op zaterdag 26 februari 2005 @ 17:09:
[knip]
Een grote database met de juiste indexen kan in principe wel sneller zijn dan het filesystem.Het duurt namelijk wel even voordat het file system de hele FAT heeft doorzocht.(Volgens mij is dit al eerder genoemd in dit topic)

Waarom heeft iederen het toch over FAT.. FAT is een slechte oude file-system implementatie. Er zijn tegenwoordig veer betere/snellere file systems. zoals NTFS en EXT3...

Maar als je het dan opdeelt in subdirectories moet het in principe wel weer sneller worden.

hangt af van de file-system implementatie.

[Erkens]

tjerkw schreef op zondag 27 februari 2005 @ 16:44:
[...]


Waarom heeft iederen het toch over FAT.. FAT is een slechte oude file-system implementatie. Er zijn tegenwoordig veer betere/snellere file systems. zoals NTFS en EXT3...


[...]

hangt af van de file-system implementatie.

offtopic:
wat is het nut om je reply een half uur later nog eens te posten

[tjerkw]

Erkens schreef op zondag 27 februari 2005 @ 16:49:
[...]

offtopic:
wat is het nut om je reply een half uur later nog eens te posten

whahaha... ik zit nog niet zo lang op GoT.. en ik zag de verder --> knop onderaan niet.. dus ik maar denken.. waar blijft mijn bericht toch. wahah

[Verwijderd]

Erkens schreef op zondag 27 februari 2005 @ 16:25:
[...]

tuurlijk, maar je moet geen appels met peren vergelijken

Nu moet ik opeens geen appels met peren vergelijken terwijl ik het daarnet nog moest onderbouwen of binaire data meestal niet in een database thuis hoort.

[...]
uiteraard, maar dat zijn dingen die mee tellen bij het ontwerpen van je database structuur etc. Als je van te voren weet dat het niet nodig is hoef je dat niet mee te nemen in je argumenten

Het gaat volgens mij over een algemeen beeld.Dus mag je dit zeker wel meenemen. Misschien is het in jouw geval niet nodig maar bij andere wel.

[...]

geen tijd voor gehad om te lezen, maar die benchmarks stellen niks voor, ACM doet hier een readfile en een connectie naar een database/select/close database, ja dan is een readfile ook sneller, maar meestal heb je al een open verbinding
Dan die van dusty, ja leuk, kan ik ook schrijven, dat hun nick een andere kleur is betekend niet dat ze meteen god zijn ofzo

Bij ACM was het verschil dan ook redelijk groot.
Maar als je mod bent ben je meestal geen één of andere koekepeer.Dus ik geloof dat hij wel eerlijk zegt dat zijn ervaring met plaatjes in een database slecht is.(kwa snelheid)

Het afraden van MySQL is alleen als tip ivm caching en zal enkel in bepaalde gevallen zo zijn, het is niet een afraden, maar een tip dus

Een tip geven ze meestal niet zomaar.

[Erkens]

Verwijderd schreef op zondag 27 februari 2005 @ 17:08:
[...]

Nu moet ik opeens geen appels met peren vergelijken terwijl ik het daarnet nog moest onderbouwen of binaire data meestal niet in een database thuis hoort.

uiteraard moet je onderbouwen, maar jij wilt hier iets wel met je database doen wat je niet met losse files wilt doen en dat ga je dan "vergelijken" hoe wil je dat ooit vergelijken, ja zo kan ik ook negatieve punten verzinnen

Het gaat volgens mij over een algemeen beeld.Dus mag je dit zeker wel meenemen. Misschien is het in jouw geval niet nodig maar bij andere wel.

nee natuurlijk maar ook hier geld weer hetzelfde

Bij ACM was het verschil dan ook redelijk groot.
Maar als je mod bent ben je meestal geen één of andere koekepeer.Dus ik geloof dat hij wel eerlijk zegt dat zijn ervaring met plaatjes in een database slecht is.(kwa snelheid)

uiteraard weten ACM en dusty wel het een en ander, maar dat maakt hun woorden niet meteen geldig of waarheid En zo betrouwbaar lijken die tests mij ook niet

Een tip geven ze meestal niet zomaar.

hun bekijken (net als vele andere hier) maar naar enkele punten, dus die tip is niet altijd van toepassing.

[Verwijderd]

Erkens schreef op zondag 27 februari 2005 @ 17:16:
[...]

uiteraard moet je onderbouwen, maar jij wilt hier iets wel met je database doen wat je niet met losse files wilt doen en dat ga je dan "vergelijken" hoe wil je dat ooit vergelijken, ja zo kan ik ook negatieve punten verzinnen

Ik maak hiermee ook niet de vergelijking met een file-system. Ik geef hier gewoon aan waarom het niet in een database hoort.

[...]

nee natuurlijk maar ook hier geld weer hetzelfde

Ik neem aan dat we het hier hebben over het algemeen. We gaan natuurlijk niet heleboel uitzonderingen verzinnen. Als je er zin in hebt mag je dat best doen.;)

[...]

uiteraard weten ACM en dusty wel het een en ander, maar dat maakt hun woorden niet meteen geldig of waarheid En zo betrouwbaar lijken die tests mij ook niet

Ik heb geen zin in een welles/nietes discussie, maar ik denk dat hun ervaring klopt.

[...]

hun bekijken (net als vele andere hier) maar naar enkele punten, dus die tip is niet altijd van toepassing.

Ik wil wel is weten welke punten ze dan overslaan.

[Verwijderd]

Als men nu eerst is met benches komt en technische whitepapers maakt het de discussie nog nuttig, nu is het niets meer dan gissen, meningen, en dan ook nog gebaseerd op generaliseren van databasesystemen en "hoe het zou moeten zijn/werken/resulteren". Wellicht is een MSSQL of een Oracle met het serveren van binaire data veel effectiever dan een MySQL, wie weet?

[tjerkw]

ik ben het met gordijnstok eens..

En Erkens ik snap niet hoe jij blijft beweren dat Databases sneller zouden kunnen zijn dan een filesystem m.b.t. grote stukken binaire data (images).

Je hebt het over indexen in databases... nou goede file system zijn geimplementeerd met indexen/hashing dus dat gaat niet langzamerl.

En dan nog de logische redenatie waaruit volgt dat een database neit sneller kan zijn in het opslaan van plaatjes:

Een database is een extra software laag bovenop het file-system die het makkelijk/snel maakt relationele data op te slaan en weer op te vragen.. Met gewone text-files schiet dat niet op. En dan wil jij beweren dan een database sneller images kan opslaan dan een filesystem? Je hebt alleen maar meer overhead.

Overigens gaat dit niet op voor databases die direct met de hardeschijf praten en dus de Operating System laag overslaan, maar dat gebeurt doorgaans niet.

[Verwijderd]

tjerkw schreef op zondag 27 februari 2005 @ 20:03:
Een database is een extra software laag bovenop het file-system die het makkelijk/snel maakt relationele data op te slaan en weer op te vragen.. Met gewone text-files schiet dat niet op. En dan wil jij beweren dan een database sneller images kan opslaan dan een filesystem? Je hebt alleen maar meer overhead.

Overigens gaat dit niet op voor databases die direct met de hardeschijf praten en dus de Operating System laag overslaan, maar dat gebeurt doorgaans niet.

Dat bedoelde ik ook.

Verder vind ik het een goed idee van Gordijnstok, maar ik weet niet wie er allemaal mee wil werken om het te benchen. En hoe gaan we het benchen, en welke db's we gaan gebruike, enz.

[Verwijderd]

Ik heb het niet over zelf benchen? Deze vraag zal heus niet door iemand eerder zijn gevraagd en voorzien van de nodige feiten. Ik verwacht toch wel een shitload aan benches tussen filesystem en db op het web.

[ACM]

Plaatjes inladen vanaf filesystems ipv databasesystemen gaat vziw over het algemeen sneller. Hoeveel hangt af van het gebruik.

Filesystem caches in de kernels zijn, vziw, significant sneller dan userspace caches, sterker nog in MySQL en PostgreSQL wordt met de standaard tabelformaten verwacht dat de kernel de database-pages wel cached.
De blob moet eerst gelezen worden, encoded voor een of ander protocol en dan verstuurd naar de client-applicatie. Terwijl de file alleen maar gelezen hoeft te worden.
Ook de toegang tot files loopt - uiteraard - via geoptimaliseerde datastructuren en/of indices, dus ik verwacht daar geen merkbare verschillen in de DB vs FS, zelfs niet als je de ruwe disk gebruikt in de DB.

Zelfs als je dus de metadata van de afbeeldingen nog uit de DB haalt win je op de overhead van de encoding e.d. Als er geen rechtenchecks nodig zijn voor de afbeeldingen, kan je waarschijnlijk zelfs de db-connectie overslaan als je het handig aanpakt... en dan is er nog meer winst. Sterker nog, dan kan je wellicht zelfs de php-laag overslaan en rechtstreeks de afbeelding laten laden door de webserver.

[Erkens]

tjerkw schreef op zondag 27 februari 2005 @ 20:03:
En Erkens ik snap niet hoe jij blijft beweren dat Databases sneller zouden kunnen zijn dan een filesystem m.b.t. grote stukken binaire data (images).

ho ho, waar zie jij dat ik beweer dat Databases wat dat betreft sneller zijn
lees eens eerst het topic volledig voordat je domme opmerkingen gaat maken

Je hebt het over indexen in databases... nou goede file system zijn geimplementeerd met indexen/hashing dus dat gaat niet langzamerl.

ja en goede databases zullen fantastische caching mogelijkheden hebben zodat die echt niet langzamer zullen zijn

En dan nog de logische redenatie waaruit volgt dat een database neit sneller kan zijn in het opslaan van plaatjes:

Een database is een extra software laag bovenop het file-system die het makkelijk/snel maakt relationele data op te slaan en weer op te vragen.. Met gewone text-files schiet dat niet op. En dan wil jij beweren dan een database sneller images kan opslaan dan een filesystem? Je hebt alleen maar meer overhead.

En zoals ik al reeds vele malen heb gezegt: ik beweer helemaal niet dat een database hierin sneller is, en dat zal ik ook nooit doen als ik geen degelijk bewijs zie

En ik beweer volgens jou dat een database als mysql sneller op kan slaan, waar heb ik dat nu weer gezegt Normaal gesproken wil je dat informatie snel tot je beschikking staat en maakt het minder uit dat je relatief iets langer moet wachten voor het opslaan

Voor elke situatie zal je dus moeten kijken wat voor die situatie het handigst is, het snel kunnen vinden van een plaatje in een groot archief waar je vooral wilt zoeken in de meta data, dan zou je voor het opslaan in de database kunnen kiezen, zodat je de juiste data direct tot je beschikking hebt ipv eerst de metadata zoeken (in je database bijvoorbeeld) en dan het plaatje erbij pakken.

En voor de mensen die geilen op kleurtjes: mijn nick is zwart, in al mijn posts geef ik mijn mening. Ook al was mijn nick rood/groen/goud/whatever, het blijft een mening die niet getest is

Overigens gaat dit niet op voor databases die direct met de hardeschijf praten en dus de Operating System laag overslaan, maar dat gebeurt doorgaans niet.

offtopic:
gelukkig niet nee

[Verwijderd]

Performance is echter niet altijd (meestal niet) de juiste reden voor een aanpak. Het kan goed zijn dat de kleine overhead die een database zou kunnen geven niet opweegt tegen de voordelen van opslaan in een database. Dat is voor elke applicatie weer verschillend, maar ik kan me goed voorstellen dat je uit oogpunt van backup, restore, en integriteit van relaties voor opslag in de database kiest.

[tjerkw]

Erkens schreef op zondag 27 februari 2005 @ 23:14:
[...]

ho ho, waar zie jij dat ik beweer dat Databases wat dat betreft sneller zijn
lees eens eerst het topic volledig voordat je domme opmerkingen gaat maken

oh sorry, die conclusie trok ik uit je standpunten.. Maar het klopt wel dat je niet zomaar wilt geloven dat databases langzamer zijn dan in het opslaan van plaatjes dan een filesystem?

[...]

ja en goede databases zullen fantastische caching mogelijkheden hebben zodat die echt niet langzamer zullen zijn

maar het is altijd een extra layer bovenop de filesystem laag, deze layer maakt het voor plaatjes niet sneller.. voor andere relationele gegevens wel.

[...]

En zoals ik al reeds vele malen heb gezegt: ik beweer helemaal niet dat een database hierin sneller is, en dat zal ik ook nooit doen als ik geen degelijk bewijs zie

En ik beweer volgens jou dat een database als mysql sneller op kan slaan, waar heb ik dat nu weer gezegt Normaal gesproken wil je dat informatie snel tot je beschikking staat en maakt het minder uit dat je relatief iets langer moet wachten voor het opslaan

ok mijn fout

Voor elke situatie zal je dus moeten kijken wat voor die situatie het handigst is, het snel kunnen vinden van een plaatje in een groot archief waar je vooral wilt zoeken in de meta data, dan zou je voor het opslaan in de database kunnen kiezen, zodat je de juiste data direct tot je beschikking hebt ipv eerst de metadata zoeken (in je database bijvoorbeeld) en dan het plaatje erbij pakken.

[...]

offtopic:
gelukkig niet nee

en dus zijn databases trager met plaatjes dan de harde schijf. (ivm die extra layer)

Overigens maak je een goed punt door onderscheid te maken in het opslaan, doorzoeken en ophalen van gegevens. de zin "databases zijn sneller dan filesystems" is dus veels te algemeen.

[ Voor 8% gewijzigd door tjerkw op 28-02-2005 18:33 ]

[Wolfboy]

tjerkw schreef op maandag 28 februari 2005 @ 18:30:
maar het is altijd een extra layer bovenop de filesystem laag, deze layer maakt het voor plaatjes niet sneller.. voor andere relationele gegevens wel.

Hoezo zou dat?
Dat is maar afhankelijk van je doel, als je de plaatjes moet beveiligen voor gebruikers die niet ingelogd zijn dan heb je meestal maar twee mogelijkheden (uitgaande van een php/mysql combinatie)
1. opslaan in de database
2. inlezen via php

Als je daaraan toevoegt dat je veel eenvoudiger zal kunnen zoeken via de database dan kan het best sneller zijn om dat wel te doen.

Overigens maak je een goed punt door onderscheid te maken in het opslaan, doorzoeken en ophalen van gegevens. de zin "databases zijn sneller dan filesystems" is dus veels te algemeen.

Precies ja, maar volgens mij gaat het Erkens ook niet om het punt dat het filesystem sneller of langzamer zou zijn maar eerder om de mensen die gewoon maar wat uit de lucht roepen zonder het te kunnen onderbouwen.

[tjerkw]

Wolfboy schreef op maandag 28 februari 2005 @ 18:56:
[...]
Hoezo zou dat?
Dat is maar afhankelijk van je doel, als je de plaatjes moet beveiligen voor gebruikers die niet ingelogd zijn dan heb je meestal maar twee mogelijkheden (uitgaande van een php/mysql combinatie)
1. opslaan in de database
2. inlezen via php

we hebben het hier niet over beveiligen..
tuulk is een keuze om plaatjes in een database op te slaan soms te verantwoorden.. maar niet als je het over snelheid hebt.

Als je daaraan toevoegt dat je veel eenvoudiger zal kunnen zoeken via de database dan kan het best sneller zijn om dat wel te doen.

je hebt het nu over relationele gegevens.. niet specifiek over plaatjes. ik zeg dan ook.. sla de referentie naar het plaatje in je database op.. zodat zoeken snel gaat. maar zorg ervoor dat je het plaatje van de schijf haalt, niet via de database.

[...]
Precies ja, maar volgens mij gaat het Erkens ook niet om het punt dat het filesystem sneller of langzamer zou zijn maar eerder om de mensen die gewoon maar wat uit de lucht roepen zonder het te kunnen onderbouwen.

en daar heeft erkens helemaal gelijk in. maar ik probeer het toch ook te onderbouwen.

[Verwijderd]

Als ik het goed begrepen heb, is Microsoft druk doende om een database als filesystem te gaan gebruiken voor windows.

Even los daarvan kan ik wel een argument verzinnen om plaatjes iig. niet in eenzelfde tabel als data op te slaan, en dat is het zoeken naar gegevens. Stel je slaat pasfoto's op voor 10 personen. Je hebt een tabel personen, met daarin een veld pasfoto waarin het plaatje staat. Pasfoto's zijn 100Kb groot. Stel nu eens dat ik van alle 10 personen alleen de voornaam wil hebben. Je db moet dan per record voorbij 100Kb seeken. Dat lijkt me niet bevordelijk voor het ophalen van de data.

Het plaatje zelf laden zal misschien wel net zo snel gaan, maar juist bij queries waarbij je het plaatje niet nodig hebt, verlies je snelheid.

Dus dan maar een aparte tabel voor plaatjes? Kan, maar waarsch. ben je dan aan het denormaliseren.

[Voutloos]

Verwijderd schreef op maandag 28 februari 2005 @ 19:27:
Dus dan maar een aparte tabel voor plaatjes? Kan, maar waarsch. ben je dan aan het denormaliseren.

Dan heb je een extra 1:1 relatie in je model. Zo'n enge tabel zal dat ook weer niet zijn. Je hebt alleen 1 extra kolom aan extra data in je DB (namelijk het id wat erbij hoort). Normaliseren is goed, maar moet ook gewoon bewust gedaan worden. Om prestatie redenen zou je 1 minder genormaliseerde relatie kunnen gedogen.

Normaliseren doe je ook voor je integriteit en die is zelfs met de extra tabel nog hoger dan met een totaal losstaand filesystem.

Elke DB is specifiek op het gebruik toegespitst. Dus dit punt, evenals reeds besproken punten wat betreft integriteit, backuppen en snelheid, zou gewoon langs moeten komen in de ontwerpfase van het systeem.

[ Voor 22% gewijzigd door Voutloos op 28-02-2005 19:37 ]