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

[by_ikar]

Uwież mi by_ikar, że to z katalogami kategorii produktów musi być. U mnie każdy rodzaj produktu trzymany jest w oddzielnej tabeli, ze względu na to, że potrzebuje dużo różnych informacji na dany temat, a nie każda kategoria produktu jest w takim samym stopniu opisywana, więc dlatego każdy w osobnej tabeli. Więc tak czy owak, musze mieć katalog kategorii produktów a w nim katalogi o nazwach takich jak ID produktu w danej kategorii.

A ja w sumie rozwiązałbym to inaczej. Coś podobnego robiłem i rozwiązałem to tak, że produkty wszystkie są w tej samej tabeli. Jak się przegląda kategorię, to wiesz do jakiej tabeli z dodatkowymi danymi zrobić join. W przypadku wyszukiwania, możesz podać tylko tytuł opis i jakieś inne podstawowe dane jak zdjęcie, cena, ilość sztuk itp. A w przypadku przeglądania już konkretnego produktu, również wiesz w jakiej kategorii jesteś, więc join do odpowiedniej tabeli w poszukiwaniu dodatkowych danych również nie stanowi problemu. W efekcie czego dodanie nowej kategorii to kwestia jednego inserta do tabeli która przetrzymuje nazwy tych kategorii. W twoim przypadku to trochę bardziej złożona zabawa. No ale można to też tak ugryźć (IMG:style_emoticons/default/wink.gif)

Nie zamierzam zapychać żadnymi logami ani nikogo informować o nieistniejących zdjęciach. Z góry zakładam, że nie wszędzie będzie zdjęcie. A czy coś się stanie jak zdjęcia nie będzie? Wg mnie nie, albo jest (jestem za) albo nie (gorzej, ale ujdzie) - proste. Ale nie widze problemu by dać możliwość sobie na przyszłość, aby dopisać coś, żeby mnie informowało o brakujących plikach. W sumie to już na cos wpadłem, skoro nie każdy produkt na początku może mieć zdjęcia, to można zrobić przypomnienie raz dziennie, że brakują jakieś zdjęcia. oczywiście będzie trzeba zaprząc do tego DB, no ale bez tego to już raczej ani rusz jeśli chcemy to modyfikować.

Jasne, dałem tylko możliwość, bo w moim przypadku bym właśnie tak zrobił, że zrobiłbym dodatkową właśnie opcję informującą tylko 1 raz o braku miniatury, ale wcześniej skrypt sprawdziłby czy w ogóle dla produktu podane są jakieś zdjęcia. Jeżeli nie - to znaczy że nie ma z czego miniatury robić i nie ma sensu powiadamiać. Do skryptu gdzieś na samym początku możesz dorzucić coś takiego:

[PHP] pobierz, plaintext 
header("HTTP/1.0 204 No Content");
[PHP] pobierz, plaintext 

w efekcie czego skrypt będzie wykonywał się dalej, ale przeglądarka nie będzie już oczekiwać na odpowiedź, tylko połączenie od razu zostanie zerwane, a skrypt w przypadku jakichś bardziej skomplikowanych prac, będzie pracować sobie tak długo jak będzie tego potrzebować, a użytkownika nie będziesz nękać niepotrzebnymi oczekiwaniami na doczytanie obrazka, który w tym przypadku nie będzie istnieć. (IMG:style_emoticons/default/wink.gif)

1. trzymanie plików w bazie - oprócz obciążania serwera WWW mamy narzut na operacje związane z bazą danych podczas serwowania pliku

IMO obrazki trzymać w bazie jest mało kiedy sens.