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]

BTW przetrzymywanie informacji o plikach w pliku xml IMO mija się z celem. Już lepiej to trzymać w bazie, niż parsować każdorazowo wiele plików xml (np dla kategorii gdzie jest wiele produktów), lub parsowanie ogromnego pliku xml w którym byłby wszystkie adresy do obrazków. Może się wydawać ciekawe, ale według mnie takie nie jest.

Niestety nie zgadzam się z tobą w żadnym wypadku !
Bazy nie relacyjne zmniejszają obciążenie serwera, a pliki XML można sobie otwierać strumieniowo więc wydajnościowo wypadają pięknie.
Nie masz tam widoków jak w mysql, że możesz sobie posortować po nazwie czy coś, ale za to kolejność dodanych danych do xml jest zachowywana, a w mysql już nie (IMG:style_emoticons/default/wink.gif)
Możesz sobie w bazie dać kolumnę kolejność ale przy zmianie jednego rekordu zmieniasz wszystkie pozostałe (IMG:style_emoticons/default/wink.gif)
Jeśli chodzi o XML, w którym przechowujesz dane dotyczące w tym wypadku obrazków to będzie to znacznie lepsze rozwiązanie niż każdorazowy request do bazy danych.
Korzystanie w każdym wypadku z mysql moim zdaniem jest ZŁEM !
Bez sensu wykorzystywać bazę do tak prostych czynności jak zapis zwykłych informacji nie powiązanych z niczym innym.
Myślisz, że aplikacje wymagające zawrotnych prędkości (powiedzmy aplikacje na androida) to z jakich baz korzystają ?
Nie jestem zwolennikiem trzymania wszystkiego w bazie danych !

Moim zdaniem to pójście na łatwiznę.

[by_ikar]

Niestety nie zgadzam się z tobą w żadnym wypadku !

Oczywiście masz do tego prawo.

Nie masz tam widoków jak w mysql, że możesz sobie posortować po nazwie czy coś, ale za to kolejność dodanych danych do xml jest zachowywana, a w mysql już nie (IMG:style_emoticons/default/wink.gif)

Tym razem to ja się z tobą nie zgodzę. Wystarczy dodatkowa kolumna z auto inkrementacją. Chyba że chodziło ci zupełnie o coś innego.

Bazy nie relacyjne zmniejszają obciążenie serwera, a pliki XML można sobie otwierać strumieniowo więc wydajnościowo wypadają pięknie.

Otworzenie pliku może i tak, w przypadku jego dodatkowego parsowania, a już w przypadku kategorii gdzie możesz mieć różne produkty, a już nie wspomnę o wyszukiwarce, gdzie produkty są już całkowicie różne. To wylistowanie 40 produktów i 40 razy parsować xml'em 40 różnych plików w poszukiwaniu istnienia miniatury produktu jest IMO przerostem treści nad formą. Już nie mówiąc o tym że wydajnościowo to jest bardzo kiepskie rozwiązanie.

Jeśli chodzi o XML, w którym przechowujesz dane dotyczące w tym wypadku obrazków to będzie to znacznie lepsze rozwiązanie niż każdorazowy request do bazy danych.

Ten request i tak wykonać musisz, żeby pobrać opis produktu, jego nazwę, cenę. Dodatkowy join do tabeli z miniaturkami i pobierasz te dane w jednym requęście. Przy niewielkim, lub nawet nie zauważalnie zwiększonym obciążeniu. W przypadku xml musisz to robić 40 razy, dla 40 produktów. 40 razy sprawdzasz czy masz prawa odczytu, 40 razy tworzysz nową instancje obiektu prasującego xml. Niestety, liczby źle wróżą xml'owi.

Bez sensu wykorzystywać bazę do tak prostych czynności jak zapis zwykłych informacji nie powiązanych z niczym innym.

Tak, może być bez sensu, zależy jak na to patrzeć, dlatego podałem drugą opcję, która zarówno nie sprawdza 40 razy czy plik istnieje i wykonuje odpowiednie czynności w przypadku jego nie istnienia.

Myślisz, że aplikacje wymagające zawrotnych prędkości (powiedzmy aplikacje na androida) to z jakich baz korzystają ?
Nie jestem zwolennikiem trzymania wszystkiego w bazie danych !

Moim zdaniem to pójście na łatwiznę.

Porównanie akurat do androida tutaj ma się nijak. Zauważ że z androida w jednym momencie jedna osoba korzysta. Z takiego allegro, gdzie masz listowanych 40 aukcji na stronie, korzysta kilka milionów ludzi dziennie. A dodatkowo w androidzie to sobie trzymasz te dane tak na prawdę gdzie chcesz, to już zależy od ciebie, i nie masz z góry narzuconego schematu. Bo możesz zarówno w xml, jak i w sqlite trzymać.

Może i pójście na łatwiznę, tyle że to nie jest tworzone dla sztuki podziwiania wykorzystanych mechanizmów, ale do eksploatowania i między innymi zarabiania. A nie zarobisz nic lub niewiele, jeżeli większość twoich dochodów pochłonie nieoptymalna aplikacja.

Ale temat nie o tym. XML odpada w przedbiegach w takim przykładzie jaki podałeś. Używać możesz, działać działa, ale czy jest wydajne to jest kwestia o którą się pyta autor tematu. A xml nigdy nie było dość szybkie.