Wydajność - Dużo folderów, dużo zdjęć., Wyświetlanie zdjęć z danego katalogu, a nie po adresach z DB. Opcje

[adbacz]

Witam i z góry przepraszam za tytuł tematu, ale nie wiedziałem jak to opisać.

Piszę pewien katalog i akurat jestem na poziomie pisania systemu uploadu i downloadu plików. Wpadłem na pewien pomysł. Mianowicie, zamiast zmuszać użytkownika do wpisywania pełnych adresów do zdjęć danego produktu i zapisywać to w DB, zrobić w folderze głównym folder o nazwie takiej samej jak ID danego produktu, i podczas wyświetlania tego produktu, sprawdzać, czy istnieje taki katalog i w nim zdjęcia, i stamtąd pobierać nazwy i wyświetlać zdjęcia.

Np. mamy kategorię ProductOne i dla tej kategorii tworzymy główny katalog o tej samej nazwie w katalogu upload. Podczas gdy będzie dodawany nowy produkt do tego katalogu i zdjęcia do niego, zostanie utworzony nowy katalog o nazwe ID produktu, np. upload/productone/155, i w tym katalogu zamieszczać wszystkie zdjęcia. A gdy ktoś będzie odwiedzał naszą stronę, będziemy sprawdzać czy katalog o ID produktu istnieje i będziemy pobierać wszystkie obrazki jakie tam są, i wyświetlać je.

Wg mnie, dość dobry patent na to, aby w jakimś stopniu zapobiec zapełnianiu sie przestrzeni dyskowej niepotrzebnymi plikami, które nie będą wykorzystywane. Ale teraz pytanie, czy to nie będzie zbyt obciążające dla serwera? Żeby za każdym razem sprawdzać czy katalog istnieje, przebierać po wszystkich plikach w tym katalogu, pobierać ich nazwy i dopiero wyświetlać?

[adbacz]

Wy mówicie o kategoriach tak? O tym, że żeby pobrać drzewo kategorii potrzeba kilkunastu, kulkudziesięciu zapytań do bazy rekurencyjnie w dodatku, żeby takie drzewo utworzyć, tak? To co powiecie na ten patent, że ja swoje drzewo kategorii (bez względu na ich zagłębienie) pobieram jednym zapytaniem, i to zwykłym SELECTem, a później tak sobie to obrabiam ładnie, że w widoku tylko zwykła pętla po tablicy i bab bardzo ładne drzewko?

Słuchajcie. Tu nie chodzi o to, żeby sie kłócić co jest lepszym sposobem. Ktoś wymyslił bazy danych, ktoś wymyśliła XMLa, a dlaczego? Do konkretnych zapotrzebowań. Tam gdzie jedno sie nie nadaje, tam drugie jest wręcz stworzone.

Dzięki by_ikar, dobry pomysł z tymi DIV-ami, na pewno go wykorzystam. Co do XMLa, raczej sobie odpuszczę. Po co mi zaprzęgać nastepne coś, co da mi więcej pisania, mimo, że można to zrobić prościej i wydajniej? Oczywiście nie mówię tutaj, że XML sie do tego nie nadaje. Znalazło by sie coś, w czym byłby lepszy od DB, ale w moim przypadku sobie to daruję. Na pewno nie będę używał już file_exists() na plikach miniatur w listowaniu produktów - rozwiązanie zaproponowane przez by_ikar jest dobre. Po prostu jeśli obrazek będzie, to zasłoni standardowy, jeśli nie to nic się nie stanie.

Teraz wracając to meritum tematu - Nikt z Was nie zakwestionował mojego pomysłu, co do katalogów, więc uznam to za dobry znak - wprowadzę go w życie. Podczas wyświetlania produktu, sprawdzę czy istnieje katalog. Nie będzie istniał, jeśli nie wgrano żadnych zdjęć - nie będę tworzył pustego katalogu tylko dlatego, że dodano produkt. Jeśli będzie istniał to w tedy dopiero bede sprawdzał istnienie plików, listował je, zapisywał do tablicy i wyświetlał w widoku. Co do listy produktów - myslę że skorzystam z rozwiązania zaproponowanego przez by_ikar - bardzo proste i przede wszystkim prawie w cale nie odbije się na wydajności.


PS. Panowie, czy jest sens wtykania jednemu i drugiemu coś do głowy? Po co, jaki to ma sens? Jeśli cudny twierdzi, ę XML mu odpowiada, to niech sobie z niego korzysta wszędzie tam gdzie chce. Mam nadzieje tylko, że XML nie jest Twoim głównym magazynem danych, bo jeśli tak, to nie chciałbym któregoś dnia pracować z aplikacją po kimś kto nagminnie używa XMLa tam, gdzie nie był potrzebny.

PS2. Proszę, tylko nie szargajcie moimi słowami które są wypisane powyżej, nie chciałem nikogo urazić.