Ich habe eine Tabelle mit Daten, die einmal pro Woche aktualisiert werden. Ich habe dann eine Abfrage, die diese Daten verarbeitet und im Wesentlichen eine Liste von Codes und die Anzahl der Stunden, die für diese Codes gebucht wurden, zurückgibt. Diese Abfrage ist relativ kompliziert und dauert etwa 5 Sekunden.
Diese Daten müssen von vielen anderen Abfragen in der DB verwendet werden, also möchte ich sie irgendwo platzieren, dass sie von anderen Abfragen leicht zugänglich sind. Dies zu tun, schien eine gute Idee zu sein, aber das bedeutet, dass jedes Mal, wenn diese Ansicht aufgerufen wird, diese Abfrage erneut ausgeführt wird, was 5 Sekunden dauert, wenn es viele Aufrufe auf einmal gibt App zu verlangsamen.
So dachte ich, wäre es besser, diese Ansicht als Tabelle zu erstellen, wenn die Daten an einem Montag importiert werden, da dies die einzige Änderung ist. Ist das die beste Idee, oder sehe ich das falsch an?
Ich beschäftige mich mit den gleichen Problemen mit den meisten meiner Projekte.
Wir haben zahlreiche Daten, die für verschiedene Zwecke neu organisiert werden müssen. Darüber hinaus profitieren wir von einer Unternehmenskultur, die für Batch-Jobs und Overnight-Prozesse verwendet wird, so dass die Benutzer über die Datenschnappscharfe gut informiert sind. Die meisten Benutzer müssen die Daten nach Excel exportieren
Die Verwendung zusätzlicher Tabellen ist ein sinnvoller Weg, um hierher zu kommen.
Persönlich gebe ich diesen Tabellen einen Unterstrich voran.
%Vor%Dies erlaubt mir, bequem Tabellen von Entitäten zu identifizieren, die eine aktive Rolle im normalen Betrieb des Systems spielen.
Ein Kollege wies mich auf "Materialized Views" hin.
Sie kopieren Daten aus einer Sicht in eine Tabelle und verwenden diese Tabelle als Sicht. Der Punkt in dieser Präsentation (Link) ist, dass Sie mit Triggern und Funktionen arbeiten können, um nur einige Teile dieser Tabelle zu aktualisieren.
Sehr nützlich, ich habe eine solche materialisierte Ansicht in SQL Server implementiert.
Klingt nach einem vernünftigen Weg.
Da die Abfrage teuer ist, klingt das Veröffentlichen der Ergebnisse in einer "Bericht" -Tabelle, die von anderen Anwendungen verwendet werden soll, wie ein guter Kompromiss.
Solange die Benutzer dieser Daten damit zufrieden sind, sich so zu ändern, wie Sie es beschreiben, ist Ihr Ansatz in Ordnung.
Wenn Ihre Ansichtsstruktur es ermöglicht, sie zu indizieren, können Sie eine indizierte Sicht erstellen (die eigentlich nur eine Kopie der Daten ist, die aktualisiert werden, wenn die zugrunde liegenden Tabellen aktualisiert werden).
Nicht jede Abfrage ermöglicht jedoch die Indexierung einer Ansicht darüber.
Wenn Ihre Daten keine Sekunde-zu-Sekunde-Istwerte sind, dann ist das Erstellen einer Tabelle OK .
Sie "sehen" immer noch Ihre Zeilen, egal ob in einer Tabelle oder in einer Ansicht der Tabellenzeilen.
Ich würde zuerst versuchen, Ihre Abfrage zu optimieren (schlagen Sie Ihre Indizes, vielleicht hinzufügen / aktualisieren / ändern Sie Ihre Indizes) und führen Sie es durch einen Profiler. Profiler bieten einen wunderbaren Einblick ... in den Entscheidungsplan Ihrer Datenbank.
Ich habe ähnliche Probleme in meinem Produktions-Support gesehen, wo ich mit einem großen Datawarehouse umgehen muss. Im Grunde genommen habe ich Tabellen mit einem Shell-Skript erstellt. Das Shell-Skript läuft folgendermaßen ab:
All dies kann mithilfe eines einfachen Shell-Skripts erfolgen. Ich fand es sehr nützlich und auch jetzt läuft es effektiv.
Tags und Links sql sql-server-2008 views