Archief - PHP: image resizing+db storing

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

m3rlin

Legacy Member
Hey all,

Even snel een kleine uitleg van de probleemstelling van m'n scriptje:
bedoeling van het script: een image uploaden. Heel simpel.

Probleem: ik wil die images rechtstreeks in de database steken. Een longblob kan precies maar files aan rond een goeie 500k...:/ (voor kleinere files, heb ik uiteraard geen enkel probleem)

Gevolg: om niet zomaar een message te tonen aan de gebruiker : "zou je niet eerst eens resizen alvorens je het online wil zwieren ?", wou ik die images resizen on the fly en het resultaat direct saven in de db.
Wat doe ik (of wat wil ik doen liever:))? file uploaden naar de server, ze resizen, de output hiervan dan inlezen (van de nieuwe image), en deze inhoud dan in m'n LongBlob field steken in de db.

Alles gaat perfect zoals het moet, tot na het resizen. Op het einde van de resize functie return ik een imagejpg. Deze maakt automatisch de "nieuwe image aan" en toont die jammer genoeg ook onmiddellijk in de browser. Dat is net het spijtige, want ik zou die "imagejpg" eigenlijk moeten saven, om ze zo te kunnen inlezen en ze pas nadien in de db te zetten. Op het einde van het proces delete ik dan de 2 fysieke files as if nothing fysical happened


Any ideas ? :) Of iemand die hetzelfde reeds heeft willen proberen ?

(De files lokaal bewaren is ook een optie uiteraard, maar als ik alle images onder de 500k krijg in m'n db, zou dat ook geen slechte oplossing zijn imo)

Tyfius

Legacy Member
Is het niet eenvoudiger de foto's apart te bewaren en een referentie in de database op te nemen ?
Ik voorzie mijn foto's op het einde met de timestamp, om zo een uniek id te verkrijgen (indien al bestaat wel check of course sleep x->5 secs en retry).

Op die manier vermijd je een vrij zware database en kan je eenvoudig je backups bezorgen.

TheCrow7

Legacy Member
Een van de eeste regels van database ontwerp.

Gebruik een database NOOIT om grote binaire bestanden te stockeren. Een database mag enkel verwijzen naar.

BertG

Legacy Member
TheCrow7 zei:
Een van de eeste regels van database ontwerp.

Gebruik een database NOOIT om grote binaire bestanden te stockeren. Een database mag enkel verwijzen naar.
:offtopic: euh, das voor relationele databanken idd het geval...
maar voor ObjectOriented Db's is dat zeker geen waar :p

orez

Legacy Member
denk eerlijk gezegd niet dat het hier over OO DB gaat... volgens mij is MySQL nog zo ver niet geevolueerd... enkel de MSSQL 2005 ..

RpR

Legacy Member
ru`orez zei:
denk eerlijk gezegd niet dat het hier over OO DB gaat... volgens mij is MySQL nog zo ver niet geevolueerd... enkel de MSSQL 2005 ..
LOL,
denk dat het omgekeerd is.
MYSQL kan zeker al van versie 4.1 (Toen project gemaakt die dit deed)
en bij mijn weten werkt dit niet bij MSSQL omdat die geen long blobs heeft.

orez

Legacy Member
MySQL neit RpR ... je kan Object Orientated Programmeren op MySQL (met behulp van PHP 5) maar er wordt bedoeld OO IN MySQL zelf..

MySQL 5.0 komt nu nog maar af met stored procedures, view triggers, etc...
Goede stap in de goede richting, maar MySQL is een RDBMS geen OODBMS, wat MSSQL 2005 zeker en vast wel is..

RpR

Legacy Member
ru`orez zei:
MySQL neit RpR ... je kan Object Orientated Programmeren op MySQL (met behulp van PHP 5) maar er wordt bedoeld OO IN MySQL zelf..

MySQL 5.0 komt nu nog maar af met stored procedures, view triggers, etc...
Goede stap in de goede richting, maar MySQL is een RDBMS geen OODBMS, wat MSSQL 2005 zeker en vast wel is..
Toch blijft MSSQL een bullshit van een db terwijl er gratis betere db's zijn.

orez

Legacy Member
Das een typische fanboy reactie hé... MSSQL is verre van bullshit... En betere DB's? Kdenk het nie hoor ;)

Ze lijken wat op mekaar... Maar durven zeggen dat ze beter zijn..

m3rlin

Legacy Member
het is inderdaad geen hibernate toepassing ofzo :)

Nu ja, akkoord dat ik ze dan best gewoon wegschrijf (m'n oud systeem was zo)... maar dan blijf ik nog steeds met hetzelfde probleem zitten ergens. Ik zou die file namelijk ineens on the fly willen verkleinen en deze image saven op de server. Maw: niet de grote image saven en die telkens verkleinen naar bv een thumbnail. Hoe krijg ik die imagejpg() weggeschreven naar een fysieke file ? :)

m3rlin

Legacy Member
aha, thx on that one Tyfius ! Heb m'n oplossing in die code teruggevonden. Blijkbaar is de 2de parameter van imagejpg() de locatie waar je die nieuwe file wil plaatsen :)

servi

Legacy Member
steek NOOIT binaire data in een database tenzij je daar een heel goede reden voor hebt. Ik zou in uw geval eigenlijk dus opteren om het gewoon als bestanden te bewaren op je filesystem en enkel de pad naar dit bestand bewaard in je database.

Overigens is een OO-DB min of meer verkrachten waar een database eigenlijk voor staat, dus die richting zou ik eerlijk gezegd ook niet uitgaan.

DJ_Trash

Legacy Member
ru`orez zei:
Das een typische fanboy reactie hé... MSSQL is verre van bullshit... En betere DB's? Kdenk het nie hoor ;)

Ze lijken wat op mekaar... Maar durven zeggen dat ze beter zijn..


damn right Orez!
"free" doesn't mean a certain "better" DB
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan