MySQL stinkt oder wie bekomme ich hierarchische Daten da wieder raus?

SideWinder

Ich habe eine simple Gruppen/Sub-Gruppen-Tabelle like:

Group ( group_id , parent_group_id, some_info )

Wie kann ich nun für eine Gruppe das höchste some_info rausholen das da ist?

CONNECT BY? WITH RECURSIVE? Irgendwie ist nichts da was man erwartet. Man googelt auch nichts.

MfG SideWinder

Christoph

Für MySQL gibt es vielleicht bessere Darstellungen:
http://dev.mysql.com/tech-resources/articles/hierarchical-data.html

SideWinder

Also entweder sehe nur ich das Problem an diesem NestedSet-Modell nicht, oder dsa ist für dynamische Strukturen untauglich. Nehmen wir an ich füge zu einem späteren Zeitpunkt einen weiteren Television ein, so hätte das ja zur Folge, dass ich den gesamten Baum neu berechnen muss? Das ist doch ein schlechter Scherz für ein Rollenkonzept.

Edit: Artikel genauer lesen, also die wollen doch tatsächlich eine Stored Procedure für ein simples Insert. Das kann ich leider auch nicht in Kauf nehmen.

Schämt sich diese "Datenbank" denn gar nicht dafür, kein einziges normales Rechtesystem umsetzen zu können? Wie erledigen die das eigentlich intern? MySQL-Rechtesystem?

OMG, unter MySQL 4.x empfehlen die einen ganzen Table-Lock! Holla die Waldfee.

MfG SideWinder

hustbaer

MSSQL konnte das bis zur Version 2005 auch nicht

Wenns nicht anders geht -> Schleife + Temp-Table oder Table-Variable.

Bei transaktionalen Tables in eine Transaktion wrappen, bei stinkigen MyISAM Tables eben Table-Lock - geht ja nicht anders.

SideWinder

Vielleicht war damals der MSSQL-Anteil unter den Datenbanken aus gutem Grund noch nicht so hoch

Nunja, ihr macht mir ja nicht gerade Lust auf mehr. Ich gebe mal die Hoffnung nicht auf und werde das mit diesem NestedSet-Modell versuchen. Ob es da schon Performance-Vergleiche gibt? Eine normale Tabelle, die Schleife im Programm vs. Nested Sets?

MfG SideWinder

hustbaer

Wenns mit Nested-Sets mit nur einem SELECT geht, dann müsste das zumindest bei kurzen Tabellen (wenig Zeilen) schneller sein.
Bei langen Tabellen vermutlich auch, aber nur wenn alle WHERE über den Index optimiert werden können.

p.S.: ich meine natürlich nur Abfragen. Änderungen sind mit Nested-Sets garantiert langsamer, nur ändert man ja sowas normalerweise nicht oft...

nman

SideWinder schrieb:

Vielleicht war damals der MSSQL-Anteil unter den Datenbanken aus gutem Grund noch nicht so hoch

Naja, MSSQL war bis vor ein paar Jahren doch genauso furchtbares Spielzeug wie MySQL, nur teurer und man musste sich dafür einen Windows-Server hinstellen. Das hat sich erst in den letzten Jahren zu einem ernstzunehmenden DBMS gemausert.

Aber das kannst Du Jungspund ja nicht wissen können. :p

hustbaer

@nman:
Wenn 10 Jahre für dich "ein paar" sind, dann ja.
SQL Server 2000 als Spielzeug zu bezeichnen hielte ich auf jeden Fall für ziemlich daneben.

nman

hustbaer schrieb:

SQL Server 2000 als Spielzeug zu bezeichnen hielte ich auf jeden Fall für ziemlich daneben.

Der 2000er war benutzbar und im Vergleich zum 7.0er sicher auch fein, aber verglichen mit der Konkurrenz… Naja, billiger als Oracle oder DB2, aber sonst fand ich das Ding gelinde gesagt nicht sehr aufregend.

Ich sehe den 2005er als den ersten SQL Server, der in richtig vielen Fällen als Alternative zu DB2 und Oracle taugt und der 2008er ist echt gut geworden, auch wenn ich einige Leute kenne, die über irgendwelchen Kleinmist schimpfen.

hustbaer

Also ich fand den 2000er sehr OK (für damals, und speziell als Step-Up vom 7er). Allerdings fehlt mir die Erfahrung mit anderen Systemen um das vernünftig vergleichen zu können.

Was ich beim MSSQL toll finde sind die Tools. 2x Klicksi und ich hab den kompletten Execution-Plan einer Query. 3x Klicksi und ich hab den Profiler auf nem Live-Server drauf hängen wo er mir hübsch alle Statements mitloggt damit ich gucken kann wo am meisten Performance drauf geht.

Was ich weniger toll finde ist dass MS manche Dinge unglaublich spät überzuckert (wie z.B. dass Table-Variablen als Input- und Output-Parameter für Stored-Procedures Sinn machen -- hat bis zur 2008er Version gedauert). Und dass sie wieder die typische Abzocker-Schiene fahren, und gewisse Features die nahezu jeder gut brauchen könnte auf die Enterprise-Version beschränken (wie z.B. Page-Compression und Backup-Compression).

witte

hustbaer schrieb:

... Und dass sie wieder die typische Abzocker-Schiene fahren, und gewisse Features die nahezu jeder gut brauchen könnte auf die Enterprise-Version beschränken (wie z.B. Page-Compression und Backup-Compression).

Das werden sie sich von Oracle abgeschaut haben. Ich sag nur Function based indicies.