Vraagje over database blobs (MySQL) en (de taal) C

[SvMp]

Ik heb twee vraagjes over blobs in databases, MySQL in mijn geval, en de benadering daarvan vanuit de programmeertaal C.

1. Ik wil plaatjes (cdhoesjes) opslaan in een database. Dat wil ik doen door de imagedata in blobs te stoppen. Ook kunnen er lyrics in de database, ook in blobs.
De vraag die mij bezighoudt is: Maakt het wat uit voor de performance of ik al mijn data samen met de blobs in 1 grote database opsla, of dat ik de blobs in een aparte database opsla?

2. Blobs lijken qua gedrag nogal op grote strings met een (bijna) onbepaalde lengte. Hoe kan ik vanaf de taal C fatsoenlijk die image-data in die blob krijgen? Image-data is binair, daar zitten dus ook tekens bij zoals ASCII 0. Moet ik met die binaire data nog wat bijzonders doen voordat ik het in die blob kan zetten zonder problemen? En geldt dit ook voor het er uit lezen?
Ik heb met de search op GoT talloze voorbeelden gevonden voor PHP, maar over C en de behandeling van binaire data in blobs niks.

[farlane]

Blob is Blob. Een 0 in een blob is dus nix bijzonders ...

[Apollo_Futurae]

los van je probleem lijkt het me netter om de plaatjes flat file op te slaan en in de db alleen een verwijzing naar de lokatie van het plaatje op te nemen.
relationele databases zijn tenslotte bedoeld voor relationele gegevens. grote hoeveelheden ongerelateerde data, zoals plaatjes, hoor je flat file op te slaan.

[ProgrammerX]

Apollo_Futurae schreef op 05 oktober 2002 @ 23:11:
los van je probleem lijkt het me netter om de plaatjes flat file op te slaan en in de db alleen een verwijzing naar de lokatie van het plaatje op te nemen.
relationele databases zijn tenslotte bedoeld voor relationele gegevens. grote hoeveelheden ongerelateerde data, zoals plaatjes, hoor je flat file op te slaan.

Het opslaan van documenten in een blob werkt best goed hoor. Je moet alleen een beetje rekening houden met de manier hoe je hiermee omgaat. Je moet natuurlijk niet overdrijven hiermee en gewoon maar alles in een database flikkeren. Daarnaast kun je een paar optimalisaties uitvoeren zoals niet meteen het plaatje over te halen, maar dit door een aparte query te laten uitvoeren als de gebruiker dit wenst (dus niet met elke cd alvast het plaatje ophalen als je door de records heengaat). Daarnaast kun je deze blobs i.c.m. een OLE container gebruiken die deze documenten ook kan comprimeren enzo.

Tevens heeft het opslaan van de documenten in de database zelf ook voordelen boven het opslaan als flatfile. Zo heb je bijvoorbeeld meer controle over het document en kan het niet zo maar per ongeluk verwijderd worden. Daarnaast is het document dan vanuit alle werkstations beschikbaar en niet alleen vanaf diegene die leesrechten hebben op de locatie waar jij dan de plaatjes zou opslaan enz.

Edit : dit gaat er ff vanuit dat je bedoeld met flatfile het opslaan van de plaatjes bijvoorbeeld in een aparte map "images" ofzo.

[ACM]

Als je in je mysql database gebruik maakt van het InnoDB filesystem kan het nuttig zijn de images-tabel daar niet in op te slaan, maar in een myisam tabel (veel sneller). Tenzij je erg veel wijzigingen eraan doet en veel gebruikers hebt (exclusive tablelocks op de hele tabel ipv op de row).

Verder zal het weinig zin hebben de boel in een aparte database op te slaan, in losse tabellen helpt natuurlijk wel...

[raptorix]

Apollo_Futurae schreef op 05 oktober 2002 @ 23:11:
los van je probleem lijkt het me netter om de plaatjes flat file op te slaan en in de db alleen een verwijzing naar de lokatie van het plaatje op te nemen.
relationele databases zijn tenslotte bedoeld voor relationele gegevens. grote hoeveelheden ongerelateerde data, zoals plaatjes, hoor je flat file op te slaan.

Blob data bevind zich meestal ook in aparte files in de database, dus dat los opslaan gebeurt meestal al door de databases zelf, daarnaast kan het best handig zijn als je database waakt over de blob data, iets wat niet kan als je het in losse filetjes opslaat.

[ACM]

raptorix schreef op 06 oktober 2002 @ 03:15:
Blob data bevind zich meestal ook in aparte files in de database, dus dat los opslaan gebeurt meestal al door de databases zelf, daarnaast kan het best handig zijn als je database waakt over de blob data, iets wat niet kan als je het in losse filetjes opslaat.

In mysql niet...
En blob volgens mij juist niet "meestal"

[SvMp]

Apollo_Futurae schreef op 05 oktober 2002 @ 23:11:
los van je probleem lijkt het me netter om de plaatjes flat file op te slaan en in de db alleen een verwijzing naar de lokatie van het plaatje op te nemen.
relationele databases zijn tenslotte bedoeld voor relationele gegevens. grote hoeveelheden ongerelateerde data, zoals plaatjes, hoor je flat file op te slaan.

De discussie blob - filesystem komt regelmatig voor in dit soort topics, en dergelijke discussies heb ik al gelezen. Ik kies hier bewust voor de opslag in de database wegens het beheer van de rechten, wat met een filesystem veel meer gedoe is.

[SvMp]

farlane schreef op 05 oktober 2002 @ 22:01:
Blob is Blob. Een 0 in een blob is dus nix bijzonders ...

Dat snap ik..

Maar je moet data in de tabel zetten met het INSERT INTO commando. Op de commando-regel moet dus ook de data van de blob. Die data moet je daarbij in een string opslaan, en daar mogen niet zomaar ASCII 0-en en andere speciale tekens in voor komen. Of zie ik dat verkeerd

[Ericston]

Je kan een binary safe string type als BSTR gebruiken denk ik.

[ACM]

svdmeer schreef op 06 oktober 2002 @ 17:23:
Maar je moet data in de tabel zetten met het INSERT INTO commando. Op de commando-regel moet dus ook de data van de blob. Die data moet je daarbij in een string opslaan, en daar mogen niet zomaar ASCII 0-en en andere speciale tekens in voor komen. Of zie ik dat verkeerd

(real_)mysql_escape_string helpt je daar mee geloof ik

[Soultaker]

De MySQL C API documentatie al eens doorgekeken? Hiermee zou het wel moeten lukken.

offtopic:
Grrr, damn you, ACM.

[ACM]

Soultaker schreef op 06 oktober 2002 @ 18:09:

offtopic:
Grrr, damn you, ACM.

offtopic:
10 minuten eerder ...
Was je zolang bezig met opzoeken van die link?

[Soultaker]

ACM schreef op 06 oktober 2002 @ 18:11:
10 minuten eerder ...
Was je zolang bezig met opzoeken van die link?

Hmm, nee, die staat bovenaan als je in Google "MySQL C API" intypt. Had wat meer tabs open en had verzaakt te refreshen alvorens te replyen. (Quick reply is ook veel te handig.)

[ Voor 0% gewijzigd door Soultaker op 06-10-2002 18:15 . Reden: typo ]