Zastanawiam się nad taką sobie kwestią. Gdy ktoś ma załóżmy 100 użytkowników na stronie z avatarami, to tak naprawdę to gdzie zapiszemy te zdjęcia-avatary nie ma znaczenia. A co gdyby ich było 100 000? Wrzucenie do jednego folderu tych zdjęć ,nie jest wtedy chyba najlepszym pomysłem. Doszedłem do wniosku że trzeba stworzyć system, który będzie tworzył katalogi np. co 2000 zdjęć. No i właśnie co wy o tym sądzicie? Ma sens robienie czegoś takiego? Ile wy byście przeznaczyli miejsc na zdjęcia w katalogu?
0
0
Coś takiego: http://stackoverflow.com/questions/671260/tips-for-managing-a-large-number-of-files
w projekcie gdzie mamy cache na obrazki i multum zdjęć "miejsc" mamy strukturę gdzie pkiki są przechowywane w katalogu: img/ID_WLASCICIELA/ID_MIEJSCA/ID_PLIKU. Co prawda wcześniej było samo ID_PLIKU, bo była gwarancja unikalności ale nieziemsko muliło przy zapisie/odczycie (nie pamiętam konkretów jak bardzo zamulało, wiem że były tragiczne timeouty)
0
Z tego co proponujesz warto zrobić dla każdego użytkownika osobny katalog. A te ID_MIEJSCA to na co to?
0
Zdjęcia można trzymać po ludzku, w bazie. Wbrew pozorom nie jest to złe rozwiązanie. Obecnie nie masz już zazwyczaj limitu na wielkość bazy danych (jak miało to miejsce jeszcze kilka lat temu w 99% hostingów). Zdjęcia i tak zajmują miejsce i tak trzeba je backupować i tak trzeba nimi zarządzać. Jeżeli przeniesiemy tą odpowiedzialność do bazy danych to okaże się iż odpada nam 90% problemów.
W tym właśnie problemy takie jak przedstawiłeś.
Istotną rzeczą jest jednak zapoznanie się z możliwościami wybranego RDBMS pod kątem obsługi blobów.
0
A co myślicie o takim rozwiązaniu? img/avatary/Litera_pierwsza_od_loginu/id_użytkownika/rozmiar-zdjecia+id_użytwkika+losowaliczba.jpg
np.
img/avatary/A/15200/150X150+15200+125F4H7J665.jpg
1
IMO id_użytkownika to przestada w tym schemacie. będziesz mieć wówczas po 1 pliku w podkatalogu. daj raczej /img/avatary/2 pierwsze litery/2 nast litery/rozmiar-zdjecia+id_użytwkika.jpg i masz baaardzo ładny podział.
@Koziołek - dasz więcej info? Bo z cenowego punktu widzenia to dyski pod macierze na serwery baz danych są duuuużo droższe niż dyski na pliki (znacznie większe wymagania wydajnościowe, cena per GB jest też znacznie większa)
0
No ładny podział to daje nam
ok 1000 katalogów przy dwóch pierwszych literach (mogą się zdarzyć też liczby dlatego liczba podbiła do 1000) przy kolejnych znowu 1000 czyli wychodzi 1 000 000 katalogów i podziałów :) co zupełnie wystarczy nawet przy ogromnej liczbie użytkowników.
0
Koziołek napisał(a):
Zdjęcia można trzymać po ludzku, w bazie. Wbrew pozorom nie jest to złe rozwiązanie. Obecnie nie masz już zazwyczaj limitu na wielkość bazy danych (jak miało to miejsce jeszcze kilka lat temu w 99% hostingów). Zdjęcia i tak zajmują miejsce i tak trzeba je backupować i tak trzeba nimi zarządzać. Jeżeli przeniesiemy tą odpowiedzialność do bazy danych to okaże się iż odpada nam 90% problemów.
W tym właśnie problemy takie jak przedstawiłeś.
Istotną rzeczą jest jednak zapoznanie się z możliwościami wybranego RDBMS pod kątem obsługi blobów.
Trzymanie zdjęć w bazie jest (moim zdaniem) niewygodne i trzeba potem używać header() aby wyświetlił zdjęcie jako zdjęcie
0
Znacznie wygodniej jest zatem utrzymywać strukturę katalogów i napisać własny system transakcyjny do pracy z nim... cóż.. co kto lubi :)
Jeżeli jednak jedyną motywacją jest konieczność użycia metody... LOL...