ugrás a tartalomhoz

Fórum motor megvalósítása XML alapon?

Edit · 2005. Dec. 30. (P), 11.45
Most kezdek el fejleszteni egy kisvárosi közösségi portált (társadalmi munkában). A CMS-t XML alapon készítem, és arra gondoltam, a fórumot is XML-re építeném. Az SQL-lel valahogy sose tudtam megbarátkozni, az XML-re jobban jár az agyam. De felmerült bennem, hogy teljesítmény szempontjából ez vajon okos döntés-e. Nem tudom, hogy szerverileg mi a különbség fájlok nyitogatása és adatbázis-kapcsolatok nyitogatása között. Van valami ellenjavallat az XML-lel szemben? Nyilván sok múlik a PHP minőségén, tehát a kérdés bevallottan elméleti.

Ami a konkrét igényeket illeti, valószínűtlen, hogy 500-nál több felhasználó legyen egyszerre a honlapon. Szerver: 75 Mhz, 96 MB memória, Linux RedHat 9, Virtuozzo Virtual Private Server.
 
1

Keresés

attlad · 2005. Dec. 30. (P), 11.54
Pl. keresést hogy oldanád meg? Szerintem nem túl jó ötlet.
2

megéri?

Táskai Zsolt · 2005. Dec. 30. (P), 12.02
jópofa kísérlet lenne XML alapon megírni. de nekem felesleges időráfordításnak tűnik, mivel több olyan motor is van, amit kis munkával testre szabhatsz. ezek amúgy (mind?) SQL adatbázison dolgoznak, talán nem is véletlen... én amúgy egy bbpress-t lőttem be magamnak, mert wordpress-t már ismertem.
Tasi
3

Nem éri meg...

Edit · 2005. Dec. 30. (P), 12.29
..., de pont azért vállaltam el társadalmi munkában, mert itt ki lehet próbálni ezt-azt egy viszonylag kis felhasználói közösségen, ahol nem veszik le a fejem, ha valami nem jön be.

Ezt találtam az Amazon.com-on:
http://www.amazon.com/exec/obidos/tg/detail/-/B000BBYREI/qid=1135938269/sr=1-1/ref=sr_1_1/103-0227010-1431028?v=glance&s=books
4

XML vs MySQL db

Dualon · 2005. Dec. 30. (P), 12.42
Előre is hangsúlyoznám, nem néztem utána, nem próbáltam ki, úgyhogy ha hülyeséget írnék, valaki javítson majd ki.

Szerintem egy MySQL adatbázis számtalan "gyárilag" optimalizált függvényt tartalmaz, amelyekre várhatóan szükséged lehet adatkezeléskor (elég a rendezésre, szűrésekre, vagy akár pl. az attlad által említett keresésre gondolni), és neked kéne őket megírni - PHP-ban, amit aztán még tovább fordítgatsz. Ebből elég erős a gyanúm, hogy sebességben rosszabbul jönnél ki, amit talán kevesebb felhasználónál nem éreznél, de hosszú távon könnyen megbosszulná magát. Szerintem. :)

Dúalon
http://e-arc.hu/
5

XML lasssssssú

Jano · 2005. Dec. 30. (P), 12.53
XML-t feldolgozni nagyon lassú. XML-t főleg olyan helyeken lehet jol alkalmazni, ahol 2 rendszer kozott visznek at adatot, illetve konfiguracios fajloknal. A PHP-nek minden egyes kereskor be kell olvasnia (ez nem olyan veszes) majd fel kell dolgoznia (ez mar igen) az egesz fajlt (vagy tobbet) es ez borzaszto lassu. Mi anno csak az oldalak hierarchiajat és az egyes oldalak konfiguracioit taroltuk XML-ben de mar ez is borzaszto lassu volt. Persze azota gondolom fejlodott a PHP feldolgozoja. Anno azzal gyorsitottunk, hogy a feldolgozott binaris adatot serializalva kiirtuk fajlba es ezt olvastuk vissza.

Az a szerver gep nagyon picinek tunik. Ha elnezel vatera-ra, vagy mas aprohirdeteses oldalakra 20-30.000-ert is lehet mar legalabb egy P2 300-400Mhz, szervert venni. Ha mast nem akkor legalabb RAM-ot tegyetek a gepbe.
16

Re: XML lasssssssú

pint3r · 2011. Már. 26. (Szo), 10.59
Az előttem írót csak megerősíteni tudom. Én most épp egy flash alapú oldal mögé írok egy adminisztrációs felületet (igaz nem PHP, hanem Perl CGI). A flash XML-ben tárolja az adatokat, nem túl sokat és egy-egy admin menüpontban általában csak egy részét, mondjuk leírást, vagy tételeket listázok és ezek módosítását teszem lehetővé ill. a mentését.

Ugyanilyet csináltam (nem is 1-et) MySQL alapra, hát mit mondjak, nagyon látványos a sebességkülönbség a MySQL javára. XML-ből iszonyat lassan lehet dolgozni még ilyen kis adatmennyiség esetén is.

Szerintem felesleges nekiállni, mert használhatatlan lesz.
6

egy két próbát szerintem megér!

connor · 2005. Dec. 31. (Szo), 12.47
Az eddig "elhangzott" véleményekkel ellentétben én arra bíztatlak, hogy azért nézd meg hogy mit lehet kihozni az XMLből. :)
Persze elkerülhetetlen, hogyha már XMLre adtad a fejed akkor megismerkedj a többi XML-re épülő technológiával. (XSLT, XPath, XQuery... stb)

