Resultset Designfrage - Key Value hier sinnvoll?



  • Ich grübel schon eine ganze Weile am Design einiger Datenbankabfrage und der Struktur der Resultsets herum.

    Ausgangproblem ist in etwa Folgendes:

    | ItemID |
    |--------|
    | 0      |
    
    | Names |
    |-------|
    | foo   |
    | bar   |
    
    | Counts |
    |--------|
    |      0 |
    |      1 |
    
    | Cities   |
    |----------|
    | Berlin   |
    | New York |
    

    Names, Counts und Cities beziehen sich hier auf das Item mit der ID 0 und können beispielsweise Ergebnisse von Subqueries sein.

    Das ganze soll in einem Resultset zurückgegeben werden. Der "klassische" Weg dürfte da ja ein Join über alle Tabellen sein, wobei in etwa das rauskommen sollte:

    | ItemID | Names | Counts | Cities   |
    |--------+-------+--------+----------|
    |      0 | foo   |      0 | Berlin   |
    |      0 | foo   |      0 | New York |
    |      0 | bar   |      0 | Berlin   |
    |      0 | bar   |      0 | New York |
    |      0 | foo   |      1 | Berlin   |
    |      0 | foo   |      1 | New York |
    |      0 | bar   |      1 | Berlin   |
    |      0 | bar   |      1 | New York |
    

    Problem hierbei: hohe Redundanz, dass sich die Kardinalitäten der einzelnen Tabellen aufmultiplizieren. Potentiell können die einzelnen Tabellen durchaus jeweils Dutzende wenn nicht gar Hunderte Werte enthalten. Die Anzahl der Spalten kann ebenfalls noch stark wachsen.
    Ausserdem gibts noch das kleine Problem, dass die Tabellen Names, Counts, und Cities prinzipiell lehr sein können - ich also auch wieder mit Outer Joins arbeiten müssten und NULL Values auftreten können.

    Eine alternative Lösung wäre ein Key-Value Ansatz, dessen Resultset in etwa wie folgt aussieht:

    | ItemID | Key   | StringValue | IntValue |
    |--------+-------+-------------+----------|
    |      0 | name  | foo         | NULL     |
    |      0 | name  | bar         | NULL     |
    |      0 | count | NULL        | 0        |
    |      0 | count | NULL        | 1        |
    |      0 | city  | Berlin      | NULL     |
    |      0 | city  | New York    | NULL     |
    

    Hier besteht nur noch Redundanz durch die mit NULL belegten Werte, allerdings ist die Anzahl der primitiven Datentypen letztendlich konstant.
    Aber das ganze wirkt natürlich schon sehr unelegant und so ein Ansatz macht das Weiterverarbeiten des Resultsets auch ungleich schwieriger.


Anmelden zum Antworten