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

Raczej nie. Problem zacznie się kiedy będzie ileś tak tyś odsłon. Bo jak to ma być 1000 odsłon dziennie to zero stresu.

Nie wiem szczerze mówiąc co tutaj ma ci obciążać, bo przecież i tak musisz sprawdzić przed wyświetleniem danych plików czy istnieją (chyba że ktoś tego nie robi i zakłada że jeżeli są wpisy w bazie to i są pliki). Sprawdzenie jeden raz czy katalog istnieje i wylistowanie zawartości poprzez chociażby directoryiterator powinno być całkiem dobrym rozwiązaniem.

Jesli w bazie mamy tylko ścieżki do plików to sprawdzamy tylko czy plik istnieje, jeśli tak to go wyświetlamy, jeśli nie to nie. Tutaj jest troszkę inaczej, bo musimy sprawdzić czy istnieje katalog dla produktu. Później sprawdzić czy są jakieś pliki, pobierać wszystkie (np przez while i dir()), sprawdzać czy to obrazek i dopiero później wyświetlać. Troszeczkę więcej roboty niż zwykłe sprawdzanie czy plik istnieje, jeśli mamy do niego ścieżkę w bazie.

Dlatego też wolałem najpierw się upewnić, niż stosować coś co może obciążać serwer, a wiadomo, operacje na plikach są baaardzo wolne.

PS. Może źle zrozumiałeś by_ikar, ale nie chodzi mi tutaj o jednorazowe sprawdzenie czy katalog istnieje, ale sprawdzanie i listowanie plików (w tym przypadku obrazów) z katalogu za każdym razem, gdy użytkownik wejdzie na stronę z obrazkami danego produktu. Bo tylko w tedy będziemy je wyświetlać.

Tak, tak, dokładnie o to chodzi. Sprawdzasz ten katalog i jego zawartość tylko jeden raz przy jednym requeście, czyli pojedynczym wyświetleniu. directoryiterator jest jak znalazł dla twojego zastosowania, podajesz mu ścieżkę, a on jeżeli są pliki w danym katalogu, w sumie nawet określone pliki, to ci te pliki wylistuje.

Gorzej to się ma w przypadku kategorii i wyświetlenia wielu produktów, tutaj to już najlepiej mieć ścieżkę do miniatury danego produktu w bazie i podczas wyświetlania listy produktów nie sprawdzać każdorazowo istnienia miniaturki produktu, tylko powiedzmy sprawdzać to raz, czy ustawić sprawdzanie w cron'ie.

No w sumie masz rację z tymi kategoriami. Niestety będzie ciężko z cron-em, ale tak sobie myślę, żeby obrazki przechowywać w folderze ponumerowane od jednego w górę, a w DB tylko dać możliwość ustawienia, który z obrazków ma być jako miniaturka. Albo nawet nie dawać, ale od razu, jak tylko wykryje zdjęcie o nazwe, np. 1.jpeg, to szukac jego miniaturki, jeśli nie znajdzie to utworzy i wyświetli, jeśli znajdzie to wyświetli. Miniaturki można nazywać 1_thumb.jpeg i w tedy nie będzie problemu. Mam rację?

ja ostatnio wpadłem na genialny pomysł.
Wiele rzeczy, które nie potrzebują relacji wkładam do xml (czyli bazy nie relacyjnej )
Robisz sobie plik xml, zabezpieczasz go .htaccess'em (deny from all) i wkładasz do niego wszystkie dane.
Fotki dajesz do jakiegoś katalogu zbiorczo numerując je powiedzmy po timestamp.
XML może wyglądać następująco:

[XML] pobierz, plaintext 
<root>
<images type="white">
<img value="45678945678" ext="jpg" name="image_1"/>
<img value="45678946539" ext="png" name="image_2" />
</images>
<images type="red">
<img value="45678945671" ext="jpg" name="image_3" />
<img value="45678946532" ext="gif" name="image_4" />
</images>
</root>
[XML] pobierz, plaintext 

