Mam stworzyć system obsługujący bardzo duże ilości użytkowników. Zbudowany w pełni na PHP5 i głównie wykorzystujący MySQL(i), jednak z możliwością podpięcia dowolnej bazy (własny driver, nie chce się bawic w ADODB).

Zastanawia mnie, czy przy paru tysiącach rekordów warto wrzucać takie rzeczy, jak opisy tekstowe do bazy danych. Teoretycznie wydaje się, że najlepszą opcją było by przechowywanie elementów tekstowych oraz innych im towarzyszących (np. jakieś atrybuty) w pliku XML (jeden plik to jeden zestaw: opis + atrybuty). Czy parsując go SimpleXML, można by zyskać dużo lepszą prędkość działania, niż korzystając z bazy i pól typu TEXT?

Oczywiscie mankamentem tego pomysłu jest brak możliwosci (z powodów oczywistych) przeszukiwania po opisach i innych elementach znajdujących się wewnątrz plików XML.


Nie chce zaśmiecać bazy niepotrzebnymi dziesiątkami megabajtów opisów. Nie wiem tylko, jak to ma sie do wydajności parsera. Jeśli ktoś ma doświadczenie w temacie, proszę o jakieś rady i przydatne informacje.

Wybór należy do Ciebie. Nie rozumiem tylko jednego co to znaczy "zaśmiecać bazy niepotrzebnymi dziesiątkami megabajtów opisów" - z jednej strony chcesz trzymać te dane, z drugiej uważasz je za niepotrzebne ... to jak to jest? Jeśli są niepotrzebne to może wcale ich nie trzymaj A tak bardziej technologicznie... wybór technologii należy do Ciebie - decudując się na jakąś, zgadzasz się na jej ograniczenia. To czy wybierzesz MySQL, Postgresa, pliki tektoswe ... to wszystko uzależnij od tego co Ci będzie teraz/w przyszłości potrzebne. Nie stosuj jednak technologii na siłę ... może XML jest "trendy", ale czy w tym przypadku gdy chcesz przechowywać wiele danych ? Jeśli są to dane userów, to trochę słabo wygląda np brak możliwości przeszukiwania.
W sumie pytanie było bardziej filozoficzne, niż techniczne
Do zestawu technik przechowywania danych mogę od siebie dodać jeszcze katalog LDAP chyba najlepiej nadaje się do przechowywania takich danych jak userzy.

Gdyby dane nie były potrzebne, to problem przechowywania miałbym z głowy

To nie będą dane userów, tylko sopra ilość tekstu, po którym nie będzie konieczne realizowanie szukania (przynajmniej tak zakładam). Więc nie ma sensu wrzucać tego do bazy, bo z tego co mnie wiadomo, im większa tabela i więcej w niej danych, tym wolniej się ją przeszukuje. A w tabeli aktualnie jest 2 tys elementów, do końca roku ma byc 5x tyle.

Dlatego chcę wskoczyć na XML i trendy czy nie, nie ma to nic do rzeczy, XML jest prosty w użyciu i lepszy do wykorzystania późniejszego niż np. zserializowany obiekt.

Dlatego pytam o speeda, przemyślenia "czy warto" mam już za sobą

Rzeczywiscie xml stal sie jakis trendy ale jednego nie rozumiem. Czemu wszyscy porownuja xml'a z baza danych. Przeciez nie za bardzo da sie to porownac. Zreszta tak jak przedmowca, sam musisz podjac decyzje co bedzie latwiej ci obsluzyc. Do bazy danych zapewnie masz juz jakies polaczenie lub heandler napisany. a tutaj musial byc albo uzyc simpleXML ktore jest poprostu "simple", albo parasowac dokument xml co jest przy niektorych modelach pamiecio-chlonne. Zreszt edycja dokumentu xml nie jest prosta, bynajmniej nie pamietam zeby mozna bylo tak pieknie i ladnie edytowac go. Wiec ewentualny zapis tez bedzie musial posiadac wlasne funkcje. Jedyne zastosowanie xml'a jakie na razie znalazlem to zapisywanie danych ktore maja byc transportowane lub/i pozniej importowane przez jakis inny system. Na razie innychzastosowac (no moze procz jeszcze SOAP i RPC) nie spotkalem, ale doksztalcam sie w tym kierunku

Ha... dobre sobie. Co masz na myśli pisząc "więcej danych"? Ilość rekordów, czy duży rozmiar pojedynczego rekordu? Jeśli to drugie to nie ma to wpływu na szybkość przeszukiwania, zwłaszcza jeśli nie zamierzasz wyszukiwać względem kolmny, która będzie przechowywać duże ilości danych.

To pierwsze ma wpływ, ale w dobrze zaprojektowanej bazie w praktyce niewielki, bo czas wyszukiwania jest logarytmiczny. Pozakładaj indeksy na kolumny wg. których będziesz wyszukiwał i będzie szybko działać.



10 tys. rekordów? To bardzo mało. W pracy mam do czynienia z tabelami po 2mln rekordów i czas przeszukiwania takiej tabeli dla przeciętnego człowieka, jest taki sam jak przeszukiwanie tabeli z 1000-cem rekordów.

