- This topic has 15 hozzászólás, 4 résztvevő, and was last updated 19 years telt el by
.
-
Bejegyzés
-
Remélem értem mit mondassz, tehát egy relációs adatkapcsolat, mégpedig egy-több kacsolat, én valahogy így csinálnám:
table.1.xmlCode:Valami string
Más valami string
Ez meg egész más
…
Ez meg izétable.2.xml
Code:
A table1 1. sorához rendelt elsõ szöveg
A table1 2. sorához rendelt elsõ szöveg
A table1 1. sorához rendelt második szöveg…
Remélem érthetõ
Kayapo jót írt, bár én átírnám így:
table.1.xmlCode:Valami string
Más valami string
Ez meg egész más
…
Ez meg izétable.2.xml
Code:A table1 1. sorához rendelt elsõ szöveg
A table1 2. sorához rendelt elsõ szöveg
A table1 1. sorához rendelt második szöveg
…
Igazából mind a kettõ ugyan az, csak így jobban beleillik a saját agyi elképzelt világomba :wink1:. Na meg másképpen kell kezelni egy kicsit feldolgozáskor.
Leslieman wrote:Kayapo jót írt, bár én átírnám így:
table.1.xmlCode:Valami string
Más valami string
Ez meg egész más
…
Ez meg izétable.2.xml
Code:A table1 1. sorához rendelt elsõ szöveg
A table1 2. sorához rendelt elsõ szöveg
A table1 1. sorához rendelt második szöveg
…
Igazából mind a kettõ ugyan az, csak így jobban beleillik a saját agyi elképzelt világomba :wink1:. Na meg másképpen kell kezelni egy kicsit feldolgozáskor.
Ez így tényleg kompaktabb, de ne felejtsük el, hogy ez utóbbi esetben a rel=”1″ tulajdonság a címke gyermek tuljadonságe, míg az elõzõ esetben a objektum – amely a cimkén belül van – gyermek tulajdonsága, ha késõbb xslt vagy más módon dekódolást kell végezni, egyszerûbb az elsõ módszer eredményével dolgozni, de ha ilyen biztosan soha nem fog történni, fõleg ha több száz, több ezer sort tárolsz, bizony jelentõs adatmennyiséget és gépidõt takaríthatsz meg a második módszerrel.
„egyszerûbb az elsõ módszer eredményével dolgozni”
Mármint miért egyszerûbb?
Maga a forrás mondjuk a második esetben átláthatóbb (mondjuk egy libxml++-ra gondolva – mert én csak azt ismerem) egy sima get_name, get_value 2x, sõt akár maga a sring is benne lehetne:Code:Bár attól függetlenül valami ilyesmi közelebb áll az emberi szemlélethez:
Code:…mivel logikailag így kapcsolódik a dolog – szerintem. (Bár, ha a feldolgozási – nem keresési – sebesség ami számít, akkor az elõzõ megoldás. Ha mondjuk keresni kell benne valamit, akkor lehet, hogy e második módszer…)
Mondjuk ez utóbbi módszer alkalmas lehet egy több dimenziós táblázat (könnyen áttekinthetõ) kezeléséhez is.„jelentõs adatmennyiséget és gépidõt takaríthatsz meg a második módszerrel.”
Az biztos igaz. Minden egyes lépcsõnél néhány dinamikus, de legalább statikus konverciót biztosan meg lehet spórolni – ami tudjuk, hogy nem a leggyorsabb + néhány ellenõrzést (hibás, hiányos adatok), bár ez egyik módszernél sem árt, noha a mennyisége stb. változhat.A keresesnel vagy akar xslt atalakitasnal gyakorlatilag szinte mindegy, hogy a ‘rel’ adatot hova rakod. A kulonbseg inkabb csak elmeleti.
Szerintem a ‘rel’ az adott elem tulajdonsaga, ezert irnam bele a „fejebe”, mig a szoveg maga a tartalom, azt meg ezert irnam az elemet nyito/zaro blokkok koze.Elgondolkodtatott ez a dolog és mivel éppen egy helpdesk rendszeren dolgozok, amiben a html dokumentumokat xml/xsl templatekkel hozom létre kicsit játszottam ezekkel az adattároló modellekkel:
template.0.xml :Code:CDATA[„Tartalom UTF-8 karakterkódolással 0x000000 – 0xFFFFFF kódig véletlenszerûen elõállítva 256 karakter hosszban”]
a dekódolást PHP5-XML-parser -rel végeztettem
A fentebb leírt két formátumú dokumentumot akartam ezzel összehasonlítani, ugyanis ez a szabványos írásmód és elsõre ez is a leghosszabb (mármint futásidõben ez tûnik a leghosszabnak) de ez bizonyult a leggyorsabbnak, kb 20% -kal gyorsab a Lesliman által írtnál és vagy 45% -kal gyorsabb annál amit én írtam. Persze csak 2 ~ 3 másodperces futásidõkrõl van szó, még ekkora adatmennyiségeknél is de ha ezenmúlik egy timeout az elég kellemetlen dolog.Szóval ez érdekes, még azon vagyok, hogy kiderítsem, mitõl van ez a külömbség
kayapo wrote:Code:CDATA[„Tartalom UTF-8 karakterkódolással 0x000000 – 0xFFFFFF kódig véletlenszerûen elõállítva 256 karakter hosszban”]
Ha jól értem, készítettél egy valag ilyen sort, ahol a tagon belül csak egy 256 elemû tartalom van.
Akkor persze, hogy gyorsabba a feldolgozása, hiszen nincs benne „altag”, vagy hogy hívják.Azon kívül még ahhoz, amit Vizsla írt csak annyit, hogy nagyon nem mindegy, hogy az xml-t csak beolvasni („parsolni”) kell-e, vagy az ellenõrzéseket is el kell-e végezni közben. Az elsõ esetben csak annyit végez a parser, hogy az xml állomány -jait ellenõrzi, hogy rendben vannak-e, le vannak-e zárva párban, stb. (well formed).
A második esetben pedig az általad megadott séma alapján ellenõrzi azt is, hogy csak olyan elemek vannak-e benne, csak olyan értékekkel, csak olyan sorrandben-e, amit a séma elõír. Ez természetesen J„A második esetben pedig az általad megadott séma alapján ellenõrzi azt is, hogy csak olyan elemek vannak-e benne, csak olyan értékekkel, csak olyan sorrandben-e, amit a séma elõír. Ez természetesen J
Nem errõl van szó. Mikor a parszer (DOM inspector) elindul létrehozz néhány dokumentum specifikus objektumot köztük a dynamic-elementet, ha ezt használod nem kell azzal, eltölteni a gépidõt, hogy létrejöjjönek ez elemekhez tartozó objektumok, változók stb, majd ha a munka befejezõdött, felszabadítani a memóriát, lezármi a szálakat, stb.
(U.I.: ezeket némi googlezás után így sejtem)
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz