Ich habe eine Anwendung, die einige Data-Warehousing-Prinzipien wie Dimensional Modeling verwendet, um Berichte über eine ziemlich einfache Datenbank zu erstellen.
Ein Beispiel (vereinfachtes Element) namens Call sieht folgendermaßen aus:
%Vor%Einige der Eigenschaften des realen Modells wurden entfernt, da sie irrelevant sind. Die vereinfachte DateDimension sieht folgendermaßen aus:
%Vor%Es gibt eine Menge mehr Spalten wie diese - sie sind für die aktuelle Dekade durch Anwendungs-Setup vorbelegt. Jedes Datum im gesamten Jahrzehnt enthält also eine Zeile in dieser Tabelle, und jeder Aufruf hat eine Verknüpfung mit dem Datum, an dem er aufgetreten ist. Dies ist alles in Fluent NHibernate abgebildet und funktioniert gut.
Wenn ich Berichte erstellen möchte, kann ich dies problemlos mit dem verbesserten NHibernate LINQ-Anbieter in 3.0 tun. Wir würden gerne LINQ für die verbesserte Wartbarkeit verwenden, die es uns gibt, aber wenn wir wirklich MÜSSEN, werden wir HQL, ICriteria oder sogar einfaches SQL in Betracht ziehen.
Also sage ich, ich möchte einen Bericht erstellen, der die Anzahl der Anrufe von einer bestimmten Nummer dividiert durch den Wochentag zeigt, an dem sie auftreten. Ich kann das so leicht machen:
%Vor%In diesem Beispiel ist "Calls" im Wesentlichen ein IQueryable, das vom NHibernates LINQ-Provider (Query) über eine Repository-Schnittstelle zurückgegeben wird. Die obige Abfrage gibt mir die richtigen Ergebnisse, NHibernate Profiler zeigt mir, dass das SQL ziemlich optimal ist, alles ist gut.
Wenn ich jedoch etwas etwas Fortgeschritteneres tun möchte, bleibe ich stecken. Angenommen, ich möchte die durchschnittliche Anzahl von Anrufen pro Wochentag. Nicht zu weit von oben, oder? Ich muss nur die Anzahl der eindeutigen Daten herausfinden, die jeder Wochentag in der Ergebnismenge hat, die Gesamtzahl der Anrufe damit teilen, und wir sind alle eingestellt - richtig? Nun, nein, hier fange ich an, die Einschränkungen des NHibernate LINQ-Anbieters zu treffen. Mit LINQ zu Objekten könnte ich eine Abfrage dafür erstellen - etwas in der Art von
%Vor%Dies wird jedoch nicht in die richtige Abfrage konvertiert, wenn Sie es in NHibernate verwenden. Stattdessen werden beide Aufrufe von .Count () oben auf die gleiche Anzahl (*) von Anrufdatensätzen umgestellt, sodass das Ergebnis immer 1 ist.
Ich könnte natürlich nur für jeden Anruf, Wochentag und Datum als neues anonymer Objekt abfragen, dann die Mathe auf der Anwendungsseite, aber nach der herkömmlichen Weisheit, That's Just Wrong (tm). Ich könnte es in Verzweiflung tun, auch wenn es Schmerz bedeutet, wenn der Tisch zu einer Million ++ Anrufe anwächst.
Das Folgende ist eine SQL-Abfrage, die mir das Ergebnis liefert, nach dem ich suche.
%Vor%Ist dies mit dem NHibernate LINQ-Provider möglich? Oder, wenn das nicht möglich ist, wie nah kann ich bekommen, bevor ich die Anwendung das Zwischenergebnis holen lassen muss und den Rest mache?
Es gibt viele Dinge, die Sie mit dem LINQ-Anbieter nicht tun können. Die Verwendung von HQL oder CreateCriteria müssen Sie nur mit NHibernate akzeptieren.
Ich habe es nicht versucht, aber es sieht so aus, als ob Sie in der Lage sein sollten, das zu tun, was Sie mit HQL oder CreateCriteria (mit DetatchedCriteria) machen wollen.
Wenn Sie verzweifelt sind, können Sie auch mit Hilfe von CreateSqlQuery auf SQL zurückgreifen.
Tags und Links sql linq nhibernate linq-to-nhibernate