Forum PHP Romania - Discutii despre PHP, MySQL, Javascript, AJAX, etc

[micael]

as vrea sa fac o pagina gen album, adica in stinga (de ex) sa afisez imagini si in dreapta, explicatii, dar totul sa fie inregistrat intr-o baza de date mysql. am facut inainte (ca exercitiu) o agenda in mysql si afisata cu ajutorul php, dar nu stiu cum se face cind e vba de imagini... imi poate da cineva o sugestie?

:lol:

[FrostB|te]

pai e simplu : uploadezi poza pe server si in acelasi timp introduci in baza de date numele pozei sau path-ul catre poza , si cu textul tot in baza de date . Any Questions ?

[TheWanderer]

Nu uploadezi calea catre fotografie, e aiurea. Daca vrei sa schimbi structura de director si ai 10 000 de fotografii ce faci ?
Pune tot continutul fotografiei intr-un camp de tip blob in DB.

[FrostB|te]

salvezi numai numele imaginii in baza de date si calea o setezi intr-o variabila .

[TheWanderer]

Si bagi variabila in tot felul de incuri? Si daca vrei sa schimbi stai si modifici fisierele de configurare. Daca vrei sa ai o structura de directori ce faci
$path_to_Xpictures, $path_to_Ypictures sau $path_to_pictures."/x" ?
Nu e mai simplu sa le pui in DB imaginile? In felul asta nu te intereseaza ce se intampla cu structura de director.

[Emil]

stocarea imaginilor in field-uri BLOB este total neergonomica si consumatoare de resurse . Solutia consta in stocarea numelui imaginii in baza de date si o structura de fisiere bine definita/organizata,personal nu am vazut pana acum aplicatie (cu mysql / postgre) care sa faca stocarea in BLOB a fisierelor. Si .. mai gandeste-te la ceva , pe foarte multe servcii de hosting spatiul de stocare este mai mare de cateva ori (poate zeci de ori) decat capacitatea maxima permisa de baza de date deci,stocarea unui numar mare de imagini ar fi imposibil de facut.
That's all .

[Emil]

Si inca ceva - gandeste-te la managementul imaginilor :
stocate fiind direct pe serer nu ai poate e mai facil in anumite situatii sa faci upload prin ftp .
de asemenea sa zicem ca faci upload la 10 fisiere , asta inseamna citire fisier (memorie consumata) introducere in baza de date (cu un query costisitor ca resurse) - ocuparea spatiului util in baza de date - incetinirea query-urilor pe cand cu imaginile pe server,se face un query simplu si nemancator de resurse de restul se ocupa webserverul .

[TheWanderer]

Stocarea numelui in baza de date si fisierul pe disc este buna pentru site-uri unde nu te astepti la un continut media consistent. Solutia de a stoca in baza de date imaginile (eventual sunete) se foloseste la proiecte de genul: Motor de articole, librarie/arhiva media, etc.
Nu este optim sa ai o structura de director imensa cu zeci de subdirectoare si doar o parcurgere de director sa dureze. Mai gandeste-te ca de obicei, la astfel de proiecte, se fac prerelucrari pe imagine (micsorari/mariri), streaming si daca e ceva ce trebuie sa aiba un raspuns rapid (MMS service) mai are si unul sau mai multi daemoni in spate... nu ar fi frumos sa nu faca toti un fread() ?
In privinta rapiditatii executarii query-urilor se fac tabele temporare pentru conditiile where si atat timp cat nu cauti in campul blob nu prea conteaza si nu iti incetineste query-ul absolut deloc. Iar daca trebuie sa fie rapida cautarea faci filtre.

"Query costisitor ca resurse" :? ... what is that?
Dupa ce ai facut upload-ul (pe care oricum trebuie sa il faci) query-ul de insertie se executa ~= instantaneu fiind conexie pe localhost. Cat despre citirea fisierului daca este pe disc se face de fiecare data cand accesezi pagina, daca este in baza de date se face doar odata (la introducere) si apoi se serverste prin pachet.

Pentru site-uri mici si medii e ok sa pui numele in baza de date dar cand ai multe poze e ridicol sa faci atatea apeluri la disc cand o conexie pe socket e mult mai buna. Plus ca nu am un 4x86 ca webserver totusi ...

[Emil]

-Datanamic
Citat:

STORE IMAGES IN THE DATABASE
In this article we'll tell you how to store images in a database and we'll sum up the advantages and disadvantages of the possible solutions.

