TSQL les clés étrangères des points de vue?

Peter déjà frappé, mais la meilleure solution est de:

1. Créer la "principale" de la logique (que le filtrage de la table référencée) une fois.
2. Avoir tous les points de vue sur des tables de jointure à la vue créé pour (1), pas de la table d'origine.

I. e.,

CREATE VIEW v1 AS SELECT * FROM table1 WHERE blah

CREATE VIEW v2 AS SELECT * FROM table2 WHERE EXISTS
  (SELECT NULL FROM v1 WHERE v1.id = table2.FKtoTable1)

Sûr, sucre syntaxique pour la multiplication de filtres pour les points de vue sur une table de points de vue sur les actions subalternes à tables de, ce serait pratique, mais hélas, il ne fait pas partie de la norme SQL. Cela dit, cette solution est encore assez bon -- efficace, simple, facile à maintenir, et des garanties de l'état souhaité pour les consommateurs de code.

Il m'a fallu un certain temps pour comprendre le misunderstaning ici -- ne sais pas si j'ai encore totalement compris, mais ici il est.
Je vais utiliser un exemple, près de la vôtre, mais avec quelques données -- plus facile pour moi de penser en ces termes.

Donc d'abord deux tables; A = Département B = Employé

CREATE TABLE Department
  ( 
   DepartmentID int PRIMARY KEY
  ,DepartmentName varchar(20)
  ,DepartmentColor varchar(10)
  )
GO 
CREATE TABLE Employee
  ( 
   EmployeeID int PRIMARY KEY
  ,EmployeeName varchar(20)
  ,DepartmentID int FOREIGN KEY REFERENCES Department ( DepartmentID )
  )
GO 

Maintenant, je vais jeter quelques données dans

INSERT  INTO Department
  ( DepartmentID, DepartmentName, DepartmentColor )
 SELECT 1, 'Accounting', 'RED' UNION
 SELECT 2, 'Engineering', 'BLUE' UNION
 SELECT 3, 'Sales', 'YELLOW'  UNION
 SELECT 4, 'Marketing', 'GREEN' ;

INSERT  INTO Employee
  ( EmployeeID, EmployeeName, DepartmentID )
 SELECT 1, 'Lyne', 1 UNION
 SELECT 2, 'Damir', 2 UNION
 SELECT 3, 'Sandy', 2 UNION
 SELECT 4, 'Steve', 3 UNION
 SELECT 5, 'Brian', 3 UNION
 SELECT 6, 'Susan', 3 UNION
    SELECT 7, 'Joe', 4 ;

Donc, maintenant, je vais créer une vue sur la première table de filtrer certains départements.

CREATE VIEW dbo.BlueDepartments
AS
SELECT * FROM dbo.Department
WHERE DepartmentColor = 'BLUE'
GO

Cela renvoie

DepartmentID DepartmentName       DepartmentColor
------------ -------------------- ---------------
2            Engineering          BLUE

Et par votre exemple, je vais ajouter une vue de la deuxième table qui ne filtre rien.

CREATE VIEW dbo.AllEmployees
AS
SELECT * FROM dbo.Employee
GO

Cela renvoie

EmployeeID  EmployeeName         DepartmentID
----------- -------------------- ------------
1           Lyne                 1
2           Damir                2
3           Sandy                2
4           Steve                3
5           Brian                3
6           Susan                3
7           Joe                  4

Il me semble que vous pensez que l'Employé N ° 5, DepartmentID = 3 points de nulle part?

", Vous vous retrouverez avec des entrées dans la
second point de vue que le point de nulle part."

Bien, il souligne l' Department table DepartmentID = 3, tel que spécifié par la clé étrangère. Même si vous essayez de joindre vue sur vue rien n'est cassé:

SELECT  e.EmployeeID
       ,e.EmployeeName
       ,d.DepartmentID
       ,d.DepartmentName
       ,d.DepartmentColor
FROM    dbo.AllEmployees AS e
        JOIN dbo.BlueDepartments AS d ON d.DepartmentID = e.DepartmentID
        ORDER BY e.EmployeeID

Retourne

EmployeeID  EmployeeName         DepartmentID DepartmentName       DepartmentColor
----------- -------------------- ------------ -------------------- ---------------
2           Damir                2            Engineering          BLUE
3           Sandy                2            Engineering          BLUE   

Si rien n'est cassé ici, la jointure n'a tout simplement pas trouver la correspondance des enregistrements pour DepartmentID <> 2 C'est en fait la même que si je les tables de jointure et puis filtre inclure comme dans le premier point de vue:

SELECT  e.EmployeeID
       ,e.EmployeeName
       ,d.DepartmentID
       ,d.DepartmentName
       ,d.DepartmentColor
FROM    dbo.Employee AS e
        JOIN dbo.Department AS d ON d.DepartmentID = e.DepartmentID
        WHERE d.DepartmentColor = 'BLUE'
     ORDER BY e.EmployeeID

Retourne de nouveau:

EmployeeID  EmployeeName         DepartmentID DepartmentName       DepartmentColor
----------- -------------------- ------------ -------------------- ---------------
2           Damir                2            Engineering          BLUE
3           Sandy                2            Engineering          BLUE

Dans les deux cas, les jointures ne manquent pas, ils sont simplement comme prévu.

