Ich überlege, eine Tabelle mit einer berechneten Spalte in Microsoft SQL Server 2008 zu entwerfen. Es wäre eine einfache Berechnung wie (ISNULL (colA, (0)) + ISNULL (colB, (0))) - wie eine Summe . Unsere Anwendung verwendet Entity Framework 4.
Ich bin nicht vollständig mit berechneten Spalten vertraut, daher bin ich neugierig, was andere darüber zu sagen haben, wenn sie angemessen sind, im Gegensatz zu anderen Mechanismen, die das gleiche Ergebnis erzielen, wie Ansichten oder eine berechnete Entity-Spalte .
Gibt es Gründe, warum ich eine berechnete Spalte in einer Tabelle nicht verwenden möchte?
Wenn ich eine berechnete Spalte verwende, sollte sie beibehalten werden oder nicht? Ich habe über verschiedene Leistungsergebnisse gelesen, indem ich persistent, nicht persistent, mit indizierten und nicht indizierten berechneten Spalten verwendet habe hier . Angesichts der Tatsache, dass meine Berechnungen einfach zu sein scheinen, möchte ich sagen, dass es nicht beibehalten werden sollte.
Nehmen wir an, Sie haben eine berechnete Spalte namens "ProspectRanking", die das Ergebnis der Auswertung der Werte in mehreren Spalten ist: ReadingLevel, AnnualIncome, Gender, OwnsBoat, HasPurchasedPremiumGasolineRecently.
Sagen wir auch, dass viele dezentrale Abteilungen in Ihrem großen Mega-Konzern diese Daten nutzen und alle ihre eigenen Programmierer haben, aber Sie wollen, dass die Algorithmen von ProspectRanking zentral von der IT in der Unternehmenszentrale verwaltet werden und eine enge Kommunikation pflegen mit dem VP des Marketings. Lassen Sie uns auch sagen, dass der Algorithmus häufig angepasst wird, um sich ändernde Bedingungen wie den Zinssatz oder die Inflationsrate widerzuspiegeln.
Sie möchten, dass die Berechnung Teil der Back-End-Datenbank-Engine und nicht der Client-Consumer der Daten ist, wenn die Verwaltung der Front-End-Clients wie das Hüten von Katzen wäre.
Wenn Sie vermeiden können, Katzen zu hüten, tun Sie das.
Ich überlege, eine Tabelle mit einer berechneten Spalte in Microsoft SQL Server 2008 zu entwerfen. Es wäre eine einfache Berechnung wie (ISNULL (colA, (0)) + ISNULL (colB, (0))) - wie eine Summe . Unsere Anwendung verwendet Entity Framework 4.
Ich bin nicht vollständig mit berechneten Spalten vertraut, daher bin ich neugierig, was andere darüber zu sagen haben, wenn sie angemessen sind, im Gegensatz zu anderen Mechanismen, die das gleiche Ergebnis erzielen, wie Ansichten oder eine berechnete Entity-Spalte .
Gibt es Gründe, warum ich eine berechnete Spalte in einer Tabelle nicht verwenden möchte?
Wenn ich eine berechnete Spalte verwende, sollte sie beibehalten werden oder nicht? Ich habe über verschiedene Leistungsergebnisse gelesen, indem ich persistent, nicht persistent, mit indizierten und nicht indizierten berechneten Spalten verwendet habe hier . Angesichts der Tatsache, dass meine Berechnungen einfach zu sein scheinen, möchte ich sagen, dass es nicht beibehalten werden sollte.
Meiner Erfahrung nach sind sie am nützlichsten / geeignet, wenn sie an anderen Stellen wie einem Index oder einer Prüfbedingung verwendet werden können, was manchmal erfordert, dass die Spalte beibehalten wird (physisch in der Tabelle gespeichert wird). Weitere Informationen finden Sie unter Berechnete Spalten und Erstellen von Indizes für berechnete Spalten .
Stellen Sie sicher, dass nur Spalten angefordert werden, die Sie benötigen
Ich habe festgestellt, dass die Verwendung von berechneten Spalten sehr nützlich ist, auch wenn sie nicht beibehalten werden, insbesondere in einem MVVM-Modell, in dem Sie nur die Spalten erhalten, die Sie für diese bestimmte Ansicht benötigen. Solange Sie keine Logik einsetzen, die im berechneten Spaltencode weniger leistungsfähig ist, sollten Sie in Ordnung sein. Die untere Zeile ist für diejenigen, die berechnet werden (nicht persistent Spalten) müssen nach sowieso gesucht werden, wenn Sie diese Daten verwenden.
Wenn es um Leistung geht
Für die Leistung können Sie die Abfrage auf die Zeilen und die berechneten Spalten eingrenzen. Wenn Sie der berechneten Spalte einen Index hinzufügen (wenn das zulässig ist Geprüft und nicht zulässig ), wäre ich vorsichtig, da die Ausführungs-Engine diesen Index möglicherweise verwenden und die Leistung durch Berechnung dieser Spalten beeinträchtigen würde . Die meiste Zeit erhältst du nur einen Namen oder eine Beschreibung von einer Join-Tabelle, also denke ich, dass das in Ordnung ist.
Brute es nicht brutal
Der einzige Zeitpunkt, an dem es nicht sinnvoll wäre, viele berechnete Spalten zu verwenden, ist die Verwendung einer einzelnen Ansichtsmodellklasse, die alle Daten in allen Spalten erfasst, einschließlich der berechneten. In diesem Fall wird sich Ihre Leistung aufgrund der Anzahl berechneter Spalten und der Anzahl der Zeilen in Ihrer Datenbank, von der Sie auswählen, verschlechtern.
Berechnete Spalten für ORM funktioniert großartig.
Mit einem objektrelationalen Mapper wie EntityFramework können Sie eine Teilmenge der Spalten in Ihrer Abfrage abfragen. Dies funktioniert besonders gut mit LINQ to EntityFramework. Durch die Verwendung der berechneten Spalten müssen Sie Ihre ORM-Klasse nicht mit zugeordneten Ansichten für jeden der Modelltypen überladen.
%Vor%Nur die ID und der Name werden abgefragt.
%Vor%Unter der Annahme, dass der Abteilungsname eine berechnete Spalte ist, erhalten Sie Ihre Berechnung für die letztere Abfrage ausgeführt.
Peformance Profiler
Wenn Sie einen Performance-Profiler verwenden und nach SQL-Abfragen filtern, können Sie sehen, dass die berechneten Spalten tatsächlich ignoriert werden, wenn sie nicht in der SELECT-Anweisung enthalten sind.
Berechnete Spalte ist eine Geschäftsregel, und es ist angemessener, sie auf dem Client und nicht im Speicher zu implementieren. Die Datenbank dient zum Speichern / Abrufen von Daten, nicht zur Verarbeitung von Geschäftsregeln. Die Tatsache, dass es etwas tun kann, bedeutet nicht, dass Sie es so machen sollten. Du bist auch frei von Eiffel zu springen, aber es wird eine schlechte Entscheidung sein :)
Berechnete Spalten können angemessen sein, wenn Sie nach diesen Informationen abfragen möchten.
Zum Beispiel, wenn Sie eine Datenmenge haben, die Sie in der Benutzeroberfläche präsentieren werden. Wenn Sie eine berechnete Spalte verwenden, können Sie die Ansicht blättern, während Sie immer noch die berechnete Spalte sortieren und filtern können. Wenn diese berechnete Spalte nur Code enthält, ist es wesentlich schwieriger, das Dataset basierend auf diesem Wert angemessen zu sortieren oder zu filtern.
Wenn Ihre berechnete Spalte nicht beibehalten wird, wird sie jedes Mal berechnet, wenn Sie in z. ein Code%. Wenn die Daten, auf denen es basiert, häufig geändert werden, kann das in Ordnung sein.
Wenn sich die Daten nicht häufig ändern, z. Wenn Sie eine berechnete Spalte haben, um Ihr numerisches %code% in ein menschenlesbares %code% oder etwas ähnliches zu verwandeln, dann lassen Sie Ihre berechnete Spalte definitiv bestehen - in diesem Fall wird der Wert berechnet und physisch auf dem Datenträger gespeichert Jeder nachfolgende Zugriff darauf ist wie das Lesen einer anderen Spalte auf Ihrem Tisch - keine erneute Berechnung immer und immer wieder.
Wir sind auch dazu gekommen, berechnete Spalten zu verwenden (und hoch zu schätzen!), um bestimmte Informationen aus XML-Spalten zu extrahieren und sie in der Tabelle als separate (persistente) Spalten anzuzeigen. Das macht Abfragen gegen diese Elemente nur viel effizienter, als ständig mit XQuery in das XML zu stochern, um die Informationen abzurufen. Für diesen Anwendungsfall halte ich persistierte berechnete Spalten für eine großartige Möglichkeit, um Ihre Abfragen zu beschleunigen!
Wenn Ihre berechnete Spalte nicht beibehalten wird, wird sie jedes Mal berechnet, wenn Sie in z. ein Code%. Wenn die Daten, auf denen es basiert, häufig geändert werden, kann das in Ordnung sein.
Wenn sich die Daten nicht häufig ändern, z. Wenn Sie eine berechnete Spalte haben, um Ihr numerisches SELECT in ein menschenlesbares OrderID INT oder etwas ähnliches zu verwandeln, dann lassen Sie Ihre berechnete Spalte definitiv bestehen - in diesem Fall wird der Wert berechnet und physisch auf dem Datenträger gespeichert Jeder nachfolgende Zugriff darauf ist wie das Lesen einer anderen Spalte auf Ihrem Tisch - keine erneute Berechnung immer und immer wieder.
Wir sind auch dazu gekommen, berechnete Spalten zu verwenden (und hoch zu schätzen!), um bestimmte Informationen aus XML-Spalten zu extrahieren und sie in der Tabelle als separate (persistente) Spalten anzuzeigen. Das macht Abfragen gegen diese Elemente nur viel effizienter, als ständig mit XQuery in das XML zu stochern, um die Informationen abzurufen. Für diesen Anwendungsfall halte ich persistierte berechnete Spalten für eine großartige Möglichkeit, um Ihre Abfragen zu beschleunigen!
Nehmen wir an, Sie haben eine berechnete Spalte namens "ProspectRanking", die das Ergebnis der Auswertung der Werte in mehreren Spalten ist: ReadingLevel, AnnualIncome, Gender, OwnsBoat, HasPurchasedPremiumGasolineRecently.
Sagen wir auch, dass viele dezentrale Abteilungen in Ihrem großen Mega-Konzern diese Daten nutzen und alle ihre eigenen Programmierer haben, aber Sie wollen, dass die Algorithmen von ProspectRanking zentral von der IT in der Unternehmenszentrale verwaltet werden und eine enge Kommunikation pflegen mit dem VP des Marketings. Lassen Sie uns auch sagen, dass der Algorithmus häufig angepasst wird, um sich ändernde Bedingungen wie den Zinssatz oder die Inflationsrate widerzuspiegeln.
Sie möchten, dass die Berechnung Teil der Back-End-Datenbank-Engine und nicht der Client-Consumer der Daten ist, wenn die Verwaltung der Front-End-Clients wie das Hüten von Katzen wäre.
Wenn Sie vermeiden können, Katzen zu hüten, tun Sie das.
Stellen Sie sicher, dass nur Spalten angefordert werden, die Sie benötigen
Ich habe festgestellt, dass die Verwendung von berechneten Spalten sehr nützlich ist, auch wenn sie nicht beibehalten werden, insbesondere in einem MVVM-Modell, in dem Sie nur die Spalten erhalten, die Sie für diese bestimmte Ansicht benötigen. Solange Sie keine Logik einsetzen, die im berechneten Spaltencode weniger leistungsfähig ist, sollten Sie in Ordnung sein. Die untere Zeile ist für diejenigen, die berechnet werden (nicht persistent Spalten) müssen nach sowieso gesucht werden, wenn Sie diese Daten verwenden.
Wenn es um Leistung geht
Für die Leistung können Sie die Abfrage auf die Zeilen und die berechneten Spalten eingrenzen. Wenn Sie der berechneten Spalte einen Index hinzufügen (wenn das zulässig ist Geprüft und nicht zulässig ), wäre ich vorsichtig, da die Ausführungs-Engine diesen Index möglicherweise verwenden und die Leistung durch Berechnung dieser Spalten beeinträchtigen würde . Die meiste Zeit erhältst du nur einen Namen oder eine Beschreibung von einer Join-Tabelle, also denke ich, dass das in Ordnung ist.
Brute es nicht brutal
Der einzige Zeitpunkt, an dem es nicht sinnvoll wäre, viele berechnete Spalten zu verwenden, ist die Verwendung einer einzelnen Ansichtsmodellklasse, die alle Daten in allen Spalten erfasst, einschließlich der berechneten. In diesem Fall wird sich Ihre Leistung aufgrund der Anzahl berechneter Spalten und der Anzahl der Zeilen in Ihrer Datenbank, von der Sie auswählen, verschlechtern.
Berechnete Spalten für ORM funktioniert großartig.
Mit einem objektrelationalen Mapper wie EntityFramework können Sie eine Teilmenge der Spalten in Ihrer Abfrage abfragen. Dies funktioniert besonders gut mit LINQ to EntityFramework. Durch die Verwendung der berechneten Spalten müssen Sie Ihre ORM-Klasse nicht mit zugeordneten Ansichten für jeden der Modelltypen überladen.
%Vor%Nur die ID und der Name werden abgefragt.
%Vor%Unter der Annahme, dass der Abteilungsname eine berechnete Spalte ist, erhalten Sie Ihre Berechnung für die letztere Abfrage ausgeführt.
Peformance Profiler
Wenn Sie einen Performance-Profiler verwenden und nach SQL-Abfragen filtern, können Sie sehen, dass die berechneten Spalten tatsächlich ignoriert werden, wenn sie nicht in der SELECT-Anweisung enthalten sind.
Berechnete Spalten können angemessen sein, wenn Sie nach diesen Informationen abfragen möchten.
Zum Beispiel, wenn Sie eine Datenmenge haben, die Sie in der Benutzeroberfläche präsentieren werden. Wenn Sie eine berechnete Spalte verwenden, können Sie die Ansicht blättern, während Sie immer noch die berechnete Spalte sortieren und filtern können. Wenn diese berechnete Spalte nur Code enthält, ist es wesentlich schwieriger, das Dataset basierend auf diesem Wert angemessen zu sortieren oder zu filtern.
Berechnete Spalte ist eine Geschäftsregel, und es ist angemessener, sie auf dem Client und nicht im Speicher zu implementieren. Die Datenbank dient zum Speichern / Abrufen von Daten, nicht zur Verarbeitung von Geschäftsregeln. Die Tatsache, dass es etwas tun kann, bedeutet nicht, dass Sie es so machen sollten. Du bist auch frei von Eiffel zu springen, aber es wird eine schlechte Entscheidung sein :)
Tags und Links sql sql-server entity-framework sql-server-2008