The(G)Forum

Falls irgendöpper würkli guet isch mit t-sql, wäri würkli froh.
Problem han innere table hierarchie-beziehige in zwei kolonne. öppe 3 millone records.
ich müesst mittere rekursion für einzelni records usefinde, was alles unedra isch - direkt oder indirekt.
das isch nöd d'schwierigkeit. han zwei methode gfunde, mit däne sich das mache laht:
- CTE rekursion
- TABLE variable mittere WHILE schlaufe

Beidi funzet, aber beidi bruchet bis zu 60 sek für ein Rekord...

Also, falls eine würkli guet drus chunt und das problem kännt, wäri ächt froh um e PN, dänn chani wiiteri details ageh.
Leider hani vom gschäft us kei zuegriff uf dä (G) - also chas echli duure, bis ich antworte.

Hesch indexe uf de parent / child ids druffe? Weiss das isch en dummi frag, aber ich has scho paar mal erläbt.

Falls indexe hesch:
Ich kenn dini date nid aber e beliebti technik um schnell uf hierarchie zuegriffe z'chönne isch se "flach" z'mache bzw. z'denormalisiere.
http://jpbi.blogspot.com/2007/05/sql-tr ... child.html" onclick="window.open(this.href);return false;

So wäri en lookup es sehr triviales sql.

Das geit natürli nur wend e feschti azahl levels hesch oder du machsch halt uf guet glück gaaaanz vieli spaltene mit de levels. Und du müestisch halt date je nach dem immer wieder ufbereite.

ich han innere table zwei kolonne (vereifacht):
group | member

jetzt chans sii, dass dä member sälber au en gruppe isch, wo verschachtlet worde isch.
das heisst dä 'member' taucht dänn au ide 'group' kolonne uf und hät sinersiits member, etc...

weiss nöd... chamer das indexiere? da sind mini SQL Känntnis am änd, aber das wirdi mal überprüefe.

Me cha alles indexiere. Sinnvollerwis duet me d'indexe uf die spaltene lege wo me när au abfragt. will wenns nid tuesch indexe hesch i dim fall jedes mal full table scans, was so viel bedütet das er 1 record nach em andere aluegt. Bi 3 millione zeilen und das ganze no rekursiv cha das scho e moment ga will er immer wieder en full table scan macht.

wenn du jetzt en index uf group und member machsch, wirds das ziemlich sicher um nes vielfache beschleunige. Du hesch den nüme O(n) suechzit sondern eher O(log n) was vorallem bi grosse datemängine e riese underschied macht. Oder anders usdrückt: Bi 3 millione sätz geits pro zile wos mues finde nid 3 millione mal ga vergliche sondern maximal 22mal, bi 30 millione maximal 25 mal.

Hiä no e Powerpoint präsentation von mir wos es paar tips het wiäd DB chasch optimiere. Ab folie 7 isch für di interessant.

cool, merci wirdi mal probiere

thx orphen. das hät würkli was bracht. han en composite index über gruppe und member kolonne zoge und jetzt laufed die queries ide gschwindigkeit, woni wott.

super wiä schnell isch es ize?

5-9 sek, dänn cachedses und dänn ca. 2 sek.

tönt scho mal besser. 2 sek für öppis us em cache zhole? Isch ja en ewigkeit aber wenns gnue schnell isch spillts kei rolle E witeri idee zuegriffszite ohni cache no abezbringe wäri dr cache gad update wenn öppis are struktur gänderet hätti. So würsch immer us em cache läsä.