In general e vorba de site-uri de content si mai putin de cele de servicii. Adica site-uri de stiri, blog-uri, etc. etc. Insa chiar si un site de servicii ca MyJob de exemplu (recrutare online) poate avea macar imagini incarcate de utilizatori (de exemplu poza candidatului).
Sunt doua mari posibilitati de stocare a pozelor unui site (si a documentelor incarcate in general) :
a. In sistemul de fisiere („pe disc”)
b. In baza de date
Eu totdeauna am ales, si raman la practica asta, sa le pun in baza de date. Macar pentru ce au patit cei de la Metropotam (a scris Orlando despre hackuiala celor de la Metropotam, s-a lamentat o don’soara Cristina Foarfa si Dragos Novac a scris si el). De fapt de la asta mi-a venit ideea acestui post.
Pe scurt cineva le-a spart site-ul, le-a sters tot, au recuperat textele (din backup-ul bazei de date) dar pozele erau tinute mai mult ca sigur in sistemul de fisiere si nu s-a facut backup si la acesta. Guess what… au ramas fara cele circa 13.000 de poze. Nasol. Poate invata ceva (cel mult ei ca cei din jur tot n-or sa invete ca de obicei).
Intr-un articol Scott Mitchell compara cele doua politici de stocare a fisierelor venite din exterior. (In zip exista un fisier PowerPoint cu descrierea detaliata) si concluziona ca in majoritatea situatiilor e cel mai rentabil sa ai fisierele in baza de date si nu in sistemul de fisiere.
______________
Acum lasand asta la o parte ma intreb ce vor invata ceilalti din intamplarea celor de la Metropotam. Sper ca macar cei de la Metropotam vor invata ceva. Ma tem ca cei din jur vor concluziona ca „mie nu o sa mi se intample” si nu vor schimba nimic privind siguranta site-urilor lor. Pana li se va intampla. Am vazut asta intamplandu-se la un cotidian/ziar/etc. si am vazut si la un alt site despre care nu pot vorbi (sper sa ma intelegeti).
Deci s-a intamplat, se intampla si se va mai intampla. Partea trista (din punctul meu de vedere) este ca de obicei nu ia nimeni nici o masura. Si apropos de luat masuri : ce credeti ca li se va intampla celor care sunt responsabili de proasta politica de backup respectiv de prostul sistem de securitate al site-ului Metropotam? Va zic eu : NIMIC.
Ce sa inteleaga un angajat care o face de oaie in stil mare si nu pateste nimic in urma asta? Ca firma il iubeste si il iarta de data asta dar sa nu se mai intample? NUUU!!! Va intelege ca poate sa o faca de oaie oricum ca nu va pati nimic niciodata.
Editare ulterioara nr.1 (o numerotez ca nu stiu daca va fi singura) : vedeti comentariul nr.2 de la Dragos Novac? :
„inainte de a afla cine e foarte important sa aflati cum. in urma cu 2 luni cineva a spart unul din forumurile pe care le administrez prin interfata de administrare. am descoperit cine, insa nu si cum. si de atunci sunt nevoit sa tin inchisa interfata de administrare pentru ca nu stiu ce sa repar.
imi pare rau si va urez recuperare usoara 😦
Ciprian
p.s. pot sa inteleg ca nu aveati backup la fotografii pentru ca 13.000 nu e tocmai usor de backuput. Stiu cum e la mine cu 1000…”
Bietul … ăăă…. cum sa ii zic.. om. Daca nu poti administra un forum (upgrad-a, migra, eventual chiar depana) mai bine te apuci de altceva. Sau mai degraba te-ai perfectiona.
Insa gafa majora a lui „Ciprian” este faza cu dificultatea salvarii celor 13.000 de fotografii. O fotografie in medie ocupa sa zicem 100kB. 13.000 x 100 kB = aproximativ 1,3 GB adica o treime de DVD. Cat de fraier sa fii sa nu poti face backup la 1,3GB. Adica pana la urma un DVD Writer costa la eMag 91,84 RON. O fi asa mult?! Il cumperi o data si il folosesti MACAR un an. Un DVD blank nu stiu cat costa ca nu ma intereseaza. Cand am nevoie de cateva le cumpar si platesc la casa cat imi cere. Oricum trei backup-uri integrale de poze intra pe un singur DVD. Daca faci o data pe zi backup atunci … Un DVD la 3 zile maxim.
Daaaaaaaaaaar iata ca ajung la alta chestie : BACKUP-URI INCREMENTALE!!! Asta mai greu faci la documente daca sunt in sistemul de fisiere, nu?! Daca erau in baza de date era alta viata… Dar nuuuuuuuuuuu romanul e puturos si ii e mai usor sa tina in sistemul de fisiere.
De fapt, ca sa divaghez nitel, asta e buba noastra, a multora dintre romani : suntem destepti dar tare puturosi. Preferam sa luam o cale care e usoara la inceput si apoi grea mai incolo sau chiar infundata. La fel cu sistemul de fisiere versus baza de date la stocarea de documente si la scrierea unei aplicatii folosind o arhitectura dovedita in timp (3-tier, MVC etc.) cu source-control, versioning, framework intern samd. NUu… hai sa o facem *ORICUM* sa vedem ca merge si mai vedem dup’aia. Bonusuri:
– Cod duplicat
– logica de business PESTE TOT (in UI, in BLL, in baza de date, in pzd-ms…)
– hard-coding la greu
-…
.. şi să nu uit să aleg un titlu. Ce trebuia să nu uit?! 
Duminică, 17-februarie-2008 la 7:00 pm
teoriile tale sunt pure speculatii si esti departe de adevar. chiar foarte.
Duminică, 17-februarie-2008 la 7:44 pm
„asta e buba noastra, a multora dintre romani : suntem destepti dar tare puturosi” – hehehe, si tu esti roman, nu? :)) :)) :))
Acum, serios vorbind: din pacate, ai dreptate; lipsa de interes dovedita de mult prea multi romani in felul in care isi fac treaba (aici, in tara, ca afara sunt obligati sa o faca asa cum trebuie!) este unul dintre motivele pentru care lucrurile merg infect in tara asta… Si, tot din pacate, nu exista zi in care sa nu ne lovim de aceasta incompetenta, mentinuta cu buna stiinta… 😦
Duminică, 17-februarie-2008 la 10:56 pm
@dragos : Care anume sunt speculatii? Poti detalia?
Duminică, 17-februarie-2008 la 11:27 pm
Da, teoretic ar fi mai buna stocare pozelor in baza de date.Insa numai teoretic, fiindca platesti foarte mult pe partea de performanta. Mai ales mysql-ul (aflat pe majoritatea site-urilor) incepe sa mearga sacadat atunci cand dimensiunea bazei de date devine foarte mare Iti recomand sa faci un test comparativ: 100 de mii de poze bagate in baza de date sau 100 de mii de cai spre poze stocate local.
In al doilea rand la fel cum la metropotam a fost sters sistemul de fisiere, la fel de usor (sau chiar mai usor cu un sql injection) se poate sterge baza de date.
Iar backup-ul incremental se poate face la fel de usor si pentru sistemul de fisiere ca si pentru baza de date. Faci un cron care sa copieze fisierele cu data mai recenta decat data ultimuli backup.
Duminică, 17-februarie-2008 la 11:33 pm
Andrei, una din regulile numărul unu când eşti un bun profesionist spune că nu dai în colegii de breaslă. No matter what. Metropotam a păţit-o, în mod sigur îi doare, deja se vede că iau măsuri. Să-ţi baţi şi tu organu’ de ei nu cred că-i cea mai productivă măsură.
Cât despre stocarea fişierelor în baza de date, think again. 13.000 de fişiere a 100 KB fac 1.3 GB. Tu ai socotit mai sus. În cazul de faţă ar avea următoarele două dezavantaje majore:
backup-ul bazei de date e din ce în ce mai greu de realizat şi asta din cauza unor informaţii mai puţin relevante precum nişte poze (faţă de articole, comentarii, adrese de email, etc etc)
query-urile devin din ce în ce mai „grele” pentru că trebuie să conţină şi informaţia binară, nu doar calea, de exemplu
Iar cea mai mare greşeală din articolul tău e că zici de backup şi achiziţionare de DVD-uri. Cel mai important tip de backup e cel automat, unde nu e nevoie ca Dragoş, Cristina sau Gina să coboare până la magazin după un blank.
Cât despre backup incremental de pe sistemul de fişiere… rsync îţi spune ceva?
Luni, 18-februarie-2008 la 12:18 am
@Andrei (Maxim) :
Hai sa le luam pe rand :
1. „Andrei, una din regulile numărul unu când eşti un bun profesionist spune că nu dai în colegii de breaslă. No matter what.” – asa fac si medicii cand omoara un pacient din incompetenta. Stiu e un caz mult mai putin grav aici dar eu vad o paralela. Nu mersi, nu am sa imi insusesc asta. De asemenea cand o sa o fac eu de oaie am sa imi rabd criticile cu demnitate.
2. „backup-ul bazei de date e din ce în ce mai greu de realizat” – daca il faci incremental nu cred ca va fi mai greu. De exemplu Luni il faci integral si in rest il faci incremental samd. Cate poze se aduna pe zi anywayz? Un giga?!
3. Ok, nu stiam de rsync dar chiar daca nu exista se putea face un tool care sa se uite la nume, dimensiune si data ultimei modificari (eventual si sa faca un hash daca optezi).
4. Ok, backup automat e in orice firma serioasa, stiu asta. Lucrez cu asa ceva. Insa nu se tin TOATE backup-urile din toate timpurile pe hdd-uri. Unele se arhiveaza pe DVD-uri. Asta nu e scorneala mea.
5. Cat priveste performanta interogarilor in baza de date mi se pare ciudat sa zici asta pentru ca exista indecsi si cauti un fisier imagine pe baza ID-ului (numeric sa zicem) din tabela aia. Interogarile din alte tabele nu vor fi afectate de performanta. Oricate imagini ai avea.
6. Per total un backup trebuie sa iti poata reda COMPLET TOATE INFORMATIILE. Indiferent unde sunt tinute datele. In DBMS, in fisiere sau mixt. Daca treaba a iesit prost (refacerea datelor) nu inseamna ca au gresit ceva?
Luni, 18-februarie-2008 la 12:23 am
@Dan :
1. Nu am lucrat niciodata cu mysql si de aceea nu inteleg de ce incepe sa mearga sacadat cand o tabela e mare si tu nu interoghezi din ea. Ma rog… nu stiu.
2. Cand un proiect software e gandit sa ajunga la o anumita dimensiune iti iei in calcul si platforme/tehnologii cat de cat performante nu mysql. Ok, nu va place Oracle, pe Microsoft (SQL Server) probabil aveti boala dar un PostgresSQL mergea…
3. SQL Injection este pwn 4 noobs ca sa zic asa. Orice vine de la user trebuie tratat cu o doza de paranoia. De exemplu orice string care va merge intr-un query construit dinamic (bad ideea de obicei – prefer proceduri stocate) trebuie fie bind-at ca parametru fie macar filtrat bine.
4. „Faci un cron care sa copieze fisierele cu data mai recenta decat data ultimuli backup.” – SUPER CORECT. Ce n-a mers in cazul lor totusi? De ce nu mai sunt imaginile?
Luni, 18-februarie-2008 la 7:16 am
Am citit si eu postul asta al tau. Acuma ma simt mai informat.
Viziteaza si orasul meu. Merci.
http://gramo.myminicity.com/
Luni, 18-februarie-2008 la 1:19 pm
1. E o diferenţă mare în a ataca Metropotam şi a spune pe un ton parintesc „uite, vedeţi ce se întâmplă când backup-ul nu e o prioritate?”. N-a murit nici un om, nu e ceva atât de dramatic. E o lecţie învăţată de web-ul românesc şi, sincer să fiu, trebuia să se întâmple aşa ceva la un moment dat. Îmi pare rău că a fost la metropotam, pentru că sunt oameni tare faini acolo.
2. (şi primele două din răspunsul pentru Dan) Hai să fim serioşi. Ce firmă româneasca va arunca 1000+ dolari pentru un server de baze de date doar ca să arunce totul acolo? Îţi spun eu, nu multe. Şi nu e vorba doar de bani aici: MySQL se comportă extrem de acceptabil când vine vorba de o aplicaţie web medie ca dimensiuni. Pentru SQL Server trebuie sa ai o maşină dedicată care să fie pe Windows, pentru Oracle la fel. Şi Postgre e mai lent decât MySQL. Deci…
Ideea e că atunci când ai mii de poze, e stupid să-ţi încarci o tabelă cu ele doar pentru că îţi simplifică backup-ul. E aproape la fel de simplu când ai chestiunile pe sistemul de fişiere, trebuie doar să mai scrii un scriptuleţ în plus care nu ia mai mult de câteva linii (cu rsync e vorba de o linie de cod şi rsync is teh shizzle). În plus, nimic, dar absolut nimic, nu e mai rapid decât un fişier servit direct de pe disc.
Problema la Metropotam probabil a fost o politică de backup uşor deficitară. N-ai observat că articolele şi informaţiile de pe site s-au recuperat imediat, singura problemă fiind la poze?
Luni, 18-februarie-2008 la 1:25 pm
@1: Nu am atacat metropotam, mai degraba mesajul meu este moralizator.
@2: Stiu firme romanesti care ruleaza Oracle si altele care ruleaza SQL Server fara licenta. Zero lei.
Stocatul unor fisiere in baza de date are si alte avantaje decat simplificarea backup-ului (simplificarea integritatii referentiale, integrarea politicii de acces la resurse samd.)
Bineinteles ca in cazul acesta e posibil ca sa fi fost doar o politica deficitara de backup.
Marți, 19-februarie-2008 la 10:02 am
Da, te-ai lansat in pure speculatii moralizatoare cu iz pedant.
In primul rand pentru a sti ce trebuie sa depanezi trebuie sa afli ce exploit in ce modul a fost folosit pentru a intra intr-un forum. Si daca asta nu ti-e jobul tau, chiar nu te intereseaza. Deci mai usor cu lasa-te si apuca-te de altceva.
Daca sincronizezi logica dintre fotografii si baza de data ai insa dreptate cu facut backup pe DVD la baza de date.
Btw revin cu aceeasi intrebare: Ai incercat sa lucrezi pe un MySQL cu documente/fisiere stocate in DB si sa ii faci si backup? Succes!
Mi s-a intamplat chiar ca un cron de copiat/facut backup la un moment dat sa nu mai functioneze. Cand e vorba de un hobby chiar nu m-a interesat. Poate ca alta ar fi situatia daca ar fi vorba de un job.
Si apropo, stii ca si tu suferi de o meteahna pur romaneasca? Ii spune tendentiozitate cu iz speculativ.
Marți, 19-februarie-2008 la 2:20 pm
Andrei daca chiar citeai ce a zis Dragos pe acolo observai ca au mare parte din poze si pe alte sisteme nu numai pe server.
Cat despre salvat pozele in baza de date (indiferent de ce sgbd folosesti) este o tampenie cat casa.
Am facut parte din echipe care au facut de la site-uri de 100 de unici pe luna la site-uri care sunt in top10 ca afisari in .ro si nicaieri nimeni nu salveaza in baza de date imagini…
Motivele sunt simple:
1) Servirea imaginilor direct de pe disk este mai rapida.
2) Servirea imaginilor de pe disk reduce numarul de interogari la sgbd. Si automat scade loadul pe server
3) Toate sistemele de baze de dare au scaderi seminificative de performanta cand ai tabele foarte mari. De la Oracle la Mysql trecand prin Rostgress (si pun pariu ca si MSSql-ul dar acolo nu am date) De ce crezi ca s-au chinuit baietii sa implementeze partitionarea secventiala a tabelor in aproape toate sgbd-urile?
Si daca tot recomanzi back-uri incrementale poate te interesezi si vezi ca sunt solutii de backup incremental pentru documente deci mai pica un argument pentru imagini in DB.
Marți, 19-februarie-2008 la 7:11 pm
@Alex :
1. „nimeni nu salveaza in baza de date imagini…” nu este un argument valid pentru „salvat pozele in baza de date (indiferent de ce sgbd folosesti) este o tampenie cat casa.”
2. „Toate sistemele de baze de dare au scaderi seminificative de performanta cand ai tabele foarte mari. ” – fals. De ce ar scadea performanta cand tabela cu imagini e mai mare atata vreme cat nu interoghezi din ea?! Ma refer la celelalte interogari decat cele pentru imagini.
3. Se poate simplifica semnificativ logica de acces la imagini. Daca ai imaginea pe disc si vrei sa o poata vedea doar utilizatorii logati vei avea mai mult cod de scris (si posibil configurari de server) decat daca ar fi in baza de date.
4. Nu este scalabil sau creste mult afinitatea de server. Sa zicem ca ai o aplicatie web pe mai mult de o masina fizica si o cale catre imagine http://img1.domeniulmeu.com/1238985.jpg super vizionata. Nu o va putea servi decat masina img1 in cazul asta.
5. Cel putin Oracle si SQL Server (am lucrat mai mult cu ultimul dar acum lucrez si cu celalalt) nu au nici un fel de scadere de performanta baza DOAR pe baza faptului ca baza de date in loc de 1GB au 50GB.
Miercuri, 20-februarie-2008 la 11:18 am
„in majoritatea situatiilor e cel mai rentabil sa ai fisierele in baza de date si nu in sistemul de fisiere.”
pleaca ma de-aici :))
Numai lamerii tin pozele in baza de date. Gandeste-te cum ar fi sa ai 5 GB de poze intr-o baza de date, cum se mai misca severul de mysql? ce putere de procesare ii trebuie? dar daca-s 10? mai misca? Si marimea bazei de date conteaza. testeaza.
Solutia e back-up pe alt server. mult mai elegant si mai rapid si mai cum vrei tu.
Miercuri, 20-februarie-2008 la 11:21 am
Sa inteleg ca mysql este un rebut de server de baze de date?
De testat am testat pe Oracle si SQL Server si nu se intampla deloc ce spui tu si altii ca s-ar intampla pe lamer-ismul ala de mysql.
Joi, 21-februarie-2008 la 3:23 pm
Andrei, sincer să fiu, mă îndoiesc că ai testat SQL Server şi Oracle cu baze de date de 50 de GB care să conţină un procent foarte mare de date într-o singură tabelă, dar…
Nu doar Scott Mitchell vorbeşte de fişiere binare în baza de date de parcă ar fi descoperit apa caldă, ci şi Marcel Kratochvil, un CTO la o companie din Austrialia. Sună tare bine, dar sunt nişte probleme majore.
Din câte ştiu eu, a servi imagini din baza de date implică urmatorul workflow:
1. clientul face request
2. serverul web primeşte request-ul
3. aplicaţia primeşte request-ul
4. baza de date este interogată
5. se creează un fişier temporar pe disc
6. fişierul temporar este servit clientului.
Dacă fişierul este servit direct de pe disc, atunci avem:
1. clientul face request
2. serverul web primeşte request-ul
3. fişierul e servit clientului
Măcar intuitiv ar trebui ca a doua variantă să fie mai rapidă. Nu am să fac benchmark-uri pentru că nu ştiu cât de relevante ar fi ele şi, sincer să fiu, n-am decât vreo 6 GB liberi pe disc momentan 🙂
Să spunem că doreşti să limitezi cumva drepturile de vizualizare a imaginilor (ceea ce nu e cazul Metropotam, de exemplu). Exact aceeaşi situaţie am avut-o eu la aplicaţia unde lucrez: pentru anumiţi clienţi se serveşte un fişier PDF cu nişte date confidenţiale şi nu se doreşte accesul direct. Aşa că stochez fişierele într-un folder care se află în afara folderului public şi am aproximativ 5 linii de cod care facilitează transferul fişierului respectiv. Oricum, nu se mai efectuează un apel la baza de date (poate doar pentru a vedea restricţiile de accesare a fişierului) şi nici nu se creează un fişier temporar pe disc pentru fiecare accesare.
O altă problemă cu stocarea în baza de date e că aşa ajungi să ai o bază de date imensă. Pentru 13.000 de imagini a 100 KB per imagine ajungi să ai o bază de date de 1.3 GB. Un backup remote la imensitatea asta îţi ia vreo 20 de minute pentru un upload de 1 MBps (cu B mare, de la Byte plauzibil dacă faci backup-ul pe un server apropiat celui de producţie). Restore-ul, în caz de urgenţă, ia alte 20 de minute doar pentru transferul fişierului ceea ce înseamnă 20 de minute de downtime asigurat.
De ce să amesteci datele importante, cum ar fi articolele, conturile, etc., cu galeria foto? Doar pentru a fi mai convenabil la backup şi pentru o eventuală politică de ACL pe care s-ar putea să n-o foloseşti niciodată?
Cât despre img1.domeniu/imagine.jpg… BIND, de exemplu, are un algoritm de round robin simpluţ în cazul în care introduci mai multe intrări A în DNS. Faptul că ai un subdomeniu nu înseamnă că ai o singură maşină dedicată care deserveşte acel subdomeniu.
MySQL e un server de baze de date extrem de decent. Atăt Flickr cât şi Fotolog folosesc MySQL ca storage engine şi, apropo, stochează acolo doar datele despre poze, nu şi fişierul binar.
Vineri, 22-februarie-2008 la 12:24 am
Am studiat impreuna cu un coleg DBA cam ce fac altii si ce recomanda altii si lucrurile par impartite. Cei de la Oracle.com par sa zica „nu mai sunt diferentele asa mari ca acum 10 ani intre FS si DBMS” iar Flickr intr-adevar tine imaginile pe disc.
Evident ca drumul mai scurt e mai rapid (ref. la workflow-urile pe care le prezinti mai sus). Ideea era cu cat e mai rapid in practica? 5%? 50%? 500%?
Ideea pentru care eram de acord sa se tina imaginile in baza de date este ca ele oricum sunt legate de alte entitati de acolo (de exemplu de articole, de utilizatori etc.)
„Faptul că ai un subdomeniu nu înseamnă că ai o singură maşină dedicată care deserveşte acel subdomeniu.” Evident, nici nu s-a pus problema asta. Insa orice masina care ar putea sa serveasca imaginea trebuie sa o aiba pe disc. Destul de redundant, nu?
Benchmark mi-ar placea eu sa fac, spatiu am, timp imi fac, ca merita. Chiar nu stiu ce o sa iasa, nu dau NICI UN FEL DE PRONOSTIC.
Trebuie doar sa ma pun de acord cu voi care sa fie parametrii benchmark-ului. Propuneri de parametrii?
Vineri, 22-februarie-2008 la 8:45 am
Hai sa o luam punct cu punct:
1) „De ce ar scadea performanta cand tabela cu imagini e mai mare atata vreme cat nu interoghezi din ea?! Ma refer la celelalte interogari decat cele pentru imagini.”
Nu ar scadea pentru celelalte tabele semnificativ, daca le pui in DB doar ca sa le stochezi acolo. Daca le mai si servesti v-a scadea pentru ca serverul de sql v-a fii ocupa o perioada mai mare din timp cu facut query-uri dupa imagini si servit record-seturi mari
2) „Nu este scalabil sau creste mult afinitatea de server. Sa zicem ca ai o aplicatie web pe mai mult de o masina fizica si o cale catre imagine http://img1.domeniulmeu.com/1238985.jpg super vizionata. Nu o va putea servi decat masina img1 in cazul asta.”
Wrong. Existe sisteme distribuite unde poti face load balancing cu fail-over pe alt server. Este drept ca va presupune dublarea continutului dar alegerea solutiei depinde de designul aplicatiei si ce asteptari ai de la ea
3) „Cel putin Oracle si SQL Server (am lucrat mai mult cu ultimul dar acum lucrez si cu celalalt) nu au nici un fel de scadere de performanta baza DOAR pe baza faptului ca baza de date in loc de 1GB au 50GB.”
Pe asta nu o cred nici daca vad benchmark facut de fata cu mine. Creste baza de date -> cresc indexi -> creste aria de cautare pe disk -> scade performanta. Plus ca intr-o baza de date de 50GB se presupune ca accesezi informatia respectiva nu doar o pui acolo si uiti de ea 😉
4) „Cei de la Oracle.com par sa zica “nu mai sunt diferentele asa mari ca acum 10 ani intre FS si DBMS” ”
Partial adevarat. Cred ca se refera la serverele instalate direct pe device nu pe un FS. Oracle are optiunea sa stochezi contentul direct pe un device neformatat cea ce permite elimintarea FS-ului din workflow-ul accesari datelor. Pentru serverele instalate pe FS este un layer in plus necesar accesari informatiei.
5) „Ideea era cu cat e mai rapid in practica”
Gandeste-te ca intr-o interogare la baza de date de cele mai mult ori cea mai costisitoarea operatiune este conectarea. Plus ca din salvarea pe FS elimini cel putin 2-3 layere pana la accesul la informatie. Scriptul – Connectarea la DB – Crearea temp-ului pentru servire – Garbage clean-up facut de OS-ului…
Vineri, 22-februarie-2008 la 4:48 pm
Conectarea in majoritatea tehnologiilor (Java, .NET etc.) se face cu o tehnica numita Connection Pooling prin care se reutilizeaza conexiuni si nu se inchid literalmente cand se da close. Ci se pune „on hold” pentru o alta potentiala cerere ce ar putea aparea.
@2: Acelasi lucru poti sa il faci tinand in baza de date imaginile si facand caching local pe discurile masinilor de servire.
Sâmbătă, 23-februarie-2008 la 12:19 am
Andrei, e mai puţin costisitoare, dar tot o operaţiune scumpă rămâne.
Miercuri, 12-martie-2008 la 11:15 pm
Din cite am citit si eu, nimeni nu recomanda stocarea datelor tip imagine sau date binare in baza de date in bloburi sau images. Pe de alta parte inteleg dilema. Se pare ca si baietii de la Microsoft au inteles-o cind au adaugat atributul de filestream in Sql Server 2008
http://www.microsoft.com/sqlserver/2008/en/us/wp-sql-2008-manage-unstructured.aspx
In acest fel datele sint stocate pe disk in fisiere normale, dar backupurile de baze de date si respectiv restorurile se aplica si pe fisiere, si sint posibile si niste operatiuni de SQL care folosesc valoarea coloanei pentru a returna dimensiuni sau alte date despre fisier.
Vineri, 14-martie-2008 la 1:50 am
Daca fac asta in SQL Server 2008 atunci O TONA DE RESPECT de la mine. E beton ideea.
Marți, 15-iulie-2008 la 11:49 pm
„test de verificare”
Marți, 9-septembrie-2008 la 6:09 pm
cum fac sa pun documentele di n local disk C in local disk D
Marți, 9-septembrie-2008 la 6:10 pm
cum fac sa pun documentele di n local disk C in local disk D
Duminică, 26-aprilie-2009 la 3:46 pm
nu stiu cum sa bag poze pe net ?