Używanie wielu różnych systemów do przechowywania danych sprowadza inne kłopoty. Np. komplikuje robienie backupów i zagraża integralności danych. Co się stanie jeśli kotś przez przypadek skasuje jeden plik XML? W bazie będziesz miał odwołanie do nieistniejącego pliku i nie będziesz w stanie nad tym zapanować.

Przechowuj dane, które stanowią całośc w jednym miejscu. 3xTAK dla baz danych

Pozdrawiam.

Dzięki za odpowiedzi

Do rzeczy - XML byłby dla mnie idealną sprawą do przechowywania własnie niektórych informacji. Te właśnie informacje nie muszą iść do bazy, nie będą przeszukiwane, używane są tylko raz - do wyświetlenia konkretnej podstrony. Ale ich poziomy zagłębienia mogą się bardzo zmieniać i tutaj idealne zastosowanie ma XML. (Chce do tego dodać właśnie jeszcze opisy tekstowe)

Oczywiście można to napisać nawet i w bazie, będzie to działało na pewno, ale dlaczego nie użyć XML? Dla mnie jest to latwe, może dlatego, że znam dość dobrze sam XML i jego możliwości. Obsługa DOM (zapis) w PHP5 natomiast jest troszkę kłopotliwa, ale już SimpleXML (dla odczytu) to sprawa banalna.

W ogóle świetną sprawą dla mnie było by przygotowywanie wyniku strony w XML, cache tego gdzieś na dysku (czy w bazie, whatever), po czym przeróbka w XSL na odpowiedni design (zależnie od tego, czy strone ogladamy na komputerze, czy może na komórce). Ale niestety z tą opcja musze poczekać jeszcze z rok, póki obsługa obu tych standardów w php nie zostanie do końca zaimplementowana.


Sh4dow --> XML ma mase zastosowań, część wymieniłem powyżej, a ich ilośc jest nieograniczona. Zasadniczo sam decydujesz, do czego użyć XML. Sławny XHTML, w jakim teraz pisze się poważne strony, jest wersją XTML zgodną ze standatdem XML. XML jest łatwy w użyciu, czytelny i ma na prawdę poważne mozliwości.

Parti --> ja nie chce wiedzieć jaką prędkośc ma przeszukiwanie dla człowieka, ja chce by po postawieniu 10... powiedzmy 30 kopii serwisu na jednym serwerze i obiciązeniu tego setkami userów, baza nie padła. Integralność danych jest ważna, dlatego kluczowe sprawy będą w bazie. Natomiast elementy dodatkowe mogą z powodzeniem zostać wrzucane do XML. Tylko co jest szybsze??

Jezeli tresci ktore chcesz miec w plikach zamiast w bazie nie sa bezposrednio polaczone z tymi ktore mialy by byc w bazie danych to ok. Moga byc na plikach. Ale jezeli zachodzi miedzy nimi scisle powiazanie (relacja) z tymi ktore mialy by byc w bazie danych, to one takze powinny do bazy danych trafic. (nie bez powodu mowimy o RELACYJNYCH bazach danych )

To co napisalem powyzej to jedyne kryterium czy wsadzic dane do bazy czy nie. To czy tych danych jest duzo czy malo niema znaczenia (wydajesz sie tego nie rozumiec). W bazie danych nie przechowujesz danych binarnych (na plikow .png) cala reszte mozna do niej wrzucic.

Baza danych bedzie zdecydowanie szybsza. To przeciez oczywiste . Xml daje jak sam mowiles potezne mozliwosci i ma wiele zastosowan, ale nie jest to absolutnie technologia ktora miala by konkurowac z bazami danych pod wzgledem szybkosci wyszukiwania danych, stabilnosci czy niezawodnosci dzialania. To po prostu foramat zapisu informacji. A twoja ewentulana witryna w xml bedzie oparta na PLIKACH. Wyszukiwanie informacji w plikach bedzie wiec wolniejsze od wyszukiwania w bazie danych danych i tyle.

A propo szybkosci dzialania. Łancuch jest tak mocny jak jego najslapsze ogniwo jezeli wiec laczysz baze danych, z plikami xml, ktore mial bys parsowac wte i wewte - w zaleznosci od potrzeb - to wydajnosc systemu spada. Wszystko to jednak teoretyczne gadanie bo tworzysz przeciez aplikacje a nie mechanizm sterowania rakieta Pliki xml beda ok pod warunkiem ze witryna bedzie niewielka.

Idealnym dla Ciebie rozwiazaniem byl by system w ktorym z serwera idze do bazy danych zapytanie (SQL) a baza danych daje odpowiedz juz w postaci dokumentów XML, ktore nastepnie sa laczone w wieksza calosc i transformowane XSLT do odpowiedniego formatu (XHTML). Takie cudenka chodza na Oracle (K) i SQL Server microsoftu (instrukcje OpenXML itd.).

Probelem polega jednak na tym, ze (z tego co mi wiadomo ) jak narazie Mysql ani zadna inna "darmowa" baza danych z ktora wspolpracuje php nie "wypluwa" plikow XML.

Mozesz napisac aplikacje ktora laczy relacyjna baze danych z plikami xml (wstawia do nich tresc) ale taki wynalazek ograniczyl bym jedynie do niezbednego minimum. (Np chcesz miec kanal RSS na stronie). Inaczej bedzie to raczej eksperyment (bardzo pouczajacy i ciekawy) niz sensowne dzialanie.