Wir haben Bestellungen, die "verursachte_Ordnung" -Kanten von Bestellung zu Bestellung enthalten, weil Freunde andere Freunde dazu bewegen können, Einkäufe zu tätigen. Wir wissen aus den Links, die wir für die Freunde generieren, dass Order ID 42 Order ID 47 verursacht hat, also erstellen wir eine Kante "created_order" zwischen den beiden Order-Knoten.OrientDB Quersumme und Gruppe nach oberstem Datensatz
Wir suchen nach den Personen, die das am meisten empfohlene Geschäft generieren. Im Moment durchlaufen wir nur C# und finden es heraus, weil unsere Datensätze relativ klein sind. Aber ich würde gerne herausfinden, ob es eine Möglichkeit gibt, stattdessen Traverse SQL zu verwenden.
Das Problem, in das ich renne, ist eine genaue Zählung/Summe für jede Originalauftrags-ID.
sich das folgende Szenario:
Auftrag 42 vier weitere Aufträge verursacht, einschließlich Bestellung 47. Bestellung 47 2 weitere Aufträge verursacht. Und Befehl 51, unabhängig von 42 oder 47, verursachte 3 Befehle.
kann ich die folgende SQL ausführen, um die besten Referrer für diese spezifische bekommen {ProductId}:
select in_caused_order[0].id as OrderID, count(*) as ReferCount, sum(amount) as ReferSum
from (traverse out('caused_order') from Order)
where out_includes.id = '{ProductId}' and $depth >= 1
group by in_caused_order[0].id
EDIT: das Schema ein wenig komplexer als das ist, ich war darunter nur die out_includes WHERE Klausel, um zu zeigen, dass die Orders etwas gefiltert werden. Aber es ist ein bisschen wie:
Product(V) <-- includes(E) <-- Order(V) --> caused_order(E) --> Order(V)
(the Order vertex has "amount" as a property, which stores the money spent and is being SUM'd in the SELECT, along with a few fields like date which aren't important)
Aber das wird wie in etwas führen:
OrderID | ReferCount | ReferSum
42 | 4 | 525
47 | 2 | 130
51 | 3 | 250
Abgesehen davon, dass nicht ganz richtig ist, oder? Weil Order 42 auch technisch die beiden 47 Bestellungen verursacht hat. So würden wir etwas wie sehen möchten:
OrderID | ReferCount | ReferSum | ExtendedCount | ExtendedSum
42 | 4 | 525 | 2 | 130
47 | 2 | 130 | 0 | 0
51 | 3 | 250 | 0 | 0
Ich erkenne, dass die beiden "Extended" count/sum Spalten möglicherweise knifflig sein. Wir müssen die Abfrage möglicherweise zweimal ausführen, einmal mit $ depth = 1 und erneut mit $ depth> 1, und dann die Ergebnisse dieser beiden Abfragen in C# zusammenfassen, was in Ordnung ist.
Aber ich kann nicht einmal herausfinden, wie man die Gesamtsumme richtig berechnet. Der erste Schritt wäre auch wie etwas zu sehen sein:
OrderID | ReferCount | ReferSum
42 | 6 | 635 <-- includes its 4 orders + 47's 2 orders
47 | 2 | 130
51 | 3 | 250
Und da diese n-Ebene tief sein kann, es ist nicht wie kann ich irgendwie tun in_caused_order.in_caused_order.in_caused_order nur in der SQL, ich weiß nicht, Wie viel tief wird das gehen? Auftrag 83 könnte durch Auftrag 47 verursacht werden und Auftrag 105 könnte durch Auftrag 83 verursacht werden, und so weiter.
Jede Hilfe würde sehr geschätzt werden. Oder vielleicht ist die Antwort, Traverse kann damit nicht umgehen, und wir müssen etwas völlig anderes herausfinden.
Ich würde gerne helfen, aber Ihre Domain ist mir nicht klar. Was ist out_includes? Könnten Sie ein Diagramm anfügen, das Beziehungen und Attribute erklärt? – Lvca
@Lvca hi, es ist nur eine Out-Kante zum Produkt-Vertex (was eine Vereinfachung unseres Schemas ist, aber ich wollte zeigen, dass es dort auch eine WHERE-Klausel gibt, um zu filtern welche Bestellungen wir auswählen). Ich habe den Beitrag aktualisiert, danke! –