robisz sobie dwa katalogi:

images/min
images/large

do min zapisujesz miniatruki do large oryginały.
oczywiście value to unikalna nazwa obrazka i musi być identyczna dla katalogu min i large.
kasując obrazek kasujesz z min, large i xml
w razie gdy chcesz poszukac obrazka po id to wykorzystujesz xpatch, a do parsowania używasz simpleXML lub DOM

Dla kategorii możesz nawet inaczej zrobić. Obrazek zamiast w img, wyświetlić jako tło, dodatkowo ten obrazek trzymać w jakimś div'ie który będzie miał również tło - obrazka oznaczającego brak miniaturki. Wówczas kiedy zdarzy się przypadek że obrazek dla danego produktu nie istnieje, to żeby nie sprawdzać 40-60 razy na jeden request czy jakieś pliki istnieją, zwyczajnie wyświetli się obrazek oznaczający brak miniaturki. A do katalogu w którym masz obrazki, mógłbyś wrzucić jakiś skrypt, do którego przekierowywałbyś cały ruch, dla nie istniejących plików/katalogów. Wówczas skrypt będzie wywoływany tylko wtedy kiedy jakiś plik nie będzie istniał, tym samym mógłbyś tam wrzucić jakieś logowanie, które powiadamiało by cię o braku obrazka, czy nawet pełen automat, który by sprawdził czy faktycznie obrazka nie ma i powiedzmy usunął z konkretnego wpisu w bazie miniaturę produktu. Trochę mogłem poplątać, ale wydaje mi się takie rozwiązanie całkiem ciekawe, w efekcie czego nie będziemy się martwić o brak miniatur produktów, lub braku dostępu do miniatury produktu (skasowana, zmienione uprawnienia etc).

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.

PS. jeżeli za bardzo zamieszałem z tymi kategoriami, to mogę wytłumaczyć na przykładach swoją drogą chyba nawet sam skorzystam z tego pomysłu bo jest na prawdę ciekawy

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
Możesz sobie w bazie dać kolumnę kolejność ale przy zmianie jednego rekordu zmieniasz wszystkie pozostałe
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ę.

Oczywiście masz do tego prawo.



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.



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.



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.



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.



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.

Ogólnie rzecz biorąc to nie widzę sensu zaprzegać dodatkowo do tego jeszcze XML. Oczywiście możnaby, ale po co? Przy dobrym rozlokowaniu katalogów, dobrze przemyślanych nazwach katalogów i plików, czy to oryginały czy miniaturki, nie będzie trzeba dodatkowo zaprzęgać nawet bazy danych.

Załóżmy, że mamy rozkład katalogów (tutaj nazwy katalogów produktów są alfanumeryczne, w rzeczywistości będą numeryczne):

Gdzie:
uploads = Wiadomo...
images = Wiadomo...
productcat1 = ID kategorii produktów
155, 5553, 233 = ID produktu

I w tedy wszystkie obrazki będziemy trzymać w jednym katalogu (a nie w dwóch, osobno dla miniaturek i oryg. jak pisałeś), i bedziemy ustawiać dla nich nazwy od jednego w górę, gdzie jeden, to będzie zawsze obrazek na miniaturkę i bedziemy sprawdzać tylko czy istnieje plik w katalogu i nazwie takiej:

Oczywiście, może się zdarzyć też tak, że nawet katalogu produktu lub katalogu kategorii produktów nie będzie. Ale to nam nie będzie w niczym przeszkadzało podczas listowania produktów z danej kategorii. My, ścieżkę do tego katalogu będziemy sprawdzać tylko i wyłącznie jedną, bo będziemy ją sklejać na poczekaniu. Ja już mam ID kategorii produktów porobione, dlatego u mnie powstałaby ścieżka jedna, dla jednego produktu, i w tedy tylko funkcją file_exists() bym sprawdzał czy obrazek istnieje.

