Der Screenshot rechts zeigt die Konfiguration für die Sortierung mit einem Suchkriterium:

• Die Option Aufsteigend wurde ausgehend vom Standard als ausgewählt beibehalten.
  
  

• Als Projektion dient eine Feldprojektion für das Feld "Benutzername" (username).

Datenbankseitig erzeugt diese Konfiguration den Sortierausdruck
ORDER BY username ASC.

Der Screenshot rechts zeigt die beiden Projektionen:

• Die erste Feldprojektion für das username-Feld wurde aus der bestehenden Konfiguration übernommen.
  
  

• Die zweite Feldprojektion greift auf as id-Feld zu.

Die Sortierung wird wie recht dargestellt angepasst:

• Das erste Sortierkriterium bezieht sich nach wie vor auf eine Feldprojektion für das username-Feld. Allerdings wird diese jetzt innerhalb einer Aggregation vorm Typ "Klein" umgesetzt, sodass der username in Kleinbuchstaben umgewandelt wird, bevor er in die Sortierung eingeht. Diese Umwandlung macht die Sortierung "blind" bzw. indifferent für Unterschiede in der Groß-/Kleinschreibung.
  
  

• Das zweite Sortierkriterium wird effektiv nur dann wirksam, wenn das erste Sortierkriterium mehrere Werte als gleichwertig einstuft. Die Feldprojektion bezieht sich dann auf das id-Feld, das definitionsgemäß einen eindeutigen Long-Wert liefert.

username,id
===========
admin,
TEST,6851
test,7552
tEST,7553
test0,7183
test1,7184
test2,7302
TEST2,7551

Für die Reihenfolge der Benutzer "TEST", "test" und "tEST" gibt nicht mehr die im vorherigen Laufzeitbeispiel wirksame alphanumerische Sortierung, sondern der Long-Wert aus dem id-Feld den Ausschlag.

Auch die Sortierung von "test2" vs. "TEST2" beruht nun auf den id-Werten, auch wenn sie sich dadurch effektiv nicht geändert hat.

►ANMERKUNG◄ Ohne die Aggregation für das erste Sortierkriterium wäre die Reihenfolge ausgefallen wie im vorherigen Laufzeitbeispiel. Das id-Feld hätte dann effektiv keinen Einfluss, weil die username-Strings bei Berücksichtigung von Groß-/Kleinschreibung ausnahmslos unterschiedlich sind. Dies ist nicht zuletzt für die Verwendung als Kennung beim Login ja auch unbedingt erforderlich.

VIP_flag,username
========================
false,tEST
false,TEST
false,test0
false,test1
false,test2
false,TEST2

true,bcollins
true,mpolo
true,TEST_VIP
false,fbeutel
false,ftuscania
false,test

• Für die ersten sechs Benutzer in der Liste links existiert das VIP-Kennzeichenattribut in der Adresse nicht, sodass die Sortierung anstelle des Kennzeichenwerts "Kein Wert" ($null) berücksichtigt.
  
  ►HINWEIS◄ Boolean-Ausgabespalten unterliegen in einer CSV Suche oder einer Tupel-Suche eine automatischen Typumwandlung, bei der $null durch false ersetzt wird. Dadurch erscheint hier false in der Spalte VIP_flag auch für die erste Gruppe.
  
  

• Für die nächste drei Benutzer existiert das VIP-Kennzeichenattribut in der Adresse und liefert den Kennzeichenwert true.

• Für die letzten drei Benutzer in der Liste links existiert das VIP-Kennzeichenattribut in der Adresse, liefert aber den Kennzeichenwert false.

VIP_flag,username
========================
true,bcollins
true,mpolo
true,TEST_VIP
false,fbeutel
false,ftuscania
false,test
false,tEST
false,TEST
false,test0
false,test1
false,test2
false,TEST2

Die Ergebnisliste enthält jetzt nur noch zwei Gruppen:

• Die ersten drei Benutzer sind ausdrücklich als VIP gekennzeichnet.
  
  

• Alle anderen Benutzer sind nicht als VIP gekennzeichnet. Ob das Kennzeichenattribut fehlt oder false "meldet" wird nicht unterschieden.

Die Ausgabespalten für die Tupel-Suche werden wie rechts abgebildet konfiguriert:

