plaatjes in db opslaan??

[Verwijderd]

Ik heb weleens gehoord dat dat kan, maar ik kan er weinig over vinden, ik wil dat doen met php4 en mysql, weet iemand hier iets van?? En zoja, hoe zit het dan met de chache van de browser, heb je die dan ook nog gewoon? Maar het belangrijkste is natuurlijk hoe je ze opslaat en terughaalt, duh....

[Tim]

blob()

[Blubber]

Ja maar hoe gooi je daar via HTML/PHP een plaatje in?

[WouZz]

Hier staat een aardige tutorial over het opslaan van binaire data in je db...

Ik heb dit ook eens gedaan maar had problemen met het restoren van een mysql-dump.. kwam volgens mij door alle quotes en ge-escape-de quotes, maar het ging in ieder geval niet goed.. moest uiteindelijk alles weer opnieuw uploaden Bovendien is het een extra belasting op je db... Als ik jou was zou ik die plaatjes gewoon als bestand opslaan en eventueel de info die erbij hoort in je db zetten...

[Verwijderd]

ja ik kan in je argument komen, maar het is voor een nieuwssite, met iets van 10 plaatjes per dag, nu wordt alles in een dir gesaved, met de newsID, maar dat wordt op den duur een flinke chaos, zeker als je meerdere plaatjes hebt en het wordt helemaal gek als je ook nog meerdere pagina's hebt

moet je voor de lol eens op cnn.com kijken, en in wat nieuws etc kijken, die url die je dan krijgt is echt NIET logisch....

maargoed ik ga wat proberen, als je het eindresultaat wil hebben, moet je het ff zeggen....

[WouZz]

Ik benoem mn plaatjes meestal met een timestamp.. dan zit je goed zolang je niet meer dan een afbeelding per seconde upload.. en als je er meer per seconde upload, kan je er altijd nog een microtime() aan vast plakken... Bovendien kan je dan aan de bestandsnaam zien wanneer ie is upgeload

Bdw, doen ze bij t.net geloof ik ook...

[Verwijderd]

Ik doe het ook in databases maar ik ben meer voorstander van een georganiseerde dir structuur.

Ik weet niet of het ook klopt, maar mijn beeld is dat ie de DB zoveel mogelijk in zijn geheugen laad en dat is niet nodig voor plaatjes?

Dus gewoon omschrijving, groote, afmetingen en de locate van het plaatje opslaan in de DB en dan in /dbimages/2000/12/braggelID.jpg het plaatje opslaan lijkt mij beter

[bartvb]

Deze vraag komt om de zoveel tijd ook langs op de MySQL mailinglist.. Standaard antwoord is inderdaad BLOB, maar het is heeeel slecht om plaatjes in je DB te gaan duwen.

DB's zijn helemaal niet blij met veel data in tabellen (worden ze traag en groot van) verder doe je helemaal niets in een tabel met een plaatje, je kan er niet op selecten (behalve op de grootte), je kan er niet op sorteren, helemaal niets.

Verder is het zo dat Apache and the like veeeeel beter zijn in het cachen van plaatjes dan in het cachen van database content (die cachen ze dus gewoon niet ).

Maw, eigenlijk _altijd_ je afbeeldingen als file opslaan.
Als je een autoincrement field hebt kan je dat ID toch gewoon gebruiken voor je bestandsnaam? En die dir hoef je zelf verder nooit meer in te kijken, je zorgt gewoon dat jou DB app netjes plaatjes aanmaakt en verwijderd..

[raptorix]

Gewoon beste van beide nemen, je zet de images in je database, vervolgens doe je bijvoorbeeld 1 keer per dag een batch opdracht die alle images naar een directory saved, het mooie is dat je snelheid naar je users optimaal is en dat je wel de organisatie van je database hebt, vrijwel elke grote site met grote database structuren doet dit, niet alleen voor images maar ook voor hun html, Serverside caching heet dit.

[Verwijderd]

Ik zou geen plaatjes in een database opslaan. Een database is fijn om dingen op te zoeken, maar je kunt niet tegen een database zeggen: ik wil alle plaatjes met een cirkeltje ofzo....

Als je gewoon de bestandsnaam er in zet dan kun je die eruit halen en dan door je webserver het plaatje laten ophalen. En apache is vele malen sneller in dat geval dan je database.

En je database wordt alleen maar log en groot van al die plaatjes.

[bartvb]

NemO:
Je neemt me de woorden uit de mond

[Verwijderd]

Ik moest ook zo nodig plaatjes in een Blobje stoppen, en alle boven beschreven nadelen kwamen aan de orde met 't commando fopen en nog wat van dat soort commands leest php 't plaatje in als een *heleboel* tekens die in een longblob field worden gepropt. Supertje traag en ik zie eigenlijk geen voordelen versus file opslag...

[raptorix]

Nemo je kan ze best opslaan in de database, dat is het punt niet het is alleen niet slim om ze continue van de server naar de client te sturen, dan is het handiger om ze 1 keer per dag gewoon naar een distributie dir te plaatsen en ze van daar naar de client te sturen, kijk als jij je resources in de database zet heb je wel voordelen bij bijvoorbeeld replicatie of backup, en zeker als je te maken hebt met zaken die vaak gewijzigt worden dan kan het groot voordeel zijn als het in een database staat.

[sebas]

http://www.koehntopp.de/php/faq-14.html#ss14.14

weliswaar in het Duits, maar weliswaarder waardevol en naja, je komt er wel uit