Wg mnie, dużo więcej obciążałoby serwer odpytywanie katalogu i sprawdzanie czy sa pliki, i jeśli są to je wylistować i wyświetlić w produkcie, niż listy kategorii.

A jeśli nie będzie danego katalogu, to co za problem dopisać prostą funkcję, która nam ten katalog docelowy stworzy podczas dodawania zdjęcia? Nie widze w tym nic trudnego, katalog produktów to nie będzie tylko i wyłącznie tworzenie nowych katalogów na serwerze i upload zdjęć, więc można sobie pozwolić na takie coś.

W przypadku kategorii, użyjesz wówczas 40 razy file_exists, jeżeli tyle produktów wyświetlasz w danej kategorii. Moje drugie rozwiązanie właściwie nie wykorzystuje żadnego skryptu. Bo przykładowo, listujesz sobie produkty i każdy produkt ma taki kod miniaturki:

[HTML] pobierz, plaintext 
<style>
 
.produkt_thumbs { width: 50px; height: 50px; background-image: url(path/to/default_thumb.jpg); display: block; }
 
</style>
 
<div class="produkt_thumbs">
    <a href="/path/to/produkt" class="produkt_thumbs" style="background-image: url(uploads/images/product1/233/1_thumb.png);"></a>
</div>
[HTML] pobierz, plaintext 

W przypadku kiedy miniaturka będzie istnieć: uploads/images/product1/233/1_thumb.png wówczas zakryje default_thumb.jpg który znajduje się w div'ie pod spodem. Kiedy nie ma miniaturki, zwyczajnie wyświetli się tylko tło div'a.

Możesz nawet dodatkowo umieścić w katalogu uploads/images skrypt, przekierować na niego cały ruch, pomijając tylko istniejące pliki/katalogi. W efekcie czego będziesz mógł sobie wykonać jakąś dodatkową akcję, możesz sobie to gdzieś logować, że brakuje miniatury, lub nawet nic nie robić, i nie męcząc apache zapychaniem logów poprzez błędne wywołania. Przykład:

htaccess umieszczony w katalogu uploads/images:



I przykładowy skrypt, który w sumie nic nie zrobi, umieszczony w katalogu uploads/images:

[PHP] pobierz, plaintext 
<?php
 
exit;
 
// lub logowanie gdzieś informacji, parsowanie url'a i zapisywanie w których produktach brakuje miniatur, 
// lub cokolwiek ci przyjdzie do głowy
[PHP] pobierz, plaintext 

Dzięki takiemu zabiegowi, masz z głowy sprawdzanie czy plik istnieje, nie musisz parsować plików xml, nie musisz pobierać tych danych z bazy, te dane nie muszą istnieć nawet w ogóle i możesz w odpowiedni sposób reagować na ich brak.

W przypadku wyświetlenia zdjęć dla konkretnego produktu:

[PHP] pobierz, plaintext 
<?php
 
$files = array();
$productImages = 'upload/images/'.$productCat.'/'.$productId.'';
 
if(is_readable($productImages))
{
    $dir = new DirectoryIterator($productImages);
 
    foreach($dir as $fileinfo)
    {
        if(!$fileinfo->isDot())
        {
            $files[] = $fileinfo->getFilename();
        }
    }
}
 
if(!empty($files))
{
    //kod html galeri
}
[PHP] pobierz, plaintext 

Lub możesz zamiast wcześniej sprawdzać poprzez is_readable, objąć directoryiterator w blok try i robić z tym co ci się podoba. Bez zbytecznych wodotrysków

W ani jednym przypadku nie masz racji.
O jakim ty parsowaniu piszesz ?
Pobierasz sobie XML do dooma i jedziesz wykorzystując plik strumieniowo.
W rzeczywistości nie pobierasz całkowicie całego pliku.
Jeśli chodzi o autoinkrementacje to do czego to miało by służyć w przypadku kolejności ?
Tabela:
id|nazwa|kod|kolejnosc