http://www.sleepycat.com/products/bdbxml.html (ez határozottan sokat tud)
google.co.hu: xml db

Cache-elést nem árt ha építesz az oldalba. No nem az XML miatt, ha SQL-t használsz akkor sem árt ha van cache, főleg egy fórum esetén.

--
connor
7

XML feljebb

Jano · 2005. Dec. 31. (Szo), 13.06
XML-t ha már szóba került az XSLT lehet megjelenítésnél akkor is használni ha tárolva a cuccok SQL-ben vannak. Lekered SQL-lel a dolgokat, átalakítod XML-be és onnantól igy dolgozol vele tovabb ha ez szimpatikus.
8

XML DB

gerzson · 2005. Dec. 31. (Szo), 14.56
google.co.hu: xml db
Connor rámutatott az összehasonlítások visszáságára, ti. adatbázis megoldásokat adatbázis megoldásokkal érdemes összehasonlítani. A BDBXML PHP 4-hez is illesztett nem szerver alapú XML dokumentumok tárolására létrehozott natív XML adatbázis. (Ők készítik a Berkeley DB-t is.)

Ha XML-t akarsz használni próbaképpen, akkor én mindenképpen azt javaslom, h. valamilyen natív XML adatbázist használj. Ezeknek van néhány szépséghibájuk persze:
- általában fizetősek (XML felhasználási területe nem az end-user kategória)
- többnyire Java alapúak
- nincs olyan kialakult és széles körben elfogadott nyelv hozzájuk, mint relációs társaiknál az SQL. Van némi haladás persze ezen a téren is, a fenti BDB XML ismeri pl. a XQuery-t (W3C). Az adatváltoztatás (UPDATE) terén szerintem még ingoványosabb a helyzet.

Linkek:

testing can reveal the presence of errors, but never their absence. - Edsger Dijkstra
9

XML Db

zamek · 2005. Dec. 31. (Szo), 18.42
Nos, akkor ehhez mit szóltok?
http://cocoon.apache.org

Teljesen XML alapú, brilliáns eszme, beépített cache, free, open source.
Mi kell még?

Igaz nem php alapú, hanem Java.

Itt egy mũkodõ site: http://vili.pmmf.hu
Ez is teljes egészében cocoon alapú.
10

Ez nagyon jó

Bártházi András · 2005. Dec. 31. (Szo), 19.31
A Cocoon tényleg egy nagyon szimpatikus "technológia". Egyszer majdnem megvettem olyan 20.000 Ft-ért egy párezer oldalas könyvet hozzá, mert annyira megtetszett. :)

Van belőle PHP-s is, ha valakinek úgy tetszik: http://www.popoon.org/ (én legalábbis úgy tudtam, hogy van, most meg úgy tűnik, hogy csak lesz?).

-boogie-
11

Fájlrendszer?

Edit · 2006. Jan. 1. (V), 13.42
Köszönöm a tippeket, igazából csak mostanában kezdtem el XML-lel foglalkozni, XSLT-n, stb. már túl vagyok, most jönnének a natív adatbázisok.

Ami a készülő portálocskát illeti, pont azért szerettem volna XML fájlrendszerre építeni, hogy elkerülhető legyen a szokásos MySQL nyűglődés (karakter-kódolási problémák, injection támadások, költözési macera). Csak hogy érthető legyen a probléma: a portál főszerkesztője egy vidéki rádiótudósító, a környezetvédelmi rovatot a gimnáziumi biológiatanár szerkeszti, a közbiztonsági rovatot a városi rendőrkapitányság munkatársa, az egészségügyi rovatot egy védőnő, stb. Tehát egy olyan rendszerre gondoltam, amit egy mezei Windows felhasználó is tud menedzselni, pl. az új tárhelyre költözés csak fájlok mozgatásából áll. Magyarán: nekem minél kevesebb dolgom legyen vele...:-)

A jelekből ítélve a SAX elég gyorsan beolvas bármit, tehát én kis naív arra gondoltam, hogy egy keresőszó megtalálása a spagettiben nem lehet olyan nagy gond, valaki már biztos írt egy jó kis függvényt erre. Hát nem. Tehát tovább nézelődöm a témában, és várom az ötleteket...
12

SQLite

Hodicska Gergely · 2006. Jan. 1. (V), 14.03
költözési macera

az új tárhelyre költözés csak fájlok mozgatásából áll

és várom az ötleteket...

SQLite


Felhő
13

Injection

Bártházi András · 2006. Jan. 1. (V), 16.13
Az injection támadások ellen miért védene egy XML alapú tárolási mód? Ugyanazok a problémák merülhetnek fel. Tárhely szolgáltatót pedig egyszer kell jól választani. :)

-boogie-
14

SQL injection

Edit · 2006. Jan. 1. (V), 17.08
SQL injection támadás. Ha nincs SQL adatbázis, nem is támadható...:-)
15

XML injection

Hojtsy Gábor · 2006. Jan. 1. (V), 17.11
András sem azt írta, hogy SQL injection lesz XML-ben. XML injection ellen nagyjából ugyanúgy fogsz védekezni, mint SQL injection ellen. Konverziókat alkalmazol a veszélyes karaktereken.