[Verwijderd]

/me zou nog steeds wel eens overtuigende argumenten willen zien waarom een filesystem wel kan wat een database niet kan.

[Verwijderd]

Op zaterdag 16 december 2000 01:55 schreef Arien het volgende:
/me zou nog steeds wel eens overtuigende argumenten willen zien waarom een filesystem wel kan wat een database niet kan.

Lijkt me niet zo moeilijk. Een filesystem (in de simpelste vorm) is een set pointers (index)en een database is een file.
Kun je je voorstellen wat er gebeurt als je plaatjes in je FAT stopt ? Alles heeft zijn specifieke toepassingsgebied.

[Verwijderd]

is een cache maken niet een id, dus als een plaatje aangeroepen wordt in een dir plaatsen, en vervolgens kijken oftie x uur niet meer wordt gebruikt en dan weer deleten??

Als ik dit zo lees, denk ik toch meer aan het plaatje in een dir op te slaan met een timestamp, maar aan de andere kant vind ik dus dat je de text in de db opslaat, dus moet je ook de plaatjes in een db opslaan, dit blijft administratief het mooist....

[bartvb]

Stukje van een posting op de MySQL mailinglist:

Consider the two senarious:

to show db images:
- the image is first read from the data file into MySQL record buffer
- from the record buffer the image goes into the socket
- the application reads it from the socket into its internal buffer
- the contents of the internal buffer are forwarded to the user

file system, not even super highly optimized:
- the image is read from the data file into internal buffer of the web
server.
- the contents of the internal buffer are forwarded to the user

[Verwijderd]

bartvb: Stukje van een posting op de MySQL mailinglist: [..]

Dat is MySQL en er zijn andere databases.

[Ritch]

Op dinsdag 19 december 2000 02:12 schreef Arien het volgende:
Dat is MySQL en er zijn andere databases.

Kijk dan ff hier naar:

Op woensdag 13 december 2000 20:01 schreef Thunderbird het volgende:
Ik heb weleens gehoord dat dat kan, maar ik kan er weinig over vinden, ik wil dat doen met php4 en mysql, weet iemand hier iets van?? En zoja, hoe zit het dan met de chache van de browser, heb je die dan ook nog gewoon? Maar het belangrijkste is natuurlijk hoe je ze opslaat en terughaalt, duh....

Je bent nu dus de discussie naar het algemene probleem aan het verschuiven (die zal wel niet op iets anders uitlopen dan alle vorige discussies hierover ), het gaat hier wel degelijk om mysql dus, dus is het gewoon geen goed idee om plaatjes in je mysql database op te slaan

[raptorix]

Op zaterdag 16 december 2000 03:30 schreef liekens het volgende:

[..]
Lijkt me niet zo moeilijk. Een filesystem (in de simpelste vorm) is een set pointers (index)en een database is een file.
Kun je je voorstellen wat er gebeurt als je plaatjes in je FAT stopt ? Alles heeft zijn specifieke toepassingsgebied.

Ja maar in een fat of welk ander disk indelingssysteem kan je geen versiecontrole doen, en dat is juist vaak 1 van de redenen waarom men images of andere binaries in een DB Propt.

[Verwijderd]

Alles heeft voor en nadelen.
Belangrijk punt voor opslaan in de database : consistentie van je data!
Een plaatje wegdonderen op je FS en de data in je database naar de haaien.

Oracle (!) zegt overigens in een FAQ (over iFS; kort door de bocht : het opslaan van files in de database)

Q: How does Oracle Internet File System perform compared to networked file systems?

A: When compared to networked file systems for file operations, the response times of a well-tuned Internet File System system are roughly twice as long (between the same and three times as long). This has been measured for SMB and HTTP using two industry-standard benchmarks, and through simple Puts and Gets using FTP.

When compared to networked file systems for searching operations, Oracle Internet File System is hundreds to millions of times faster (depending on the size of the content to be searched), because it has a built-in content, server-side search engine, rather than having to retrieve content over the network to search it.

Je moet dus kiezen.

[Verwijderd]

Ritch: Je bent nu dus de discussie naar het algemene probleem aan het verschuiven (die zal wel niet op iets anders uitlopen dan alle vorige discussies hierover )

Omdat de vraag of je het moet doen IMHO iets ingewikkelder is dan ja of nee en het bv ook van je RDBMS afhangt.

[Verwijderd]

sjako: Q: How does Oracle Internet File System perform compared to networked file systems?

A: When compared to networked file systems for file operations, the response times of a well-tuned Internet File System system are roughly twice as long (between the same and three times as long). This has been measured for SMB and HTTP using two industry-standard benchmarks, and through simple Puts and Gets using FTP.

Vraag blijft alleen waar dat aan ligt: aan IFS, aan het RDBMS, etc...

[Killemov]

Van http://developer.netscape.com/docs/manuals/htmlguid/index.htm

Aan de clientkant:
<FORM ENCTYPE="multipart/form-data"
ACTION="http://www.ikke.nl/slurpplaatje" METHOD="POST">
<P>File name:
<INPUT NAME="PLAATJE" TYPE="file">
</FORM>

Aan de serverkant heb je legio oplossingen om je plaatjes op te slaan op het filesysteem of in een db. Dit hangt van heeeeel veel factoren af. Ik werk zelf met een systeem van een virtueel filesysteem in de database (ORDBMS=Informix), zodat er aan de buitenkant geen verschil te zien is tussen filesysteem of db. Plaatjes in de db bevallen mij trouwens prima!