i co ? jeśli chcesz mieć produkty wyświetlane w/g własnych potrzeb kolejności to co .... za każdą zmiana kolejności zmieniasz każdy rekord w tabeli.
Autoincrement to zupełnie inna bajka.

Co do trzymania danych w bazie, a w xml to powiedz no mi jak ładnie rozwiążesz drzewko kategorii w bazie danych
Widzę, że jeszcze nie przyszło ci pracować z XML lub nie robiłeś żadnego sklepu jeszcze.
id|parent_id|nazwa
i co ? żeby pobrać drzewo kategorii musisz rekurencyjnie dawać zapytanie do bazy - w rezultacie nawet kilka tysięcy zapytań w ułamku sekundy.
Co do parsowania XML to nie parsujesz go tylko raz wyszukasz element, do którego będziesz się odwoływał i lecisz potem rekurencją po danych pięknie wyłożonych na talerz.
Zrób sobie aplikacje ze złożonym drzewem kategorii i dawaj pięknie sobie zapytania do bazy - powodzenia.
XML jest doskonałym narzędziem do szybkiego dostępu do danych.
A baza danych... pięknie ułatwia życie i nigdy XML jej nie zastąpi, ale jeśli chodzi o trzymanie prostych danych to dokładnie do tego xml jest stworzony !

Co do parsowania xml chyba nie do końca rozumiesz jak go używać.
xpatch lub zwykłe wyrażenia regularne.
Myślisz, że baza danych to co to jest ?
To są pliki parsowane po wyrażeniach regularnych, w przypadku mysql napisana w c++

Zachęcam do zapoznania się z dokumentacją narzędzi służących do parsowania xml

Co do wyszukiwania produktów z xml nikt nie każe ci opisów produktów trzymać w xml

Podsumowanie.
Wybór bazy danych zależny jest tylko i wyłącznie od tego jakie dane będą trzymane i wykorzystywane.
Nie wiem po co trzymać dane do obrazków w db skoro spokojnie możesz do tego użyć najprostszego narzędzia czyli xml
A jeszcze jedno co do operacji na plikach
file_exists() to nie jest operacja na plikach to tylko sprawdza czy coś o podanej ścieżce istnieje.
Mówiąc, że to zwolni aplikację to tak jakby dzielenie plików php na klasy miało też ją spowolnić - przecież też trzeba sprawdzić czy plik istnieje


OoO jeszcze to zauważyłem

W przypadku kiedy miniaturka będzie istnieć: uploads/images/product1/233/1_thumb.png wówczas zakryje default_thumb.jpg który znajduje się w div'ie pod spodem. Kiedy nie ma miniaturki, zwyczajnie wyświetli się tylko tło div'a.

Poco niby zaczytywać niepotrzebne obrazki ? Klient będzie czekał na ich załadowanie ?

Super że po godzinach pracy zajmujesz się wróżbiarstwem, tyle że twoja kryształowa kula, lub fusy, są trefne. Bo przyszło mi pracować, może nie tyle co tobie, ale pracować pracowałem. Chwała bogu że mamy xml, dzięki czemu możemy mieć drzewiaste kategorię w sklepie. Zaraz, czy najpopularniejsze skrypty dostępne w sieci nie trzymają tego drzewka w bazie?


Możesz domniemać że nie pracowałem z xml lub pracowałem mało, w twoim przypadku jest odwrotnie, dużo pracowałeś z xml, mało lub wcale z bazą danych.


skomentuje to tylko tak ->


Wiem co to jest, tyle że w przypadku bazy, te dane parsuje odpalony demon, te dane możesz trzymać w pamięci ram, dzięki czemu możesz mieć mega szybki dostęp. A xml to niby jak powstaje? To wszystko musi być parsowane przecież..


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


Każde dodatkowe sprawdzenie czy plik istnieje, czy posiadasz prawa odczytu - to wszystko kosztuje nie tyle co pamięć, co czas potrzebny dla dysku na odczyt.


