Imagini in baze de date
Moderatori: coditza, Emil, Moderatori
- kelye
- Senior Member
- Mesaje: 230
- Membru din: Vin Ian 20, 2006 10:42 pm
- Localitate: Bucuresti
- Contact:
Imagini in baze de date
TITLU ORIGINAL:intrebare (existentiala) magazin virtual
deci.. am facut un magazin virtual bazat 100% pe mysql . poze tot in mysql
si vine cineva si zice "moaa.. nu e bine deloc.. trebuiau pozele direct in directoare pe hdd"
asa ca intreb si eu ca omul (decat sa caut pe google ..dar oameni suntem) ..voi ce parere aveti ?
cand ai un site cu 2000 de poze (si thumbnail si expand pic) .. e mai bine sa faci un db cu pics sau sa le pui pe hdd intr-un director /directoare ?
deci.. am facut un magazin virtual bazat 100% pe mysql . poze tot in mysql
si vine cineva si zice "moaa.. nu e bine deloc.. trebuiau pozele direct in directoare pe hdd"
asa ca intreb si eu ca omul (decat sa caut pe google ..dar oameni suntem) ..voi ce parere aveti ?
cand ai un site cu 2000 de poze (si thumbnail si expand pic) .. e mai bine sa faci un db cu pics sau sa le pui pe hdd intr-un director /directoare ?
- kelye
- Senior Member
- Mesaje: 230
- Membru din: Vin Ian 20, 2006 10:42 pm
- Localitate: Bucuresti
- Contact:
se poate sa si argumentati va rog ?
adica e util asa .. macar un "am incercat eu si merge mai bine cu .."
Later edit:
sa ma argumentez si eu ..de ce folosesc bd
- pozele sunt de dimensiuni mici si nu ar fi mare problema ( la 2200+ poze si thumbnail aferent am 160,817 KB db)
- nu ma intereseaza numele pozei ci doar id-ul ei ..fiecare produs are id unic si poza unica deci slabe sanse sa le incurc
- multa usurinta in update (in loc sa sterg de pe hdd 2 poze si sa uploadez alte 2 doar modific o inregistrare in mysql)
Birkoff
faza e ca ori am un director cu 4000 de poze ori am o structura de directoare care sa respecte categoriile/subcategoriile magazinului
problema la mine a fost ca la un moment dat nenea a vrut sa uneasca 2 categorii (30-100 de produse) si sa mute unele subcategorii in alte categorii.. per total cam 200 de inregistrari..daca aveam directoare eram mort... asa.. fiecare produs legat de un id poza.. m-a durut in brisca in ce categorii/subcategorii sunt produsele
select * from table fac doar pe produse .. si acolo am chiar mai putin de un nume pt poza.. am un id.. un int
shakabut
-dump-ul meu total are 300 mb .. hosting-ul ma lasa query-uri de 50 mb max, cand faci dump poti sa setezi de la ca record la ce record sa faca dump.. iti faci cate dump-uri vrei si de ce marime vrei
si oricum..faci asta o data nu zilnic si nici macar lunar.
per total .. manipularea mi se pare MULT mai facila cu bd
[/quote]
adica e util asa .. macar un "am incercat eu si merge mai bine cu .."
Later edit:
sa ma argumentez si eu ..de ce folosesc bd
- pozele sunt de dimensiuni mici si nu ar fi mare problema ( la 2200+ poze si thumbnail aferent am 160,817 KB db)
- nu ma intereseaza numele pozei ci doar id-ul ei ..fiecare produs are id unic si poza unica deci slabe sanse sa le incurc
- multa usurinta in update (in loc sa sterg de pe hdd 2 poze si sa uploadez alte 2 doar modific o inregistrare in mysql)
Birkoff
daca schimb structura site-ului si am nevoie doar de poze iar tre sa fac un script sa extrag doar pozele din bd..
faza e ca ori am un director cu 4000 de poze ori am o structura de directoare care sa respecte categoriile/subcategoriile magazinului
problema la mine a fost ca la un moment dat nenea a vrut sa uneasca 2 categorii (30-100 de produse) si sa mute unele subcategorii in alte categorii.. per total cam 200 de inregistrari..daca aveam directoare eram mort... asa.. fiecare produs legat de un id poza.. m-a durut in brisca in ce categorii/subcategorii sunt produsele
2. la select * from tabel merge greu cand sunt mult poze, mai ales daca am multe interogari...
select * from table fac doar pe produse .. si acolo am chiar mai putin de un nume pt poza.. am un id.. un int
shakabut
-dump-ul meu total are 300 mb .. hosting-ul ma lasa query-uri de 50 mb max, cand faci dump poti sa setezi de la ca record la ce record sa faca dump.. iti faci cate dump-uri vrei si de ce marime vrei
si oricum..faci asta o data nu zilnic si nici macar lunar.
per total .. manipularea mi se pare MULT mai facila cu bd
[/quote]
Ultima oară modificat Mie Mar 01, 2006 1:10 pm de către kelye, modificat de 2 ori în total.
- Birkoff
- Senior Member
- Mesaje: 6380
- Membru din: Joi Mar 18, 2004 2:34 pm
- Localitate: Bucuresti
- Contact:
Recomand directoare pentru ca uite ce dezavantaje am eu daca fac in bd:
1. complicat la exportul bazei de date, mai ales la dimensiuni mari de poze, uneori daca e baza de date prea mare din cauza pozelor ma chinui mult pana o export pe toata...
2. la select * from tabel merge greu cand sunt mult poze, mai ales daca am multe interogari...
3. daca schimb structura site-ului si am nevoie doar de poze iar tre sa fac un script sa extrag doar pozele din bd...
4. mie sincer mi se pare mai simplu sa bag doar numele pozei in bd si in rest sa ma joc din php
1. complicat la exportul bazei de date, mai ales la dimensiuni mari de poze, uneori daca e baza de date prea mare din cauza pozelor ma chinui mult pana o export pe toata...
2. la select * from tabel merge greu cand sunt mult poze, mai ales daca am multe interogari...
3. daca schimb structura site-ului si am nevoie doar de poze iar tre sa fac un script sa extrag doar pozele din bd...
4. mie sincer mi se pare mai simplu sa bag doar numele pozei in bd si in rest sa ma joc din php
1) CMS, ERP, CRM, etc... (doar pentru clienti))
2) Portofoliu, servicii, contact, blog
3) Folositi aceasta clasa sql in proiectele voastre (open source)
4) Vrei un magazin virtual la cheie, usor de folosit, cu api-uri incluse pentru maximizarea vanzarilor si multe alte facilitati? Da un semn si discutam.
2) Portofoliu, servicii, contact, blog
3) Folositi aceasta clasa sql in proiectele voastre (open source)
4) Vrei un magazin virtual la cheie, usor de folosit, cu api-uri incluse pentru maximizarea vanzarilor si multe alte facilitati? Da un semn si discutam.
-
- PHPRomania Supporter
- Mesaje: 7
- Membru din: Vin Feb 17, 2006 3:52 pm
- Localitate: Pitesti
- Contact:
Directoare!
Argumentatie stupida: am avut candva un client care avea un site cu galerie foto. Tinea pozele pe baza de date. A trimis un zip cu codul si un dump cu baza. Zipul avea 200 de kilo si baza 20 de mega. La vremea respectiva nu se auzise de Navicat si am pierdut aprox. 3 ore sa sparg dump-ul in 10 dump-uri de maxim 2048 de kilo, cate cerea PHPMyAdminu'.
Argumentatie stupida: am avut candva un client care avea un site cu galerie foto. Tinea pozele pe baza de date. A trimis un zip cu codul si un dump cu baza. Zipul avea 200 de kilo si baza 20 de mega. La vremea respectiva nu se auzise de Navicat si am pierdut aprox. 3 ore sa sparg dump-ul in 10 dump-uri de maxim 2048 de kilo, cate cerea PHPMyAdminu'.
directoare. (de fapt eu le pun de obicei intr-un dir mare pozele mari si un alt dir mare pozele mai mici)
daca le tin in db atunci:
- toate trebuie sa fie in acelasi format (eg, numai jpeguri, sau gifuri sau mai stiu eu ce)
- trebuie sa pastrez si dimensiunile pozelor in tabela.
- trebuie inca un script care sa afiseze pozele
daca le tin in db atunci:
- toate trebuie sa fie in acelasi format (eg, numai jpeguri, sau gifuri sau mai stiu eu ce)
- trebuie sa pastrez si dimensiunile pozelor in tabela.
- trebuie inca un script care sa afiseze pozele
function foo() { foo(); }
-
- Senior Member
- Mesaje: 833
- Membru din: Dum Iun 01, 2003 7:54 pm
- Localitate: Bucuresti
- Contact:
aplicatii enterprize: baza de date sau server dedicat (doar pagini statice).
Cand ai 7-8 servere intr-un cluster ar trebui sa pastrezi tonele de fisiere binare dintr-o aplicatie pe fiecare server in parte => 8 x tona = spatiu total.
In cazul asta se poate merge pe stocare in baza de date.
Poate o idee mai buna si poate mai recomandata: aparitia unui server ce va servi doar poze (sau alte tipuri de fisiere binare).
Si Y! are asa ceva.
Un server web lighttpd e super bun pentru treaba asta.
dar cum noi suntem programatori web de cartier nu e prea probabil sa ne intalnim cu asa ceva.
Am observat ca in baza de date se intampla lucruri suspecte cu spatiul ocupat pe HDD, dupa stergeri, inserari repetate.
Cand ai 7-8 servere intr-un cluster ar trebui sa pastrezi tonele de fisiere binare dintr-o aplicatie pe fiecare server in parte => 8 x tona = spatiu total.
In cazul asta se poate merge pe stocare in baza de date.
Poate o idee mai buna si poate mai recomandata: aparitia unui server ce va servi doar poze (sau alte tipuri de fisiere binare).
Si Y! are asa ceva.
Un server web lighttpd e super bun pentru treaba asta.
dar cum noi suntem programatori web de cartier nu e prea probabil sa ne intalnim cu asa ceva.
Am observat ca in baza de date se intampla lucruri suspecte cu spatiul ocupat pe HDD, dupa stergeri, inserari repetate.
-
- PHPRomania Supporter
- Mesaje: 9
- Membru din: Mar Mai 20, 2003 2:51 pm
- Localitate: Bucuresti
- Contact:
aurelian scrie:aplicatii enterprize: baza de date sau server dedicat (doar pagini statice).
Cand ai 7-8 servere intr-un cluster ar trebui sa pastrezi tonele de fisiere binare dintr-o aplicatie pe fiecare server in parte => 8 x tona = spatiu total.
In cazul asta se poate merge pe stocare in baza de date.
Poate o idee mai buna si poate mai recomandata: aparitia unui server ce va servi doar poze (sau alte tipuri de fisiere binare).
Si Y! are asa ceva.
Un server web lighttpd e super bun pentru treaba asta.
dar cum noi suntem programatori web de cartier nu e prea probabil sa ne intalnim cu asa ceva.
Am observat ca in baza de date se intampla lucruri suspecte cu spatiul ocupat pe HDD, dupa stergeri, inserari repetate.
Da .. mai ales la blob sau text ... tabelele se fragmenteaza pentru ca raman goluri in ele .. si atunci trebuie folosita comanda optimize des
-
- Senior Member
- Mesaje: 327
- Membru din: Lun Feb 16, 2004 2:40 pm
- Localitate: Bucuresti
- Contact:
Directoare
Motivatie: CACHE + minimizarea consumului de resurse !
Pentru fiecare poza ai o cerere catre server -> care o paseaza mai departe la PHP care o paseaza mai departe -> la baza de date... rezulta folosire mai mare pe proc. mai mult memorie... etc.
Multe pagini PHP sunt trimise cu headere ca expirate deja si nu stau in cache... rezulta nefolosirea celor mai triviale forme de CACHE... CACHE-ul facut de browser(e).
In schimb daca poza este "oferita" direct de SERVER-ul web... se scuteste timpul de pe proc. timpul de pe DB... masina e mai libera... etc. si in plus... daca bowserul o are deja in CACHE i se intoarce un Header ... cu "Not modified"... astfel se scuteste un transport suplimentar de date...
Mai mult... odata oferita de server... printre headere se adauga si:
Content-Length: 17579
Lucru care ajuta daca imaginea nu a fost transmisa corect... blablabla... poate exista vre-un browser care verifica... lungimea... si reface cererea daca nu corespunde !
Presupunand ca fiecare produs are un identificator (fie un ID fie o cheie commpusa care identifica unic imaginea... nu coneaza) eu am folosit intotdeauna:
./imgs/prod_mari/IDENTIFICATOR.gif
./imgs/prod_mici/IDENTIFICATOR.gif
Nu ai decat de uploadat o poza... a doua este redimensionata automat de GD...
La delete ai de sters ori 2 poze ori... fiindca sunt foarte mici le lasi acolo... oricum nimeni nu mai pointeaza catre ele !
Motivatie: CACHE + minimizarea consumului de resurse !
Pentru fiecare poza ai o cerere catre server -> care o paseaza mai departe la PHP care o paseaza mai departe -> la baza de date... rezulta folosire mai mare pe proc. mai mult memorie... etc.
Multe pagini PHP sunt trimise cu headere ca expirate deja si nu stau in cache... rezulta nefolosirea celor mai triviale forme de CACHE... CACHE-ul facut de browser(e).
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
In schimb daca poza este "oferita" direct de SERVER-ul web... se scuteste timpul de pe proc. timpul de pe DB... masina e mai libera... etc. si in plus... daca bowserul o are deja in CACHE i se intoarce un Header ... cu "Not modified"... astfel se scuteste un transport suplimentar de date...
Mai mult... odata oferita de server... printre headere se adauga si:
Content-Length: 17579
Lucru care ajuta daca imaginea nu a fost transmisa corect... blablabla... poate exista vre-un browser care verifica... lungimea... si reface cererea daca nu corespunde !
Presupunand ca fiecare produs are un identificator (fie un ID fie o cheie commpusa care identifica unic imaginea... nu coneaza) eu am folosit intotdeauna:
./imgs/prod_mari/IDENTIFICATOR.gif
./imgs/prod_mici/IDENTIFICATOR.gif
Nu ai decat de uploadat o poza... a doua este redimensionata automat de GD...
La delete ai de sters ori 2 poze ori... fiindca sunt foarte mici le lasi acolo... oricum nimeni nu mai pointeaza catre ele !
- kelye
- Senior Member
- Mesaje: 230
- Membru din: Vin Ian 20, 2006 10:42 pm
- Localitate: Bucuresti
- Contact:
domnul Radical .. ai fost cel mai convingator ... clar .. si nu atat pentru resurse and cache and stuff ( cu toate ca nu sunt deloc de neglijat) ci pentru ca m-a lovit simplitatea stocarii ..
nu stiu de ce asociam stocarea in directoare cu denumiri reprezentative pentru produs ( copiator_canon_f23.jpg) cand de fapt poti face un simplu rename cu un id pe care il poti folosi la fel in baza de date ..
gata.. sunt convertit ..directoare ..
em@il : nu sunt sigur ca vad o posibilitate de a face asta usor/automat nici daca ar fi real files nu mydsql ... dar sunt sigur ca vei avea amabilitatea sa share some valuable info on that
nu stiu de ce asociam stocarea in directoare cu denumiri reprezentative pentru produs ( copiator_canon_f23.jpg) cand de fapt poti face un simplu rename cu un id pe care il poti folosi la fel in baza de date ..
gata.. sunt convertit ..directoare ..
em@il : nu sunt sigur ca vad o posibilitate de a face asta usor/automat nici daca ar fi real files nu mydsql ... dar sunt sigur ca vei avea amabilitatea sa share some valuable info on that
-
- Senior Member
- Mesaje: 2799
- Membru din: Joi Mai 27, 2004 4:36 pm
- Localitate: Bucuresti
- Contact:
kelye scrie:em@il : nu sunt sigur ca vad o posibilitate de a face asta usor/automat nici daca ar fi real files nu mydsql ... dar sunt sigur ca vei avea amabilitatea sa share some valuable info on that
nimic magic, just ImageMagick (see convert) Eu a tb. sa tai shadowul (de 5px) care era peste un fundal negru cand site-ul a trecut de la backround negru la background alb .
Programator cu experienta in Magento/ZF, Typo3/Flow3, Symfony, B2B, CRM, ERP, SMB... vand betoniera
eu folosesc stocarea pozelor pe hdd, si cum multe persoane fac upload la poze incontinuu ... se pot nimerii nume identice ....
de aceea ... nici o poza nu ramane cu numele ei
$s1 = rand(1, 9999999999);
$s2 = rand(1, 9999999999);
$s3 = rand(1, 9999999);
....
salvez imaginea cu $s1."_".$s2."_".$s3.".jpg" .. si am rezolvat ..
chestia cu salvatul imaginii in db .. e cea mai mare prostie ... asta e parerea mea ... sincer .. e de ajuns ... id si numepoza ... atat ...
si asa am multe probleme cu db, pentru ca in permanenta se scrie in ea ...si nu o data la 1 min, ci cam 1000 de query-uri la 8 secunde ...
nu as face decat sa ingreunez ... totul .. cu toate ca serverul este un HP Proliant DL 580 G2 cu vreo 4 procesoare ... si asa db pica uneori
de aceea ... nici o poza nu ramane cu numele ei
$s1 = rand(1, 9999999999);
$s2 = rand(1, 9999999999);
$s3 = rand(1, 9999999);
....
salvez imaginea cu $s1."_".$s2."_".$s3.".jpg" .. si am rezolvat ..
chestia cu salvatul imaginii in db .. e cea mai mare prostie ... asta e parerea mea ... sincer .. e de ajuns ... id si numepoza ... atat ...
si asa am multe probleme cu db, pentru ca in permanenta se scrie in ea ...si nu o data la 1 min, ci cam 1000 de query-uri la 8 secunde ...
nu as face decat sa ingreunez ... totul .. cu toate ca serverul este un HP Proliant DL 580 G2 cu vreo 4 procesoare ... si asa db pica uneori
Cine este conectat
Utilizatori ce ce navighează pe acest forum: Niciun utilizator înregistrat și 31 vizitatori