Imagini in baze de date

[black diamond]

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

Daca avem numele fisierului format din $nume si $extensie, de ce nu $nume_nou=$nume."-".$s1."_".$s2."_".$s3.".".$extensie; ?

[kelye]

si de ce ma rog nu poti sa faci un :
[php]
for ($i=1; ; $i++)
{
if ( ! is_file($nume_poza . '_' . $i .'.jpg') )
{
$nume_nou = $nume_poza . '_' . $i .'.jpg';
break;
}
}
[/php]

la random ala ai 0.0000000x.1 sanse ca totusi sa ai acelasi nume .. asa.. nu vad cum

[Ground.Zero]

o alta varianta ar fi:

[php]

function ren_tstamp($input) {
list($usec, $sec) = explode(" ",microtime());
return str_replace('.', '', (float)$usec + (float)$sec).'_'.$input;
}

$new_file = ren_tstamp($file);[/php]

[coditza]

Cod: Selectaţi tot

<?php
function ren_tstamp($input) {
    list($usec, $sec) = explode(" ",microtime());
    return str_replace('.', '', (float)$usec + (float)$sec).'_'.$input;
}

function ren2($input) {
    return uniqid('').'_'.$input;
}

for($i=0;$i<10;$i++) {
    echo 'File'.$i.' - '.ren_tstamp('File'.$i).'<br />';
}


for($i=0;$i<10;$i++) {
    echo 'File'.$i.' - '.ren2('File'.$i).'<br />';
}
?>


output

File0 - 114413794874_File0
File1 - 114413794874_File1
File2 - 114413794874_File2
File3 - 114413794874_File3
File4 - 114413794874_File4
File5 - 114413794874_File5
File6 - 114413794874_File6
File7 - 114413794874_File7
File8 - 114413794874_File8
File9 - 114413794874_File9

File0 - 443228dcb3937_File0
File1 - 443228dcb3942_File1
File2 - 443228dcb394c_File2
File3 - 443228dcb3955_File3
File4 - 443228dcb395f_File4
File5 - 443228dcb3968_File5
File6 - 443228dcb3971_File6
File7 - 443228dcb397b_File7
File8 - 443228dcb3984_File8
File9 - 443228dcb398d_File9

noah, care ii mai buna?

[Ground.Zero]

noah... daca se uploadeaza in ritmu' ala crapa serveru pan' la urma

anyway... nice

[coditza]

Daca fac 2 omuleti upload exact in acelasi timp la un fisier cu acelasi nume o sa apara conflicte.

[Pirahna]

ok ...

atunci pune

rand(4 cifre).timestamp.numefisier.extensie !!!

[carco]

nee $_SERVER['REMOTE_ADDR'].sessionid().uniqid('').rand(4 cifre).timestamp.numefisier.extensie

[johnny]

[php]
$filename = md5($_SERVER['REMOTE_ADDR'].sessionid().uniqid('').rand(4 cifre).timestamp.numefisier).extensie;
?>
[/php]

cu un seed pentru random (sau poate sha1 in loc de md5 ... ca sa nu arate urat cu ip-ul ala acolo .... )

[Mascka]