Zawsze może poczekać aż się skrypt przeładuje żeby odczytać 40 plików xml

Mam prośbę, do kogoś postronnego który mógłby użytkownikowi @cudny wytłumaczyć różnicę w koszcie pobrania danych jednym zapytaniem do bazy, a różnicę kosztu odczytania 40 plików xml i przetworzenia danych zawartych w tych plikach..

Posłuchaj, przecież tutaj nawet nie potrzeba wiedzy w danym temacie żeby odrzucić twoje rozwiązanie. 40 plików xml, to jest 40 odczytów, 40 instrukcji warunkowych sprawdzających czy plik istnieje, czy masz dostęp, oraz 40 instrukcji warunkowych sprawdzających czy w danym xml'u coś w ogóle jest. Jak ten złożony łańcuch instrukcji ma się do instrukcji tylko 40 instrukcji warunkowych, które sprawdzają czy tablica danych pobrana 1 zapytaniem z bazy, zawiera w odpowiednim rekordzie, odpowiednią wartość dla pola miniatury? xml wygląda przy takiej bazie danych wówczas jak żółw kuternoga, kiedy w tym samym czasie baza danych nawet zadyszki nie złapie kilkukrotnie okrążając zmulonego xml'a.

Nikt przy zdrowych zmysłach w skrypcie nie użyłby xml'a nawet do konfiguracji, bez uprzedniego cachowania jego zawartości. A ty tutaj namawiasz do przetworzenia 40 takich plików. Faktycznie genialne, jeżeli chce się zabić serwer.

PS. mam prośbę do ciebie @cudny, weź przygotuj jakieś demko swojego rozwiązania online, niech ten skrypt otwiera 4 plików xml, z zapisem o jakim wcześniej wspomniałeś. Wrzuć dodatkowo jakieś memory_get_usage/peag_usage i przy okazji czas wykonywania skryptu. Może podczas sprawdzania twojego rozwiązania, dojdziesz do wniosku że twój pomysł z wydajnością ma niewiele wspólnego..

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.


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 ?


To lepiej nie komentuj


Ale nie tak jak myślisz, że od razu masz 10 megowy plik w pamięci ram

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
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 :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 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.

Wyobrażasz sobie 1 plik, przetrzymujący informację o kilku sety fotkach? Nawet jeżeli to będzie w cache, otwieranie za każdym razem tak dużego cache i alokowanie zbędnej pamięci, jest bardzo dużym przerostem formy nad treścią.



są strony które mają dynamiczne drzewo kategorii, miejscami dość mocno zagnieżdżone (chomikuj.pl?) i gdzie trzymają dane? Wątpią aby trzymali je w xml'u. Mało jest takich szalonych ludzi, póki co zaliczasz się do tego niewielkiego kręgu.


Dlatego też podałem drugi przykład, który nie dotyczy zarówno sprawdzania katalogów, plików, nie szuka danych w bazie, nie wczytuje pliku xml, właściwie jest banalnie prosty i w swojej prostocie szybki.


Nie masz, bo byłby to raz że narzut wydajnościowy, a dwa to by były duże ilości danych i odebranie tych danych przez użytkownika trwało by stanowczo za długo. W przypadku xml'a wyświetlenie również całego drzewa kategorii, dało by taki sam efekt - duża ilość danych. Dodatkowo po co wyświetlać wszystkie kategorię i robić bardzo długie drzewo kategorii? Jesteś pierwsza osobą którą spotykam, która tak namiętnie, aż prawie całkowicie bezsensownie, wykorzystuje xml'a do rzeczy, do których nie powinien zostać wykorzystany ze względu na to jaki generuje narzut na wydajność.

