Mein Fehler. Hätte von Anfang an besser den Begriff Array statt Tabelle verwendet
Ach das kann man genauso umgekehrt sehen. Ohne das Stichwort hätte ich das vielleicht gar nicht gelesen.
In einem Baum würde ich versuchen mit möglichst wenig Knoten, möglichst viele Elemente zu verwalten.
Da hast du Recht, allerdings gibt es in meinem speziellen Fall leider einige leere Knoten, die ich nicht ganz vermeiden kann.
Einige leere Knoten sind doch sicher kein "Engpass"? Sind es vielleicht eher sehr viele?
Wodurch ist die "Kapazität" von B - E definiert? Sind das die Werte der Attribute?
D ist z.b. ein Enum mit 5 Elementen, demnach ist die Kapazität des entsprechenden Filters auch 5.
Gut, so hab ich mir das vorgestellt.
Ist die tatsächliche Anzahl der Objekte hinter der Kombination von A-E nicht relevant?
Bin ich mir nicht ganz sicher, aber wenn ich wirklich jeden einzelnen Ast rekursiv optimiere, sollte das keine Rolle spielen.
Wenn ich das richtig verstanden habe, geht es doch wahrscheinlich um Suchgeschwindigkeitsoptimierung und die würde man über eine möglichst gute Gleichverteilung erreichen?
Ein Optimierungsansatz ..
Kannst du mir da eventuell ein Beispiel geben?
Kann ich leider nicht, ich habe schon ewig nichts mehr mit Bäumen gemacht.
Anhand Deines Beispiels stelle ich mir ein Mapping vor
B=3 & E=4 könnte man z.B. zu X=15 "zusammenfassen", wenn es ein vollständiges Mapping sein müsste-was dann wieder weniger Sinn macht.
X1= B1 E0
X2= B2 E0
X3= B3 E0
X4= B1 E1
X5= B2 E1
X6= B3 E1
X7= B1 E2
X8= B2 E2
X9= B3 E2
X10= B1 E3
X11= B2 E3
X12= B3 E3
X13= B1 E4
X14= B2 E4
X15= B3 E4
Wenn einige Kombis nicht auftreten, wäre B=3 & E=4 dann vielleicht "nur noch" X=9. Analog dann für die weiteren Attribute bzw. in einer anderen Kombination, die "günstiger" ist.
Ob das Sinn macht, hängt dann von der Attributverteilung der Objekte ab. (Und davon, ob ich das Problem überhaupt verstanden habe)