View mit variabler Basistabelle

[Bernhard Geyer]

Folgendes Problem:

Ich habe meine zu verarbeitenden Daten in Tabellen der Art Results_XXXX, wobei XXXX ein Zähler ist der mir sagt, um welche Art von Ergebnis es sich handelt. Auf diese Tabelle basiert eine View-Hiararchie der Art:

CREATE VIEW V_View1
AS SELECT * FROM Results_XXX WHERE .... (Komplexe SQL-Anweisung)

CREATE VIEW V_View2
AS SELECT * FROM V_View1 WHERE .... (Komplexe SQL-Anweisung)

CREATE VIEW V_View3
AS SELECT * FROM V_View2 WHERE .... (Komplexe SQL-Anweisung)

Jeder Benutzer muß diese Views basierend auf eine andere Basistabelle benutzen können.

Die zu verabeitenden Daten können aus 2 Gründen nicht in einer Tabelle stehen:

1, Die Anzahl der Datensätze können pro Ergebnisstabelle bis 100.000 Datensätze betragen -> Performanceproblem, wenn alles in einer Tabelle steht!

2, Die Spalten der Tabelle sind teilweise unterschiedlich (ca. 5 Spalten sind bei allen Ergebnisstabellen gleich, die anderen sind unterschiedlich (Bezeichnung, Typ)

Für Access, auf den die bisherige Lösung basiert, war das kein Problem. Jede Ergebnisstabelle lag jeweils in einer eigenen Access-Datenbank. Alle Views, welche auf dieser Tabelle aufbauten, waren in einer anderen Access-Datenbank abgelegt. Die Ergebnisstabelle wurde dynamisch in die Datenbank unter einem festen Tabellennamen eingebunden.

Ich hoffe irgendjemand hat eine Idee und kann mir helfen.

[Andreas Kosch]

Hallo Bernhard,

wenn anstelle der VIEWS eine <b>Stored Procedure</b> als SELECT-Prozedur verwendet wird, kann der als Parameter übergebene Benutzername intern zur Verzweigung auf die unterschiedlichen Tabellen ausgewertet werden

[Bernhard Geyer]

Hallo Andreas,

dein Vorschlag geht für die erste Stufe der Views (in meinem Beispiel der View V_View1). Aber wie bekomme ich die darauf aufbauenden Views hin?

Mein Grundview als Stored Procedure ist (beispielhaft):

<b>CREATE PROCEDURE P_TestGroup<br>
@TableName as NVarChar(100)<br>
AS<br>

DECLARE @SQLString NVarChar(100)<br>

SET @SQLString = 'SELECT TCStatusId, Count(TCErrorCode) AS CountTC FROM ' + @TableName + ' GROUP BY TCStatusId'<br>
EXECUTE sp_executesql @SQLString</b>

Jetzt will ich meinen 2.ten View darauf aufbauen der Art:<br>
(Folgende Anweisung soll nur als Beispiel dienen)<br>
<b>SELECT P_TestGroup(@TableName='TCResult') WHERE TCStatusId < 100</b>

Ich würde hier nur 2 Möglichkeiten sehen:

<b>1. Alle Views multiplizieren:<br></b>
CREATE VIEW V_1_View1 AS SELECT * FROM Results_1 WHERE ... <br>
CREATE VIEW V_1_View2 AS SELECT * FROM V_1_View1 WHERE ... <br>

CREATE VIEW V_2_View1 AS SELECT * FROM Results_2 WHERE ... <br>
CREATE VIEW V_2_View2 AS SELECT * FROM V_2_View1 WHERE ... <br>

<b>1. Mit mehreren Datenbanken arbeiten (auf dem gleichen Server), in den jeweils alle Views definiert werden:<br></b>
CREATE VIEW V_View1 AS SELECT * FROM MasterDB.dbo.Results_1 WHERE ... <br>
CREATE VIEW V_View2 AS SELECT * FROM V_View1 WHERE ... <br>

Jeder User, der Reports auswerten will wird mit einer Datenbank, welche im Moment nicht benutzt wird, verbunden (Logging der benutzten Datenbanken), sowie der bzw. die "Grundview(s)" wird/werden entsprechend Angepaßt.

Die Anzahl der Views wird > 100 betragen. Die Anzahl der User liegt im Bereich < 50.

Wäre einer dieser beiden Möglichkeiten ohne große Hinternisse realisierbar

[Andreas Kosch]

Hallo Bernhard,

die Stored Procedure sieht nach dem <i>Microsoft SQL Server</i> aus, und da kenne ich mich nur sehr oberflächlich aus. Die generelle Frage ist die, sollte nicht die Design-Entscheidung <i>View-Hiararchie</i> aufgrund der neuen Datenbank nochmals überdacht werden? Wenn das bisherige Design auf <b>mehrere</b> ACCESS-Datenbanken ausgelegt war, wird es zwangsläufig mit <b>einer</b> SQL-Datenbank Veränderungen geben. Kann die Funktion der <i>View-Hiararchie</i> nicht auch nur durch Stored Procedure etc. (die intern Abfragen bzw. Verzweigungen durchführen) realisiert werden?

Das Aufteilung auf mehrere SQL-Datenbanken ist nur in begründeten Ausnahmen vertretbar