ehh... nie mogę się niestety zgodzić, że za przeproszeniem takie pierdółki jak trzymanie nazwy i id fotki, ba nawet kilku tysięcy fotek jest bezsensem dla pliku xml.
Zobacz, otwierasz sobie xml w dom i znajdujesz po id - dom wspiera unikalne id i sam je nadaje - dany katalog (w tym wypadku będzie to kawałek drzewka).
Po co zaprzęgać do tego bazę danych ? całe drzewo masz już gotowe do wyświetlenia - nie musisz nic parsować.
Jedziesz rekurencyjnie po gotowych danych.
Jasną rzeczą jest, że wyszukiwanie i parsowanie całego xml (wtedy trzeba zaczytać go całego do cash) jest bezsensem ale.. pobranie gotowego wyniku już nie
Ważną rzeczą jest do czego xml się wykorzystuje i jeśli jest możliwość trzymania danych, które zwrócą ci gotowe dane bez wykorzystywania bazy to ja jestem za.
Galerię tworzę sobie zawsze na xml, bo po co do tego używać bazy skoro i tak musisz potem te dane zapisać do tablicy.
xml nie zapisujesz tylko od razu wypluwasz.
A co do drzewa kategorii... Zaraz dam subskrypcje na ten temat i sprawdzę jak zachowa się wyświetlenie drzewa przy kilkudziesięciu tysiącach kategorii z bazy i z xml - nigdy tego nie testowałem bo... zawsze używałem bazy i pobierałem ajaxowo daną kategorię
Wyniki wrzucę tutaj. Zżera mnie wręcz ciekawość

Zauważ jednak to że jeśli faktycznie ktoś się porusza po tym drzewie bardzo często to ilość requestów jest spora, a w przypadku gotowego drzewka pobierasz dane raz i javascript zalatwia reszte, tym bardziej, że xml można od razu wrzucić na public i wykorzystywać usera do parsowania xml

Nie sądziłem że baza, a właściwie funkcje/obiekty które operują na tej bazie, zwracają dane w innej postaci niż tablice, lub obiekt który w większości przypadków implementuje interfejs ArrayAccess, dzięki czemu dostęp do danych jest taki sam jak w przypadku tablicy.


Po co? Właśnie po to że pozostałe dane i tak lecą z bazy. Dołożenie do tej bazy jakiegoś joina, to jest minimalny narzut wydajnościowy. I jest od razu pod ręką, a sama baza może nie jest aż tak funkcjonalna pod względem drzewa co xml, ale jest wystarczająca praktycznie w większości przypadków, gdzie nawet książki opisują przykłady właśnie na bazie danych - szerokim łukiem omijając mulastego xml'a.

Wrzuć wynik, zmierz go kilka razy, zarówno dla czasu wykonywania jak i użytej pamięci. I najlepiej udostępnij pliki na których pracowałeś

Cudny: Po pierwsze, jeśli uważasz, że drzewiastej struktury nie można wrzucić do bazy i odpytywać inaczej niż rekurencyjnie to się z deczka mylisz. Co zabawniejsze... mogę ją pobrać jednym zapytaniem Jedyne utrudnienia są przy edycji (dodawanie, edycja. usuwanie) węzłów i na to trzeba kilku zapytań, ale ile razy to robisz? Zazwyczaj te operacje są tylko sporadycznie po postawieniu serwisu. Właśnie kilka dni temu to robiłem w oparciu o bazę danych. W zasadzie w chwili obecnej całą strukturę kategorii wrzucam do bazy i zapisuję w cache'u, a w razie edycji ten cache aktualizuję. Baza więc ma niemal zerowe obciążenie z tego powodu bo przez 99% czasu używam cache'u. Właściwie to dostosowałem do własnych celów jsTree, którego kod odwalił za mnie 90% roboty.
Po drugie to jeśli się bawisz już plikami xml, to chyba zdajesz sobie sprawę, jak upierdliwe jest edytowanie czy modyfikacja struktury zazwyczaj. Ja już nawet nie mówię o poszukiwaniu elementu o nieznanej do końca ścieżce. XPath to świetna rzecz, ale w porównaniu do SQL i tak wypada blado. Cokolwiek ciutkę bardziej złożonego i jest problem. Już nawet nie mówię, że poprzez pliki XML można serwer wywalić. Poczytaj o ataku "one million laught" czy preparowaniu xml o złośliwej strukturze. To są rzeczy o których się niewiele mówi, ale są równie zabójcze dla serwisów jak sql-injection.

