Imagini in baze de date

[kelye]

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 ?

[stealth]

directoare ... inclusiv mysql recomanda.
pastrezi doar referinta la imagini in tabela mySQL.

[Vic]

Dap...clar directoare.

[kelye]

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

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]

[Vic]

Pana la cautari mai aprofundate, sa vedem ce argumente strangem de ambele parti. Eu optez pentru directoare, dar uite aici cateva argumente pro.

[Birkoff]

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

[shakabut]

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'.

[coditza]

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

[aurelian]

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.

[cupubboy]

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

[Radical]

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).

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 !

[carco]

Apoi, sa presupunem ca se vrea sa se taie din dreapta si de jos cate 5 pixeli (am avut o situatie de curand), ce faci daca sunt in mysql? Sau, trebuiesc redimensionate, schimbat format, ...

[kelye]

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

[carco]

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 .

[Magic]

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