Opened by leo11 at 2011-02-25 11:18
User since
2008-08-14
250 Artikel
BenutzerIn
![[default_avatar]](/battie/theme/default/default_avatar.gif)
2008-08-14
250 Artikel
BenutzerIn
Hallo.
Gegeben ist eine DB deren logische Struktur wie die eines XML's gedacht werden kann. Sie besteht aus n items, die jeweils 0-n unterschiedlichste Childbranches haben können. Jeder Branch hat eine optionale Menge an Key-Value Paaren. Hier eine vereinfachte Veranschaulichung:
Nun möchte ich Auswertungen fahren:
- Hat jedes ITEM ein np2_2? Sollte hier für das 2'te Item fehlschlagen.
- Hat jedes ITEM ein AMOUNT mit a3_5? Sollte hier ok zurückgeben.
- Hat jedes ITEM ein AMOUNT mit einem DESC mit a20_3? Sollte hier für das 2'te Item fehlschlagen.
.....
...
..
Wie man erkennt wird grundsätzlich pro ITEM über alle ITEMS geprüft. Daher sollte die Fehlermeldung auch immer die Item nr des Items mit ausgeben, bei dem die Information vermisst wird. Das ist n6_7. Hier also 10 oder 20.
Die Namen der Branches und deren Keys sind bekannt. Die Menge and Branchnamen ist überschaubar. Die Menge an möglichen Keys pro Branch liegt bei grob 200.
Als Datenstruktur habe ich dafür mit Hashes experimentiert, deren Keys, sofern es sich um eine Branch handelt, als value eine Arrayref mit Feldern von Hashes halten. Darüber jage ich dann pro prüfung 1 sub mit verschachtelten foreach mit exists key abfragen etc.
Ich vermute, das man das schlauer organisieren kann, und hab darüber nachgedacht den Inhalt als XML mit XML::LibXML zu parsen und alles über DOM zu handhaben. Dann könnte ich mit XPath arbeiten und vorgefertigte Methoden nutzen.
DOM verbraucht aber ordentlich Speicher, was bei 10.000 Items schon mal eine kritische Menge sein kann, oder? Vielleicht kann man das auch irgendwie ganz anders organisiseren.
Hat jemand Tipps für mich?
Gegeben ist eine DB deren logische Struktur wie die eines XML's gedacht werden kann. Sie besteht aus n items, die jeweils 0-n unterschiedlichste Childbranches haben können. Jeder Branch hat eine optionale Menge an Key-Value Paaren. Hier eine vereinfachte Veranschaulichung:
Code: (dl
)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
ITEM
n6_7=10
a3_1=MG
np2_2=1.11
AMOUNT
a3_5=CER
np2_2=2.22
DESC
a20_1=hello1
a20_3=test1
DESC
a20_1=hello2
a20_3=test2
AMOUNT
a3_5=CER2
np2_2=4.11
DESC
a20_1=hello3
a20_3=test3
DESC
a20_1=hello4
a20_3=test4
ITEM
n6_7=20
a3_1=MG
AMOUNT
a3_5=CER
np2_2=3.22
DESC
a20_1=go
AMOUNT
a3_5=TEE
np2_5=66.43
ITEM
...
..
Nun möchte ich Auswertungen fahren:
- Hat jedes ITEM ein np2_2? Sollte hier für das 2'te Item fehlschlagen.
- Hat jedes ITEM ein AMOUNT mit a3_5? Sollte hier ok zurückgeben.
- Hat jedes ITEM ein AMOUNT mit einem DESC mit a20_3? Sollte hier für das 2'te Item fehlschlagen.
.....
...
..
Wie man erkennt wird grundsätzlich pro ITEM über alle ITEMS geprüft. Daher sollte die Fehlermeldung auch immer die Item nr des Items mit ausgeben, bei dem die Information vermisst wird. Das ist n6_7. Hier also 10 oder 20.
Die Namen der Branches und deren Keys sind bekannt. Die Menge and Branchnamen ist überschaubar. Die Menge an möglichen Keys pro Branch liegt bei grob 200.
Als Datenstruktur habe ich dafür mit Hashes experimentiert, deren Keys, sofern es sich um eine Branch handelt, als value eine Arrayref mit Feldern von Hashes halten. Darüber jage ich dann pro prüfung 1 sub mit verschachtelten foreach mit exists key abfragen etc.
Ich vermute, das man das schlauer organisieren kann, und hab darüber nachgedacht den Inhalt als XML mit XML::LibXML zu parsen und alles über DOM zu handhaben. Dann könnte ich mit XPath arbeiten und vorgefertigte Methoden nutzen.
DOM verbraucht aber ordentlich Speicher, was bei 10.000 Items schon mal eine kritische Menge sein kann, oder? Vielleicht kann man das auch irgendwie ganz anders organisiseren.
Hat jemand Tipps für mich?