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ć?

[cudny]

Nie pisze tu o otwieraniu 40 plików tylko trzymaniu informacji w jednym pliku - bez opisów tylko dowiązania do plików, co do mojej pracy na bd do bardzo kolego się mylisz. Pracowałem na początku tylko na bd do puki nie zrozumiałem jak działa XML.

Racja, to nie jest operacja na plikach, to jest operacja w bazie danych wink.gif a nie sprawdza coś, tylko konkretną rzecz - plik.

file_exists(); sprawdza czy ścieżka jest poprawna - a niby co ? otwiera plik ? nie ! sprawdza poprawność ścieżki.

A teraz, bardzo cię proszę - wmówisz mi, że wykonanie tysiąca zapytań rekurencyjnie do bd to najlepsza metoda generowania drzewa kategorii ?

XML jest doskonałym narzędziem do szybkiego dostępu do danych.
skomentuje to tylko tak -> smile.gif

To lepiej nie komentuj (IMG:style_emoticons/default/biggrin.gif)

A xml to niby jak powstaje? To wszystko musi być parsowane przecież..

Ale nie tak jak myślisz, że od razu masz 10 megowy plik w pamięci ram (IMG:style_emoticons/default/biggrin.gif)

I nic nie napisałem o wyższości XML nad bazami danych !
XML w przypadku szybkiego dostępu do danych, które wiesz gdzie się znajdują jest doskonały - poruszasz się już po gotowym drzewie.

A co do największych sklepów i jak one trzymają drzewa kategorii (IMG:style_emoticons/default/biggrin.gif)
Zauważ, że w allegro nie masz możliwości wyświetlenia całego drzewa kategorii - czemu - tutaj jednak użyję tej kryształowej kuli bo to tylko moje domniemania - ale super by było kilkadziesiąt tysięcy zapytań wykonać w ciągu ułamka sekundy (IMG:style_emoticons/default/biggrin.gif) :D
Co nie zmienia faktu, że do takiej ilości danych XML faktycznie się nie nada, ale to też tylko dane z kuli kryształowej (IMG:style_emoticons/default/biggrin.gif) bo nie wiem czy ktoś testował coś takiego, bo po co ?

Dalsza część wniosków:

Wykorzystując do trzymania danych bez potrzeby relacji i wykorzystywania widoków nadal uważam, że nie warto obciążać zbędnie bazy danych.
Wydajność aplikacji przeważnie polepsza się redukując ilość zapytań i ilość pobieranych wyników.