datenbankseitige Berechnung

[Effie]

Wäre es einfacher/sinnvoller mit Views zu arbeiten?
Ich habe kaum Ahung von Sql, habe nur den Tipp bekommen mit berechneten Spalten arbeiten zu können, weiß aber nun nicht ob das die sinnvollste oder einfachste Lösung ist.
Ich muss nämlich sehr viele Werte aus anderen Werten berechnen lassen

 

[ukulele]

Views sind für Berechnungen sicherlich gut geeignet, vor allem wenn sie über mehrere Tabellen Werte zusammen führen. Ich denke (ohne zu wissen) das in berechneten Spalten tatsächlich auch ein zusätzlicher Wert gespeichert wird, also redundant vorhanden ist. Bei Views ist das nicht der Fall.

 

[Tommi]

Hallo zusammen,

der Unterschied zwischen einer berechneten Spalte und einer View ist der, dass eine Berechnung zu einer Datenzeile in einer View jedesmal bei Abfrage berechnet wird.
In einer berechneten Spalte wird der Wert nur dann neu berechnet, wenn sich innerhalb der Spalte einer der von der Berechnung abhängigen Werte verändert.

Nutzen hiervon ist, dass die Abfrage der Tabelle mit einer berechneten Spalte natürlich performanter ist als bei erneuter Berechnung je Datenzeile in einer View.

Viele Grüße,
Tommi

 

[Effie]

Habs mal mit einer Prozedur versucht
..

Create Procedure calcReqCovScope
@typ int
AS
declare @Zahl1 int,
@Zahl2 int,
@erg int
 
declare o cursor scroll for
select
ReqToCov,
ReqTot
from Base
 
open o
fetch next from o
into @Zahl1, @Zahl2
 
While @@FETCH_STATUS=0
Begin
 
set @erg = @Zahl1+ @Zahl2
 
insert into KPI
(
ReqCovScope
)
select
@erg

nur leider will das immer noch nicht so wirklich funktionieren

 

[Tommi]

Hallo Effie,

eine Berechnung mittels Cursor erscheint mir hier nicht zweckmäßig. Im Detail: ein Curser mit der Bedingen "FOR SELECT" kann kein UPDATE vornehmen und innerhalb der Schleife fehlt ein weiteres FETCH.
Die Nutzung einer Prozedur bedeutet auch, dass diese entweder durch einen Trigger oder einen Zeitplan gestartet werden muss.

Ich stelle mir auch grade die Frage, warum du eine Berechnung in der Tabelle haben möchtest.
Im Regelfall nutzt man tatsächlich eher Views um Berechnungen von Daten vorzunehmen. (Ein View hat auch noch diverse andere Vorteile).
Gibt es einen besonderen Grund, dass die Berechnung in der Tabelle vorgenommen werden soll?
Wenn ja, warum funktionieren die bisher vorgeschlagenen Wege nicht?

Viele Grüße,
Tommi

 

[Effie]

Also ehrlich gesagt... ich hab keine Ahnung, bin in der Ausbildung und Chef sagt ich solls mit einem Trigger lösen ...
Ich habe noch nie wirklich was in sql gemacht, kenn mich also mit vor- und nachteilen von Triggern/berechneten Spalten/ Views wenig aus.

Zu Beginn war meine Aufgabe:
SOBALD wert1 und wert 2 in Tabelle1 gespeichert werden , soll wert3(wert1+wert2) berechnet und auch in Tabelle1 gespeichert werden.
Das habe ich nun also mit Berechneten Spalten umgesetz.

Nächste Aufgabe:
Sobald wert4 und wert5 aus Tabelle1 gespeichert werden, soll wert6(wert4+wert5) in Tabelle2 gespeichert werden.

 

[akretschmer]

Also ehrlich gesagt... ich hab keine Ahnung wie ich das am besten lösen kann, bin in der Ausbildung und Chef sagt ich solls mit einem Trigger versuchen ...
Ich habe noch nie wirklich was in sql gemacht, kenn mich also mit vor- und nachteilen von Triggern/berechneten Spalten/ Views wenig aus.

Zu Beginn war meine Aufgabe:
SOBALD wert1 und wert 2 in Tabelle1 gespeichert werden , soll wert3(wert1+ wert2) berechnet und auch in Tabelle1 gespeichert werden.
Das habe ich nun also mit Berechneten Spalten umgesetz.

Das ist, soweit ich M$SQL verstehe, so korrekt

Nächste Aufgabe:
Sobald wert4 und wert5 aus Tabelle1 gespeichert werden, soll wert6(wert4+wert5) in Tabelle2 gespeichert werden.

Da dies eine andere Tabelle betrifft, denke ich, wirst Du einen TRIGGER brauchen, der das da einträgt.

Ich bin aber nach wie vor der Meinung, daß da jede Menge Redundanz entsteht, was nicht gut ist. Sowohl bei der 'berechneten Spalte', als auch bei einer via TRIGGER gepflegten Spalte.


Andreas

 

[Effie]

Was kann ich denn anders machen, um diese Redundanz zu verhindern?

 

[ukulele]

Dann musst du theoretisch zwei Trigger für tabelle1 erstellen. Einen AFTER Trigger der nach UPDATE und INSERT in der Tabelle INSERTED guckt, ob beide Werte gegeben sind (nicht NULL) und das Ergebnis in tabelle2 schreibt. Und einen AFTER Trigger, der bei einem DELETE in der Tabelle DELETED guckt welcher Wert betroffen ist und diesen ggf. löscht. Natürlich kann letzteres auch entfallen (falls nicht gelöscht wird) oder geschickt in den ersten Trigger eingbaut werden.

INSERTED und DELETED sind "Systemtabellen" die nur innerhalb des Triggers abgefragt werden können und nur einen Datensatz, nämlich den Neuen und den Alten zurück geben.

 

[ukulele]

Redundanz vermeidest du nur über eine View.

 

[Tommi]

Da es sich ja hier um eine Aufgabenstellung handelt, die ein Prinzip verdeutlichen soll, ist das mit der Redundanz sicher vernachlässigbar.
Aber wenn ein Wert aus Spalten einer Tabelle fest berechnet und in einer anderen Tabelle eingetragen werden soll, ist das nur mit einem Trigger zu lösen.

VG
Tommi