de unde s`a plecat si unde a ajuns.. m`am acrit de topicul asta sa`l deschid mereu..

[coditza]

// better, difficult to guess
$better_token = md5(uniqid(rand(), true));

This will create a 32 character identifier (a 128 bit hex number) that is extremely difficult to predict.

Nu ajunge? lipesti ala la numele original al fisierului si cu hasta basta...

[alina_ally23]

Am facut un site de comert electronic, am pozele intr-un director dar nu stiu cum sa fac sa mi le arate si pe site.
Am declarat asa:

Cod: Selectaţi tot

define('WEB_ROOT','http://numesite.lx.ro/');
define('SRV_ROOT','http://numesite.lx.ro/');
define('CATEGORY_IMAGE_DIR', 'http://numesite.lx.ro/images/category/');
define('PRODUCT_IMAGE_DIR',  'http://numesite.lx.ro/images/product/');

si functia pt detaliile produselor:

Cod: Selectaţi tot

function getProductDetail($pdId, $catId)
{
   
   $_SESSION['shoppingReturnUrl'] = $_SERVER['REQUEST_URI'];
   
   
   $sql = "SELECT pd_name, pd_description, pd_price, pd_image, pd_qty
         FROM tbl_product
         WHERE pd_id = $pdId";
   
   $result = dbQuery($sql);
   $row    = dbFetchAssoc($result);
   extract($row);
   
   $row['pd_description'] = nl2br($row['pd_description']);
   
   if ($row['pd_image']) {
      $row['pd_image'] = WEB_ROOT . 'images/product/' . $row['pd_image'];
   } else {
      $row['pd_image'] = WEB_ROOT . 'images/no-image-large.png';
   }
   
   $row['cart_url'] = "cart.php?action=add&p=$pdId";
   
   return $row;         
}

Pozele mele sunt in images/product, dar nu vrea sa mi le ia. Cand n-am introdus nimic in baza de date, in campul image, merge pe ramura asta

Cod: Selectaţi tot

$row['pd_image'] = WEB_ROOT . 'images/no-image-large.png';

Ce trebuie sa introduc in baza de date? Ce path? Am incercat sa introduc "images/product/6-1.jpg", dar nu vrea...nu mai merge pe

Cod: Selectaţi tot

$row['pd_image'] = WEB_ROOT . 'images/no-image-large.png';

, dar nici poza nu vrea sa o afiseze
Eu cred ca e gresit path-ul. Ce trebuie sa introduc pt a afisa poza?
Pls help

[alopia]

Vic : "Dap...clar directoare."
stealth : "directoare ... inclusiv mysql recomanda."
shakabut : "Directoare!"

Eu zic ca toate aceste afirmatii sunt cit se poate de eronate ca sa nu spun ca sunt timpenii. Principalul argument e viteza...

Ei bine va informez ca Google va contrazice flosind propriul sistem de stocare distribuit Bigtable care nu este altceva decit o baza de date foarte sofisticata ... e adevarat nu MySQL . Aveti mai jos spatiul ocupat de catre bazele de date ale diverselor aplicatii google:

- Google Earth (imagini satelit) 70 Terra Bytes (celule in baza de date 9 bilioane)
- Google Crawl 800 Terra Bytes (celule in baza de date 1000 de bilioane)
- Google Analytics 200 Terra Bytes (celule in baza de date 80 de bilioane)

Acum haideti sa vedem ce a patit Youtube. Initial au folosit Lighttpd pentru servit thumbnail-urile filmuletelor (sunt in medie 4 thumbnail-uri per movie la Youtube). S-au trezit ca numarul enorm de fisiere unde erau stocate thumbnail-urile punea intreg sistemul la pamint. Prima oara au incercat sa rezolve problema modificind serverul Lighthttpd care nu mai era nici el deajuns de "light" cind lucra cu milioane de thumbnail-uri. Au esuat in incercarea lor singura solutie temporara dupa cum povesteste un administrator Youtube fiind sa adauge noi si noi servere la clusterele lor atunci cind tot sistemul incremenea incapabil sa serveasca atitea imagini.

Aveti mai jos un citat care incepe amuzant si descrie cu ce s-au confruntat cei de la Youtube pentru ca au ales solutia idioata a stocarii imaginilor in directoare:

Cuong joked about “The Windows approach of scaling: restart everything”

Thumbnails turn out to be surprisingly hard to serve efficiently. Because there, on average, 4 thumbnails per video and many thumbnails per pages, the overall number of thumbnails per second is enormous. They use a separate group of machines to serve thumbnails, with extensive caching and OS tuning specific to this load.

YouTube was bit by a “too many files in one dir” limit: at one point they could accept no more uploads (!!) because of this. The first fix was the usual one: split the files across many directories, and switch to another file system better suited for many small files.

Lighttpd turned out to be poor for serving the thumbnails, because its main loop is a bottleneck to load files from disk; they addressed this by modifying Lighttpd to add worker threads to read from disk. This was good but still not good enough, with one thumbnail per file, because the enormous number of files was terribly slow to work with (imagine tarring up many million files).

Their new solution for thumbnails is to use Google’s BigTable, which provides high performance for a large number of rows, fault tolerance, caching, etc. This is a nice (and rare?) example of actual synergy in an acquisition.

YouTube uses MySQL to store metadata. Early on they hit a Linux kernel issue which prioritized the page cache higher than app data, it swapped out the app data, totally overwhelming the system. They recovered from this by removing the swap partition (while live!). This worked.

Acum sa vedem ce solutii au gasit alte companii la problema stocarii imaginilor sau al altui tip de continut:
- Oracle - Real Application Cluster database
- IBM - DB2 Parallel Edition similara sistemului de stocare distribuit Google BigTable

Am aratat asadar ca la cele mai dure teste stocarea fisierelor in directoare se dovedeste o solutie dezastroasa.
La final o sa argumentati well eu nu o sa am niciodata necesitatile Google sau Youtube! Ei bine chiar si pentru site-uri mai mici in cazul meu stocarea imaginilor intr-o baza de date s-a dovedit o solutie mult mai buna decit in sistemul de fisiere din urmatoarele motive:
- drepturi de access la imagini cotrolate (la imaginile din directoarele publice
toata lumea are access)
- securitate sporita datorita faptului ca nu exista directoare cu drepturi de scriere
- securitate sporita datorita faptului ca indiferent ce ar incerca sa uploadeze un atacator fisierul va fi stocat in baza de date si nu intr-un director public acolo unde atacatorul spera sa uploadeze ceva
- backup foarte usor, multiple posibilitati de a opera cu imaginile in baza de date, mutarea site-ului de pe un server pe altul joaca de copil
- foarte usor de contruit un sistem de clustere failover via MySQL replication ... cind un server pica intra in scena altul
- o data construit sistemul il puteti folosi la toate site-urile dumneavoastra la final mai putina munca si mai putin timp pierdut
- la toate aceste avantaje puteti adauga dupa imaginatia fiecaruia folosirea mod_rewrite astfel incit browser-ul va crede ca primeste imagini din sistemul de fisiere ceea ce va va ajuta sa beneficiati fara probleme de cache-ul oricarui browser sau alte traznai

La final singurul argument pro dupa parerea mea ar fi comoditatea scunsa in spatele argumentelor de alt tip cuma ca viteza e de vina. Sa creezi un astfel de sistem ia ceva timp dar satisfactiile in simplitatea utilizarii lui mai tirziu vor fi pe masura!

Asadar alegerea mea: Imagini in baza de date!

[alopia]

Ah si ma amuza nebunia generarii unui nume aleatoriu... asa ca am sa contribui cu alta remarca aberanta meniuta sa mai toarne niste gaz pe foc Lumea uita de srand(). Solutia folosita pentru seed pe server este foarte probabil sa fie folosirea numarului de milisecunde trecute...

Tada ... cu alte cuvinte este o posibilitate sa va treziti in situatia ca doua scripturi lansate in paralel in aceiasi milisecunda sa genereze aceleasi numere aleatoare. Sa emulam situatia cu urmatorul script:

<?php
srand (114413794874);
echo rand();
echo '<br />';
echo rand();
echo '<br />';
echo rand();
?>

De fiecare data cind rulati scriptul veti vedea aceleasi valori
Asadar daca faceti rand(4 cifre).timestamp rand generind numere in functie de timestamp adaugarea timestamp nu ajuta la absolut nimic Obtineti doar ceva de genul asta:

<?php
srand (114413794874);
echo rand();
echo '_114413794874<br />';
echo rand();
echo '_114413794874<br />';
echo rand();
echo '_114413794874<br />';
?>

Funny nu ?

Aberatia numarul 2: generarea imaginilor continind coduri de securitate.
Daca stim:
- milisecunda cind porneste scriptul
- timpul scurs pina la apelul functiei rand()
Putem estima ce seed s-a folosit asadar putem calcula codul de securitate generat Asta ma face sa ma gindesc ca afisarea "Aceasta pagina a fost generata in x milisecunde" in partea de jos a site-ului meu nu e o idee prea geniala

[AurelianToma]

1. daca folositi directoare nu inteleg de ce mai stocati si numele in dB ? Era suficient sha1($id); Extensia? $arrExtensii= array('gif', 'png....altele); foreach..arrExtensii...{<vezi_daca_exista_poza>}.
2.daca studiati putintel veti vedea ca mysql nu "oboseste" din cauza dimensiunilor pozelor CI mai degraba de la a)conexiuni_simultane b)setarea query-lor c)altele
3.a verificat cineva timpii de raspuns in cazul 1(cu baza) sau 2(cu directoarele)? Sa ridice mana sus!
4.baza nu era pe acelasi...hard?? sau (se pare) ca mysql nu stie sa optimizeze citirea unui fisier binar