Ansicht oder gespeicherte Prozedur für komplexe Abfragen?

Question

Ich habe eine etwas komplexe Abfrage mit mehreren (verschachtelten) Untergräben, die ich für die Anwendungsentwickler zur Verfügung stellen möchte. Die Abfrage ist generisch und generiert eine Ansicht mit berechneten Werten über eine Sammlung von Datensätzen, und der Entwickler wird erwartet, dass nur einige Datensätze aus der Rückgabe der Abfrage benötigt werden (dh sie beschränken das Ergebnis für die ID eines Unternehmens oder einen Datumsbereich oder einige eine solche).

Ich kann 3 Möglichkeiten sehen, dies zu implementieren:

1. Lassen Sie die Entwickler die Abfrage in jede Anwendung einbetten und ihre eigenen hinzufügen WHERE Klauseln nach Bedarf.
2. Erstellen Sie ein gespeichertes Verfahren, das alle Bedingungen als Parameter anerkennt gemäß den übergebenen Parametern.
3. Implementieren Sie die Abfrage als Ansicht mit mehreren Sub-Ansichten (da MySQL unter den Ansichten nicht zulässt) und lassen Sie die Entwickler diese als Tabelle und Verwendung verwenden WHERE Damit jede Anwendung die von ihnen benötigten Filter anwendet. Derzeit schaue ich mir 3 zusätzliche Unteransichten an, vor allem, weil einige Untergrenze mehrmals verwendet werden und sie als Unteransichten zur Doppelarbeit verhindert-sonst hätte es schlechter sein können ;-).

Was wird besser Leistung sein? (Angenommen, die gesamte Indizierung ist in allen Fällen gleichwertig.) Geben Sie sich für die schlimmsten Szenarien ein, wenn Sie können.

Was wird in Code -Wartungsgründen besser sein, denken Sie?

Answer 1

Ich mag Fragen, die "gut" definieren - Sie haben speziell nach Leistung und Wartbarkeit gefragt, die Antworten über diesen Kompromiss sprechen.

Aus Sicht der Leistung denke ich nicht, dass es wahrscheinlich einen Unterschied zwischen den drei Optionen gibt, solange die Abfragen und Daten in Ihre erwarteten Szenarien passen. Ich würde mit 100 -mal mehr Daten testen und die "Wo" -Klaus anzeigen oder aus einer Client -Anwendung.

Der beste Weg, um diese Frage zu beantworten, besteht darin, sie zu testen - es gibt natürlich viele spezifische Details, die die allgemeinen "Ich würde x, y oder z" -Antworten ungültig machen, die wir überlaufen können. Wenn die Leistung ein kritisches Problem darstellt, verwenden Sie ein Datenbank -Füllwerkzeug (Redgate Make on, ich habe in der Vergangenheit DBMonster verwendet) und probieren Sie alle drei Optionen aus.

Aus Wartungspunkt, Ansicht, würde ich eine Option 4 anbieten, die - meiner Ansicht nach - bei weitem das Beste ist.

Option 4: Erstellen Sie eine Datenzugriffsbibliothek, die den Zugriff auf Ihre Daten zusammenfasst. Lassen Sie die Bibliothek Methoden und Parameter freisetzen, um die Auswahl von Datensätzen zu verfeinern. Erwägen Sie, das Spezifikationsmuster (http://en.wikipedia.org/wiki/specification_pattern) zu verwenden. Verwenden Sie alle Abfragen in der Bibliothek, und stören Sie die Entwickler nicht mit den Implementierungsdetails.

Wenn das nicht funktioniert - heterogener Anwendungscode, zu viel Änderung für eine einfache Anforderung - würde ich die Optionen wie folgt bewerten:

1. Eingebetteter SQL: Abhängig von der Häufigkeit, mit der dieser SQL wiederverwendet wird, kann dies in Ordnung sein. Wenn es nur einen Teil des Codes gibt, der die SQL ausführt, ähnelt er der Datenzugriffsbibliothek logischerweise. Wenn das gleiche Snippet jedoch an vielen Stellen wiederverwendet werden muss, ist es eine wahrscheinliche Quelle für Fehler - eine kleine Änderung des SQL müsste an mehreren Stellen wiederholt werden.

2. Speichernde Verfahren: Ich mag gespeicherte Verfahren aus Wartungsgründen im Allgemeinen nicht - sie werden in der Regel durch Überladung spröde und schaffen eine prozedurale Denkweise. Wenn Sie beispielsweise andere Anforderungen an die Verwendung dieser SQL -Berechnung in einem separaten gespeicherten Verfahren haben, haben Sie sehr schnell ein prozedurales Programmiermodell, wobei gespeicherte Procs sich gegenseitig aufrufen.

3. Ansichten: Dies ist wahrscheinlich die beste Wahl. Es wird die spezifische Datenlogik an einem einzigen Ort gestellt, fördert jedoch die Verwendung von SET-basierter Logik, da die Zugriffsroute über eine SELECT-Anweisung statt durch Ausführung einer Verfahrensanweisungen erfolgt. Ansichten sind leicht in andere Fragen einzubeziehen.

Answer 2

Wenn sie gut implementiert werden, wäre eine der drei Lösungen für die Manteinanz in Ordnung, aber denken Sie daran, wie Sie jeden von ihnen in einem Migrationsprozess (Code oder Datenbankmigration) behandeln würden.

Wenn die Abfrage groß ist Leistung Aufgrund weniger Bande mit Overhead, weil es eine kleinere Anfrage sendet. Mit dieser Lösung können Sie auch ein wenig mehr Sicherheit erhalten.

Für ein Manteinanz Lösung, ich würde die 1. und 2. Lösung bevorzugen, weil Sie Änderungen an der Abfrage vornehmen können, ohne Datenbankänderungen vorzunehmen. Wenn Sie die 1. Lösung auswählen, würde ich den Abfrageanruf in eine Funktion einwickeln, damit Sie nur einen Ort haben, an dem Sie Änderungen vornehmen können.

Von einem Entwickler Standpunkt, Ich würde die View -Lösung auswählen, weil es die transparenteste ist. Ich meine, es ist wie eine reguläre Tabelle, Sie können die Tabellenstruktur mit einem Beschreibungsbefehl überprüfen oder einfach die Felder und Bedingungen auswählen, die Sie zum Abfragen benötigen, oder mit einem anderen verbinden Tabelle usw. ...

Über die Wo Klausel Flexibilität, Sie können es mit einer der vorgeschlagenen Lösungen erreichen. Sie können einen Where -Parameter in Ihrer Wraping -Funktion (1) hinzufügen, dem gespeicherten Verfahren einen Where -Parameter hinzufügen, aber mit Injektionen (2) vorsichtig sein, oder der Entwickler kann eine Where -Klausel wie gewohnt mit der Ansicht (3) hinzufügen.

Beachten Sie, dass in MySQL Ansichten keine temporären Tabellen sind, Wenn die Abfrage sehr komplex ist Diese Lösungen wären nicht die beste, wenn die Abfrage viel und auf unterschiedliche Weise verwendet würde (Deaktivieren von Cache -Leistungsteigerungen). Ich würde eine temporäre Tabelle in Betracht ziehen Lösung (Zählertabelle), die jeden Zeitraum mit einer programmierten Aufgabe / einem Cron (z. Diese Lösung könnte die Leistung erheblich verbessern.

Ich hoffe, das hilft, ich mag die View -Lösung am meisten, aber vielleicht ist es komplexer, sich aus einer Datenbank -Sicht zu entwickeln.