Witam

Chciałbym się dowiedzieć co będzie lepszym rozwiązaniem zapisanie zdjęcia do bazy danych (MySQL) czy jako zwykły plik graficzny na serwerze?

Z góry dzięki za odpowiedź

Jako plik graficzny na serwerze. W bazie możesz trzymać powiedzmy jakieś odniesienie do tego pliku typu image_url.

Spodziewałem się więcej opinii na ten temat, jakiejś większej dyskusji, no nic, trudno.

W bazie nie trzyma się zdjęć, bo nie do tego baza jest stworzona żeby trzymać takie duże pliki w niej. Dlatego lepszym rozwiązaniem jest trzymanie tylko linku do danego zdjęcia, a samo zdjęcie jest fizycznie na serwerze.

Co jeszcze więcej byś chciał?

Trzymanie zdjęc w bazie ma więcej zalet:
- mogą nie miec stałej nazwy, stałej ścieżki
- w lepszy sposób mozna kontrolowac i pobieranie zdjec
- lepiej mozna kontrolowac prawa dostepu do wybranych zdjec
...

zaden argument
Tak samo dobrze mozna to kontrolowac i bez bazy
Jak wyzej - bez bazy rownie dobrze sie to kontroluje.

Zdjecia nalezy trzymac na dysku a nie w bazie.

Dlaczego?

I drugie pytanie: po co w takim razie zostały stworzone pola BLOB w bazach danych?

Poniewaz czasami jest potrzeba trzymania tam takich danych. ALe w wiekszosci wypadkow zdjecia czy inne zasoby w serwisie trzyma sie na dysku. Tak jest poprostu lepiej

Podaj kontrargumenty.
Jeden znam: łatwiejszy dostęp do pliku - nie trzeba go materializowac.
Podaj inne na przewagę trzymania w systemie plików, a nie w bazie.

To tak jakbys prosil bym podal ci kontrargumenty na to, ze lepiej w deszczu chodzic pod parasolem niz bez parasola - pewne rzeczy sa dosc oczywiste. Raz zmokniesz do suchej nitki a potem sie przeziebisz to bedziesz wiedzial na nastepny raz, ze parasol jest potrzebny

Wyobraź sobie 'materializowanie' pliku z bazy ważącego kilka gB.
Baza danych jest od przechowywania struktur, nie danych.
A teraz wyobraź sobie backup takiej bazy danych na serwer. Limity, obciążenie, kompatybilność... eeeh.

OK, to jest argument.
Naprawdę? Dlaczego? Przecież dane można przechowywać w CSV.
Wyobraź sobie backup plików graficznych... Limity, obciążenie, kompatybilność..

Wykonaj upload kilku gigabajtowego pliku przez http, omijając limity php.ini - większość dostawców nie zezwala na modyfikowanie ini, a jeśli już to nie pod takie wartości.
Jak Ci brakuje argumentu, to lepiej dla wszystkich, jakbyś nic nie pisał - kompromitujesz się.

Pokazuję tylko inne rozwiązanie. NIGDZIE nie napisałem, że sam bym tak zrobił. Nasza dyskusja (o ile z twojej strony można nazwać to dyskusją, a nie atakiem) ma na celu wybranie przez pytacza rozwiąznia.

Korzystanie z bazy do przetwarzania plików spowolni całą resztę.
Nie od dziś wiadomo, że łatwiej jest przesłać backup dużych plików przez ftp, zamiast http->mysql.

Dlaczego nie trzymać plików w bazie?

Może dlatego, że w takim systemie dane przetwarzane są 3 razy. Najpierw baza musi je wysłać do drivera w języku serverside (PHP), później driver musi umieścić je w lokalnej strukturze danych (2 operacje kopiowania), na koniec dane trzeba przetworzyć i wysłać do przeglądarki. 3 razy to wersja bardzo optymistyczna, pomijająca operacje kopiowania danych występujące między userland a kernelem, które występują co najmniej dodatkowe 2 razy. Więc CPU zamiast robić cokolwiek pożytecznego w kółko przepisuje te same dane.

Jak to serwujesz normalnie to dane odczytujesz bez przetwarzania, bezpośrednio z dysku (cache), nie trzeba ich nawet nigdzie kopiować, "nowe" kernele (takie nowsze niż robiono 10 lat temu) mogą wysyłać dane bezpośrednio do interfaceu sieciowego z pominięciem userland.





Druga sprawa to fakt, że trzeba ręcznie obsługiwać cacheowanie, niewielu ludzi potrafi zrobić to dobrze. A trzeci problem, to fakt że tak napisany skrypt nie obsługuje partial-content, więc jeśli np. na komórce padnie połączenie to trzeba będzie ściągać cały plik od nowa. Więc się skończy albo niedorobionym kodem, albo marnym wymyślaniem koła na nowo i implementowaniem podstawowych operacji HTTP (już widzę jak będzie z kompatybilnością takiej "rzemieślniczej" implementacji robionej przez kogoś, kto ma może na desktopie 3 przeglądarki + 2 komórki).

Na prawdę nie można chyba zrobić wiele głupszego, niż słać pliki z bazy (no chyba, że piszemy jakiś mikro-skrypt który odwiedza 30 ludzi dziennie). To świetny materiał na atak DOS. Jak ktoś się dowie, to może jednym łączem 128 kbit ubić cały serwer a być może i zamulić sieć usługodawcy po prostu inicjując requesty.

Już o backupach nie wspominając (taki plik w bazie, jako dump zajmuje 3-4x więcej miejsca na dysku)


Serwer dedykowany w OVH kosztuje 15 złotych brutto, średni VPS 20. Plik można podzielić i przesłać.

Jak na dzielonym hostingu załadujesz do BLOB's nawet paręset MB crap'u to wylecisz po 10 minutach bo tak obciążysz system że od razu zauważą. Zwłaszcza, że w normalnych rozwiązaniach są dedykowane serwery DB... więc śląc ten crap w kółko po sieci tak im obciążysz linki że cię wywalą nawet zanim zauważą nadmierne obciążenie CPU i dysków.

BTW: Myślałem, że ten "dylemat" rozwiązano 10 lat temu Po to się buduje szybkie serwery plików i rozwija kernele, żeby można było słać setki tysięcy statycznych plików na sekundę z jednej maszyny. Nie sztuka nakupić sprzętu za 100 tysięcy i go zamulić 50 transferami / s

http://lowlatencyweb.wordpress.com/2012/03...rvers-are-fast/
http://www.techrepublic.com/article/use-se...-data-transfer/
http://redmine.lighttpd.net/projects/1/wiki/Docs_Performance
http://www.lighttpd.net/benchmark/

Każdy nowocześniejszy serwer ma nagłówki, żeby serwowania plików nie robić z interpreterów po stronie serwera... a każdy nowocześniejszy OS obsługuje operacje atomowe na plikach, więc jedyna potencjalna zaleta bazy i tak tutaj odpada.
http://redmine.lighttpd.net/projects/1/wik...HTTPD-send-file