Gespeicherte Prozedur oder Berechnungen über IQueryable?

Question

Dies ist eine Frage, die auf der Auswahl der Leistung gegenüber den Designpraktiken basiert. Wenn ich eine Methode habe, die viele Male pro Sekunde ausgeführt wird;

public static IQueryable<IPerson> InRadius(this IQueryable<IPerson> query, Coordinate center, double radius) 
{ 
    return (from u in query 
      where CallHeavyMathFormula(u, center, radius) 
      select u); 
} 

Diese Erweiterungsmethode für IQueryable erzeugt eine SQL, die einige schwere Mathematik Berechnung bedeutet (Kosinus Sinus usw.). Dies würde bedeuten, dass die Anwendung 1-2 KB SQL an den Server pro Aufruf sendet.

Ich habe von der Platzierung aller Anwendungslogik in Ihrer Anwendung gehört. Ich möchte auch in Zukunft auf eine Datenbank wie azure oder eine dieser skalierbaren Datenbanken wechseln. Wie gehe ich mit so etwas um? Soll ich es so lassen wie es jetzt ist oder gespeicherte Prozeduren schreiben? Wie machen Anwendungen wie Twitter oder Facebook das?

Answer 1

Stored Procedure-Sprachen neigen dazu, Sie eng an einen bestimmten Anbieter oder ein Produkt zu binden. Berücksichtigen Sie die Möglichkeit, dass Sie neu schreiben müssen, wenn Sie die Migration in der Zukunft planen.

Mit diesem gesagt, ich denke, eine solche Entscheidung hängt von anderen Faktoren ab, wie ob es erfordert, dass viele Daten aus einer Datenbank in den Speicher verschoben werden müssen. Wie viele Daten; wie viel Speicher; Wie viele Bytes auf dem Draht hin und her? Dies sind die Dinge, die Sie senden müssen.

1-2KB pro Datenbank-Anruf klingt nicht viel nach mir.

Ich würde nicht in Betracht ziehen, Sinus und Kosinus schwere Mathematik zu berechnen. Eine dynamische FFT- oder lineare Algebra-Lösung wäre weitaus schwieriger. Nichts, was ich als schwer bezeichnen würde, würde mehrmals pro Sekunde ausgeführt werden.

Es klingt für mich, als ob Sie sicher wären, diese Berechnung auf der Anwendungsseite zu behalten.

Answer 2

Erstens kann es in Abhängigkeit von der verwendeten Datenbank Ausführungspläne und Ergebnisse für gespeicherte Prozeduren und Ad-hoc-Abfragen zwischenspeichern. Dies sollte der Hauptgrund sein, in Code vs gespeicherte Prozedur zu gehen. Sie könnten auch in der Lage sein, eine .net-Funktion innerhalb von sql zu verwenden, um einen Teil der Bedingung als .net-Code zu behalten (zu schwer, um als sql usw. zu schreiben). Dann statt db zu oft zu drücken, würde ich versuchen, Ergebnisse zu cachen .

Es ist keine Sünde, in einer Anwendung sowohl gespeicherte Prozeduren (hauptsächlich für komplexe Abfragen, wo SP eine große Verbesserung schaffen würde) als auch Ad-hoc-Code durch iqueriable zu haben.

Die Verwendung des SQL Profiler könnte Ihnen auch bei der Entscheidung für die beste Lösung helfen.

Und solange Sie nicht die Migration zu einer anderen db auf dem Plan für die nähere Zukunft haben oder wenn es nur ein "möglich ist", ignorieren Sie es für jetzt, ziehen Sie es später als Teil des notwendigen Refactoring bei dieser Moment.