• Die erste Ausgabespalte (count_roles) wendet eine Aggregation vom Typ "Anzahl" auf eine Feldprojektion für das Feld "Rollen" (roles) des Benutzerkontos an.
  
  

• Die zweite Ausgabespalte greift per Feldprojektion auf das Feld "Benutzername" (username) zu.

►HINWEIS◄ Diese Projektionen müssen nachfolgend auch für die "Gruppierung" und "Sortierung" verwendet werden. Dabei wählen wir für die Aggregation zwecks Transparenz willkürlich denselben Namen wie für die Ausgabespalte (count_roles), auch wenn das funktional nicht erforderlich ist.

Damit die Aggregationsfunktion "Anzahl" innerhalb der Aggregation anwendbar ist, muss eine Gruppierung bestellt werden, die wie rechts abgebildet per Feldprojektion das Feld "Benutzername" als einziges Gruppierungskriterium benennt.

Die gewünschte Sortierung verwendet zwei Sortierkriterien:

• Das erste Sortierkriterium reproduziert die Projektion für die erste Ausgabespalte (count_roles). Die Aggregation liefert die Anzahl der Rollen je Benutzer, nach der absteigend (Aufsteigend abgewählt) sortiert werden soll.
  
  

• Das zweite Sortierkriterium reproduziert die zweite Ausgabespalte und greift per Feldprojektion auf das Feld "Benutzername" (username) zu, um Benutzer mit derselben Anzahl von Rollen Aufsteigend zu sortieren.

►ANMERKUNG◄ Die Reihenfolge der Ausgabespalten muss nicht zwingend der Hierarchie der Sortierkriterien entsprechen. Aus technischer Sicht ist es nicht einmal notwendig, dass die in der Sortierung verwendeten Projektionen überhaupt als Ausgabespalten angelegt sind. Es erleichtert allerdings die Interpretation der Ergebnisse.

count_roles,username
====================
5,admin
3,TEST_VIP
2,bcollins
2,fbeutel
2,mpolo
1,ftuscania
1,test
... 

Die Beispieldaten (links) verdeutlichen, dass zunächst absteigend nach dem Ergebnis in der count_roles-Spalte sortiert wird, während die username-Spalte als nachrangiges Sortierkriterium dafür sorgt, dass Benutzer mit derselben Rollen-Anzahl alphabetisch aufsteigend nach dem Benutzernamen sortiert werden.

Wie definiert die Sortierung zwei Sortierkriterien:

• Das erste Sortierkriterium definiert eine Subselect Projektion, die sich nicht etwa auf die Entität "Rolle" bezieht, sondern auf die Entität "Benutzer".
  
  

  • Die Parameter Feld für Join und Feld der Entität für Join beziehen sich jeweils auf das Feld "ID" (id) eines Benutzerkontos, wobei für die Zuordnung von Daten zum Benutzer in der übergeordneten Suche gefordert wird, dass diese IDs übereinstimmen. Das lässt auf den ersten Blick wenig Mehrwert vermuten, da so jedem Benutzerkonto dasselbe Benutzerkonto noch einmal "zugeschlüsselt" wird.
    
    

  • Allerdings ermöglicht diese 1:1-Zuordnung eine Aggregation innerhalb der Spaltenprojektion für Subselect: Per Typ "Anzahl" können wir hier das Zählen der "Rollen" (Feldprojektion roles) je Benutzer-ID veranlassen, was direkt in der übergeordneten Suche mangels "Gruppierung" nicht möglich ist. Der Subselect wird für jede ID in der übergeordneten Suche abgearbeitet. Dabei kann die Aggregationsfunktion "Anzahl" im Subselect alle gefunden Rollen-Werte zusammenzählen, ohne dass eine Gruppierung definiert sein muss. Diese Anzahl kann als Sortierkriterium (count_roles) verwendet werden.
    
    

  • Die Option Aufsteigend ist für dieses Kriterium abgewählt, damit die Benutzerkonten mit absteigender Rollen-Anzahl erscheinen.
    
    

• Als zweites Sortierkriterium dient wie im vorigen Beispiel eine Feldprojektion für das Feld "Benutzername" (username). Benutzern mit derselben Rollen-Anzahl werden nach dem Benutzernamen alphabetisch Aufsteigend sortiert.