A database gives you the opportunity to store photos and other small images in a database table. You can create such a database table for example when you want to create an online photo album with descriptions of your photos.

Storing images in a database table is not recommended. There are too many disadvantages to this approach. Storing the image data in the table requires the database server to process and traffic huge amounts of data that could be better spent on processing it is best suited to. A file server can process such image files much better. Storing the image data inside a binary field leaves that data only available to an application that streams raw image data to and from that field. You cannot view the image with an external standard image viewer anymore. The only advantage to this approach is that you can better secure your images because you can use the database security features.

An alternative, and better method is to store the images outside of the database and store only a link to the image file. You only need a text field in your database table to store this information. The only problem to this approach is that you must synchronize the data in the link field with your file system. It is also very easy to use this method of storing images in combination with a programming language since most programming languages support some kind of LoadFromFile() function which can be used to display the image file.



- Sitepoint forums

Citat:
Images can be stored directly in a database as BLOBs (Binary Large OBjects), just like any other binary data. There are advantages and disadvantages to doing this.

One advantage is security. Allowing a web based application to place uploaded files directly on the server is asking for trouble, and I have cracked multiple web based applications through this hole. Putting the data in the database neuters it from causing any problems. Also, if you store the files on disk, you usually have to store records of their existance in the database and it is possible for those records to get out-of-sync with the files on the drive. Finally, it is advantageous from a backup solution perspective to have all your data in a database which you can export for backups. If you store the files directly on the disk then you have two sources of data to backup and they must be backed up when there data is in sync so as not to end up with useless backups.

Overall, it depends on the specific needs of your project. Those are most of the considerations that were examined when I was faced with this kind of decision at work a few months ago.

The best piece of advice I can give you if you decide to keep the images as files on the drive is to store them outside the web server's DocumentRoot and use a wrapper script which returns the image based on an ID number passed to it. Also, be extremely careful about what you allow in the filenames.


PHPBuilders mailing lists :
Citat:
While I agree with some of your principle, there needs to be a bit of clarification.

There are times when storing images and other binaries in a DB are desirable, nevertheless essential.

In a farmed environment, typically, thumbnails and the like (which may or may not be dynamic, or uploaded by end users) are better off in a database. In terms of managing large amounts of small images, this is the way to go. For this, I have never had a problem.

I would not, however, suggest sticking larger images in there (++10mb), but for the smaller ones it is pretty good. This allows you to build the redundancy where it needs to be, instead of replicating large quantities of files between farm servers.


etc .
Tine minte ca nu vorbim de o baza de date Oracle sau alta baza de date superperformanta .
Si, ma repet - majoritatea serviciilor de hosting au capacitatea DB-ului mai mica si de zeci de ori decat spatiul de stocare oferit !
Altele iti limiteaza pana si numarul de query-uri permis intr-un anumit interval de timp .
Sunt chiar curios sa fac niste teste amanuntite cu load-ul la server in aceasta privinta ..
Cheia .. cum spuneam intr-un post anterior consta buna organizare a structurii de directoare. [/code]

[TheWanderer]

Solutia de a stoca imaginile in DB este buna cand ai server-ul propriu, daca planuiesti un serviciu de hosting do 50 de MB e inutil sa iti tii imaginile in baza de date. Sunt de acord de acord si cu faptul ca nu este bine sa tii imagini mari; daca va trebui sa servesti imagini de 10 MB deja nu mai e o simpla varsare de content si e mai bine ca imaginile sa fie transmise de webserver.

Toate serverele limiteaza numarul de query-uri. Am deschis in C++ socket catre MySQL si am vrut sa vad cate query-uri poate sa accepte. Daca trimiti prea multe (am facut un while) inchide socket-ul automat. In privinta query-urilor executate simultan stiu ca MSSQL Server poate executa cel mai mare numar.

[andreich]

Am vazut aceeasi problema in sectiunea Cod PHP. Poate merge solutia data acolo. http://www.phpromania.net/forum/viewtopic.php?t=815.

[micael]

multumesc tuturor celor care mi-au raspuns.... si daca mai sint si alte "variatiuni pe aceeasi tema" multumesc anticipat si celor care veni cu alte variante. sint inca la inceput (un pic peste nivel 0) si orice explicatie imi prinde bine.
lucrez de vreo 4 luni la un site si aproape zi de zi observ ce rudimentar il facusem in prima faza si il modific... nu stiu cind va fi demn de a fi pus pe net, dar perseverez :D :)

[PHPRomania Bot]