Czyżby cały IIS był do bani-przecież tam cały konfig jest na xml'u.

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

Poprawka, tak mówi tylko jedna osoba w tym temacie, i te drzewko kategorii akurat nawiązał jako jedna z przewag którą ma xml nad bazami.


Ah, przez tego xml'a całkowicie zapomniałem ci napisać, że nie musisz tworzyć katalogów kategorii, wystarczy że stworzysz katalog z ID produktu, reszta jest zbędna. Zbędna, ponieważ w przypadku zmiany kategorii, musisz przenosić katalog z plikami z jednego katalogu do drugiego. Dodatkowa funkcjonalność która jest zbyteczna moim zdaniem. Wystarczy samo ID danego produktu.

Jeżeli już skorzystasz z mojego rozwiązania, bo w sumie nawet mi się spodobało, to nie zapomnij o tym dodatkowym skrypcie, żeby niepotrzebnie nie zapychać logów apacha. Lub mieć to nawet w poważaniu, bo przecież sytuacja że jakieś pliki przypadkowo zostaną skasowane jest bardzo marginalna. No ale w razie czego masz możliwość reagowania na brak tych plików w sposób inny niż tylko zapisanie logów przez apache.

Też tak uważam. ID w bazie, jako unique (albo lepiej: auto_increment), i troszczyć się tylko o dodawanie i usuwanie (katalogów i plików).
W kwestii dwóch rozwiązań:
1. trzymanie plików w bazie - oprócz obciążania serwera WWW mamy narzut na operacje związane z bazą danych podczas serwowania pliku
2. trzymanie plików na dysku w katalogu - Co prawda musimy obrobić katalog ze zdjęciami. I zapewne tych plików będzie kilka-kilkanaście (bo jeśli to są zdjęcia produktów, to chyba nie tysiące?) - ale nie obciążamy bazy, tylko podajemy "a href" do pliku ze zdjęciem i koniec. Dodatkowo: jeśli są to zdjęcia czegoś popularnego i często czytanego, to odczyt katalogu i plików może zostać przyspieszony przez trzymanie tego w cache/buforach systemu operacyjnego.

Każde rozwiązanie ma swoje wady i zalety. Na pewno prościej policzyć sumarycznie ilość zdjęć przez wykonanie selecta do bazy, ale przecież można dodać obok "ID" kolumnę z ilością dodanych zdjęć, i relatywnie niewielkim narzutem często wykonywane operacje możemy usprawnić.
Pytanie zasadnicze, na które sam najlepiej znasz odpowiedź: czy więcej zajmują Ci zapytania do bazy, czy wykonanie kodu? Jeśli baza się męczy, to lepszym rozwiązaniem będą pliki (po co dociążać coś, co już zajmuje dużo czasu). I odwrotnie. Ale to już sam musisz przemyśleć.

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.

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

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



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


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

Chyba sie troszke nie zrozumieliśmy. U mnie, każdy rodzaj produktu ma inne właściwości opisujące go. Dlatego jeden produkt ma w swojej tabeli powiedzmy 24 kolumny, a inny 50. I jeśli nie bierzemy pod uwage kolumn nazwy, kategorii, id (?), wyświetleń, akceptacji publikowania, to każdy jest inny. Nie mogłem dac tego do jednej tabeli - nie opłacałoby się.

Wyszukiwanie? Zwykłe wyszukiwanie po nazwie. Jesli zaawansowane, to w tedy user musi wybrać czego szukać i gdzie - dlatego to się nazywa zaawansowane