Ecke83 10 Geschrieben 29. Oktober 2009 Melden Teilen Geschrieben 29. Oktober 2009 Hi, hab grad ein kleines Problem. Ich habe eine Sicht im SQL Server die aus 2 Tabellen die Daten vereint. Dabei möchte ich das die Sicht die Spalten aus der 2. Tabelle dynamisch ausliest, also alle die gerade vorhanden sind und nicht die, die zum Zeitpunkt der Sichterstellung vorhanden waren. Der Einfachheit halber, schreibe ich mal 2 simple Tabellen auf, lässt sich besser erklären Tabelle1 -LfdNr -StammNr -Menge Tabelle2 -LfdNrZuordnung -Name1 -Wert1 -Name2 -Wert2 Die Tabelle2 (ist eigentlich auch schon eine View) kann sich verändern, wenn man im Programm ein neues Objekt anlegt, taucht in Tabelle 2 ein zusätzlich Eintrag auf. Wenn man ein Objekt löscht, verschwindet der Eintrag. So kann es also bis NameN und WertN gehen. Meine View erzeuge ich mit folgendem Befehl: CREAT VIEW Auswertung AS SELECT Tabelle1.StammNr, Tabelle1.Menge, Tabelle2.* FROM Tabelle1 LEFT OUTER JOIN Tabelle2 ON Tabelle1.LfdNr = Tabelle2.LfdNrZuordnung Ich habe dann auch eine Sicht mit den Spalten StammNr, Menge, LfdNrZuordnung, Name1, Wert1, Name2, Wert2. Soweit so gut. Wenn jetzt jemand aber ein neues Objekt anlegt und dadurch in Tabelle2 Name3 und Wert3 hinzukommt, hätte ich gern das in der Sicht die 2 Spalten automatisch mit angefügt werden, ohne das ich das nochmal öffnen/speichern muss. Ich hatte gehofft das Tabelle2.* das macht, aber leider werden nur die Spalten eingefügt die zu diesem Zeitpunkt vorhanden sind. Gibts dafür ein Workaround oder mach ich was falsch. Bzw. versuche ich was unmögliches :) Ich hoffe jemand kann einen Tipp geben Danke schonmal Lg Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 29. Oktober 2009 Melden Teilen Geschrieben 29. Oktober 2009 Moin, wenn ich nicht ganz falsch liege, sollte eine View grundsätzlich durchaus die Dynamik haben, die du dir wünschst. Wenn das in deinem Test nicht funktioniert, könnte das am internen Caching des SQL Server liegen. Das geht auch aus diesem Dokument hervor: CREATE VIEW (Transact-SQL) Dort verstehe ich vor allem diese Passage als relevant: Wenn eine Sicht nicht mit der SCHEMABINDING-Klausel erstellt wurde, sollte sp_refreshview ausgeführt werden, nachdem Änderungen an den der Sicht zugrunde liegenden Objekten vorgenommen wurden, die die Definition der Sicht betreffen. Andernfalls liefert die Abfrage der Sicht möglicherweise unerwartete Ergebnisse. Allerdings ist die Art, wie eure Anwendung mit den Tabellen umgeht (dynamisches Ändern des DB-Schema), alles andere als gutes Design. Es widerspricht den Grundlagen relationaler Datenbanken. Daher wirst du immer wieder auf derartige Probleme und Einschränkungen laufen. Gruß, Nils Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 29. Oktober 2009 Melden Teilen Geschrieben 29. Oktober 2009 Eine View funktioniert immer nur auf dem aktuellen Design der Tabellen. Wenn man am Design der Tabellen was ändert, werden Views meistens ungültig. Aber Design-Änderungen an Tabellen macht man nicht täglich. Der übliche Weg ist ist: SQL Script bauen mit den benötigten Create bze. Alter Table Befehlen. Danach "drop view ..." und "create view.." . Fertig. -Zahni Zitieren Link zu diesem Kommentar
Ecke83 10 Geschrieben 29. Oktober 2009 Autor Melden Teilen Geschrieben 29. Oktober 2009 Naja eine andere Lösung gibt es nicht. Die Objekte an sich werden schon in einer Tabelle in die Tiefe gespeichert, für Auswertungen am Bildschirm braucht man die Daten aber in die Breite zugeordnet zu anderen Objekten. Deshalb habe ich ja ausch geschrieben das Tabelle2 keine Tabelle ist, sondern auch schon eine Sicht, die dafür sorgt das die Daten eben in der Breite erscheinen... Es wäre zu komplex jetzt alles bis ins Detail zu erörtern, aber ich denke das unsere Anwendung sehr gut designt ist :) , wenn man Hintergundwissen hat, würde man verstehen wie es funktioniert, ich habe das Beispiel nur etwas einfache gewählt um mein Problem zu illustrieren Bisher haben wir das Problem umgangen indem wir alle Vies neu erzeugt haben, aber die AuswerteViews sollen nun nicht mehr neu erzeugt werden Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 29. Oktober 2009 Melden Teilen Geschrieben 29. Oktober 2009 Eine View über eine andere View ? Das finde ich auch etwas ungewöhnlich. Man kann mit den richtigen Views jede Menge Daten "in der Breite" (bis es in Excel hinten runterfällt ;) ) anzeigen, ohne ein Tabellen-Design zu ändern. Leider Ist Deine Problemstellung nicht konkrekt genug, um Dir zu helfen. -Zahni Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 29. Oktober 2009 Melden Teilen Geschrieben 29. Oktober 2009 Moin, Eine View über eine andere View ? Das finde ich auch etwas ungewöhnlich. och, das ist gar nicht so ungewöhnlich. Macht man durchaus. Weniger gewöhnlich ist die Dynamik im Schema. Wobei ich an der Stelle, um Caching-Probleme zu umgehen, ggf. eben weiterhin auch die Auswertungs-View dynamisch neu erzeugen würde. Oder man arbeitet ohne View mit dynamisch erzeugten Queries, die werden nicht gecacht. Oder ihr schaut eben, dass ihr nach dem Ändern der zugrundeliegenden View sp_refreshview ausführt. Gruß, Nils Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 29. Oktober 2009 Melden Teilen Geschrieben 29. Oktober 2009 Ich komme eher aus der DB2-Ecke. Da sind Views immer dynamisch, also werden bei Aufruf ausgeführt. Daher finde ich eine Sicht auf eine Sicht etwas seltsam. Für statische resultsets (z.B. Statistiken zu einem bestimmten Termin) gibt es in DB2 MQT's . -Zahni Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 29. Oktober 2009 Melden Teilen Geschrieben 29. Oktober 2009 Moin, das sind unterschiedliche Dinge. Wie gesagt, sind Views auch in SQL Server grundsätzlich dynamisch. Zur Steigerung der Performance cacht SQL Server aber die Definition solcher vordefinierten Objekte (nicht die Daten selbst). Das ist normalerweise kein Problem, wenn man nicht intensiv mit dynamischen Schemata arbeitet. Um den Cache für View-Definitionen zu verwerfen, kann man sp_refreshview nutzen. Es gibt auch etwas Ähnliches wie Views mit statischen Daten (z.B. Indexed Views). Das ist aber eine andere Ecke. Views, die von Views abgeleitet sind, dürften allerdings auch in anderen Datenbanken üblich sein. Unter anderem wird man mit einer View von der Tabelle unabhängig. Oder eine View sucht Daten aus verschiedenen Quellen zusammen und stellt sie über ein Objekt zur Verfügung, das man dann über andere Views nutzt. Usw. usf. Nachteile für die Performance gibt das normalerweise nicht, weil der Query Optimizer solche Szenarien i.d.R. beherrscht. Gruß, Nils Zitieren Link zu diesem Kommentar
Ecke83 10 Geschrieben 30. Oktober 2009 Autor Melden Teilen Geschrieben 30. Oktober 2009 OK, Danke für den Tipp mit sp_refreshview, das war die Lösung. Die View wird mit Tabelle2.* angelegt, wenn man an dieser Tabelle2 (eigtl. ja auch eine View) was ändert muss man danach ein sp_refreshview für die AuswertungsView aufrufen. Danke. Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 30. Oktober 2009 Melden Teilen Geschrieben 30. Oktober 2009 Schön, danke für die Rückmeldung! Gruß, Nils Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.