Maintenant, je vais essayer de briser l'intégrité référentielle par le biais de vue (il n'y a pas de DepartmentID= 127)

INSERT  INTO dbo.AllEmployees
      ( EmployeeID, EmployeeName, DepartmentID )
VALUES( 10, 'Bob', 127 )

Et il en résulte:

Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the FOREIGN KEY constraint "FK__Employee__Depart__0519C6AF". The conflict occurred in database "Tinker_2", table "dbo.Department", column 'DepartmentID'.

Si j'essaie de supprimer un service à travers le point de vue

DELETE FROM dbo.BlueDepartments
WHERE DepartmentID = 2

Qui se traduit par:

Msg 547, Level 16, State 0, Line 1
The DELETE statement conflicted with the REFERENCE constraint "FK__Employee__Depart__0519C6AF". The conflict occurred in database "Tinker_2", table "dbo.Employee", column 'DepartmentID'.

Donc les contraintes sur les tables sous-jacentes s'appliquent toujours.

Espère que cette aide, mais alors peut-être que j'ai mal compris votre problème.

Quelque chose comme cela dans Vue2 est probablement votre meilleur pari:

CREATE VIEW View2
AS
     SELECT
          T2.col1,
          T2.col2,
          ...
     FROM
          Table2 T2
     INNER JOIN Table1 T1 ON
          T1.pk = T2.t1_fk

À l'aide de Rob Farley schéma:

CREATE TABLE dbo.testtable(
id int IDENTITY(1,1) PRIMARY KEY,
val int NOT NULL); 
go
INSERT dbo.testtable(val)
VALUES(20),(30),(40),(50),(60),(70);
go 
CREATE TABLE dbo.secondtable(
id int NOT NULL,
CONSTRAINT FK_SecondTable FOREIGN KEY(id) REFERENCES dbo.TestTable(id)); 
go

CREATE TABLE z(n tinyint PRIMARY KEY);
INSERT z(n)
VALUES(0),(1);
go
CREATE VIEW dbo.SecondTableCheck WITH SCHEMABINDING AS
SELECT 1 n
FROM dbo.TestTable AS t JOIN dbo.SecondTable AS s ON t.Id = s.Id
CROSS JOIN dbo.z
WHERE t.Val < 50;
go
CREATE UNIQUE CLUSTERED INDEX NoSmallIds ON dbo.SecondTableCheck(n);
go

J'ai dû créer une petite table d'assistance (dbo.z) pour faire ce travail, parce que les vues indexées ne peut pas avoir l'auto-jointures, les jointures externes, sous-requêtes, ou de tables dérivées (et TVCs comptent comme des tables dérivées).

Vous pourriez stade filtré tableau 1 données d'une autre table. Le contenu de cette mise en scène de la table sont à votre vue 1, puis vous construisez vue 2 via une jointure de la table intermédiaire et le tableau 2. De cette façon, le proccessing pour le filtrage de la table 1 est fait une fois et réutilisés pour les deux points de vue.

Vraiment ce qu'il se résume à ce point de vue 2 n'a aucune idée de quel type de filtrage que vous avez effectué à vue 1), sauf si vous dites à vue 2 les critères de filtrage, ou de les rendre en quelque sorte tributaire des résultats de la vue 1, ce qui signifie que l'émulation de la même filtrage qui se produit sur vue1.

Contraintes de ne pas effectuer tout type de filtrage, elles ne préviennent des données non valides, ou en cascade principales modifications et les suppressions.

D'une approche purement intégrité des données de point de vue (et rien à voir avec l'Optimiseur de Requête), j'avais envisagé une Vue Indexée. J'ai pensé que vous pourriez faire un index unique, qui pourrait être rompu lorsque vous essayez d'avoir violé l'intégrité dans vos tables sous-jacentes.

Mais... je ne pense pas que vous pouvez contourner les restrictions de vues indexées assez bien.

Par exemple:

Vous ne pouvez pas utiliser les jointures externes, ou des sous-requêtes. Qui rend très difficile de trouver les lignes qui n'existent pas dans la vue. Si vous utilisez des agrégats, vous ne pouvez pas utiliser AVOIR, de sorte que les coupes certaines options vous pouvez utiliser on trop. Vous ne pouvez même pas avoir des constantes dans une vue indexée si vous avez groupement (si vous utilisez une clause GROUP BY), de sorte que vous pouvez même pas essayer de mettre un index sur un champ constant de sorte qu'une seconde ligne va tomber. Vous ne pouvez pas utiliser de l'UNION de TOUS, de sorte que l'idée d'avoir un nombre qui va casser un index unique quand il frappe un second zéro ne fonctionne pas.

Je me sens comme il devrait y avoir une réponse, mais je crains que vous allez avoir à prendre un bon coup d'oeil à votre conception réelle et le travail ce que vous avez vraiment besoin. Peut-être les déclencheurs (et un bon index) sur les tables concernées, ainsi que toutes les modifications qui pourraient casser quelque chose peut rouler tout ça.

Mais j'espérais vraiment être en mesure de proposer quelque chose que l'Optimiseur de Requête peut être en mesure de l'effet de levier pour aider à la performance de votre système, mais je ne pense pas que je peux.