Discussion :

[StringBuilder]

Bonjour,

J'essaie de m'auto-former sur les diverses méthodes pour optimiser une base de données, et je souhaite créer une vue indexée.

Voici le DDL de la base de test :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
CREATE TABLE dbo.firstname
(
	id int NOT NULL primary key,
	name varchar(20) NOT NULL
);
 
CREATE TABLE dbo.lastname
(
	id int NOT NULL primary key,
	name varchar(20) NOT NULL
);
 
create view dbo.fullname
as
select coalesce(f.id, l.id) id, f.name firstname, l.name lastname
from dbo.firstname f
full outer join dbo.lastname l on l.id = f.id;

Lors j'essaie de créer un index sur ma vue "dbo.fullname", j'obtiens une erreur comme quoi la vue n'est pas liée au schéma.

J'ai donc ajouté la clause WITH SCHEMABINDING à la déclaration de ma vue :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
create view dbo.fullname with schemabindings
as
select coalesce(f.id, l.id) id, f.name firstname, l.name lastname
from dbo.firstname f
full outer join dbo.lastname l on l.id = f.id;

Sauf que maintenant SQL Server râle car l'index clustered de ma vue n'est pas unique.

J'ai donc essayé de créer cet index clusterd :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
create unique clustered index uix_id on dbo.fullname(id);

Et là, SQL Server râle à cause de la présence d'une clause "outer join" dans ma vue.

Bon, alors je réécris ma vue sans OUTER JOIN :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
create view dbo.fullname WITH SCHEMABINDING
as
select f.id, f.name firstname, l.name lastname
from dbo.firstname f
inner join dbo.lastname l on l.id = f.id
union all
select f.id, f.name, null
from dbo.firstname f
where f.id not in (select l.id from dbo.lastname l)
union all
select l.id, null, l.name
from dbo.lastname l
where l.id not in (select f.id from dbo.firstname f);

Et là, il veut toujours pas de l'index car la vue comporte des UNION...

Euh...

En fait, on peut faire des vues indexées uniquement si elles sont simple à bouffer de la paille ? Quel intérêt ?

[Donpi]

J'étais arrivé à la même conclusion il y a quelques mois.
C'est déprimant.

PS: Vous avez essayer avec un index non cluster ?

[StringBuilder]

Quand je crée un index NONCLUSTER, il me dit que... l'index CLUSTER n'est pas unique (même s'il n'y en a pas de défini explicitement).

[bvesan]

Bonjour,
La liste des contraintes sur la requête à transformer en vue indexée est effectivement longue comme le bras: http://msdn.microsoft.com/fr-fr/libr...x#Restrictions
Donc pas de jointure externe, pas de UNION (mais a priori pas de problème avec les UNION ALL), et pas de sous requête.

Je pense que l'idée de la vue indexées est de dramatiquement améliorer les perfs sur des requêtes avec un très grand nombre de jointures (modèle très normalisé) sur des tables de forte volumétrie avec une fréquence de mise à jour très faible (parce que le surcoût à la mise à jour des tables sous jacentes) reste important.

[iberserk]

En fait, on peut faire des vues indexées uniquement si elles sont simple à bouffer de la paille

Ne rabaissez pas nos chers amis équidés comme cela!!!

En effet les vues indexées (vieilles comme le monde au passage...) induisent de nombreuses limitations.

Au delà d’éviter les jointures elles sont surtout intéressante pour les requêtes mettant en jeu des agrégats afin de drastiquement limiter la volumétrie.

Attention a bien peser le pour et le contre sur le coût nécessaire à maintenir le ou les indexes de telles vues.

[StringBuilder]

Faudrait déjà que j'arrive à en créer une

Ok, donc principalement pour des vues contenant des données agrégées.

Merci pour ces informations