Les vues matérialisés, les index clustered et la commande insert select

Bonjour,

J'ai une petite question sur les mécanismes de gestion des index sur les vues matérialisés dans SQL Server 2000.

Voilà, j'ai créé la vue matérialisée suivante :

CREATE view viewOrders with SCHEMABINDING as

select o.continent_code as continent_code, o.customer_code as customer_code, cust.label as customer_label, rf.OPE_RF_CODE as rf_code, rf.label as rf_label, o.WEEK_DATE as WEEK_DATE, o.YEAR_DATE as YEAR_DATE, count_big(*) as nb_orders
from dbo.DKP_ORDERS o, dbo.DKP_OPE_RPL_FAM rf, dbo.DKP_OPE_ITEMS items, dbo.DKP_UF_CUSTOMERS cust
where o.opc_code = items.opc_code
and rf.ope_rf_code=items.ope_rf_code
and cust.customer_code=o.customer_code
and cust.continent_code = o.continent_code
group by o.continent_code, o.customer_code, rf.ope_rf_code, cust.label, rf.label, o.WEEK_DATE , o.YEAR_DATE

Cette vue met en œuvre 4 tables qui, au moment de la création de la vue sont vides.

A la suite de la création de la vue, je crée un index sur cette vue :

CREATE UNIQUE CLUSTERED INDEX VOrdersIdx ON viewOrders (continent_code, customer_code, rf_code, WEEK_DATE, YEAR_DATE)

Je souhaite alors alimenter ces 4 tables par des ordres de type « INSERT INTO Table SELECT … »

Le problème est alors le suivant : la commande SELECT est correcte et nous retourne un certain nombre de ligne mais la commande « INSERT » n’insert aucune ligne dans la table DKP_UF_CUSTOMERS. Il n’y a pas d’erreur mais aucune ligne n’est insérée.

A savoir, la table DKP_OPE_ITEMS possède une ForeignKey issue de la table DKP_OPE_ITEMS et la table DKP_ORDERS possède une FK issue de la table DKP_UF_CUSTOMERS

L’insertion de données par une commande simple sans passer par un « INSERT SELECT » fonctionne.

Il semblerai donc que c’est la commande « INSERT SELECT » qui pose problème.

Après nombre de tests, il s’avère que la suppression de l’index sur ma vue débloque la situation et me permet de nouveau de faire des insertions via la commande « INSERT SELECT ».



Quelqu'un pourrait-il m'expliquer le phénomène et son origine ?

Merci d'avance

Mickaël

mettre un index sur une vue n'est pas des plus propres, surtout en clustered

a mon avis, tu devrais mettre des index adéquats sur les 4 tables, car sql serveur se base sur les index des tables appelées pour les vues.

en plus il mettra moins de temps a mettre a jour la vue lors de tes insert ou update

remplace tes , par des inner join qui restreignent le flux

Code:

---

1 2 3 4 5 6 7

select o.continent_code as continent_code, o.customer_code as customer_code, cust.label as customer_label, rf.OPE_RF_CODE as rf_code, rf.label as rf_label, o.WEEK_DATE as WEEK_DATE, o.YEAR_DATE as YEAR_DATE, count_big(*) as nb_orders from dbo.DKP_ORDERS o inner join dbo.DKP_UF_CUSTOMERS cust on cust.customer_code=o.customer_code and cust.continent_code = o.continent_code inner join dbo.DKP_OPE_ITEMS items on o.opc_code = items.opc_code inner join dbo.DKP_OPE_RPL_FAM rf on rf.ope_rf_code=items.ope_rf_code group by o.continent_code, o.customer_code, rf.ope_rf_code, cust.label, rf.label, o.WEEK_DATE , o.YEAR_DATE

---

A+
serge

Merci pour tes conseils Serge.

Tu dis que sql serveur se base sur les index des tables appelées pour les vues.
Est-ce le cas également pour les vue matérialisée (with SCHEMABINDING) ?

Et si quelqu'un peut m'expliquer pourquoi avec mon index SQL server ne permet pas d' "insert select" sans pour cela retourner de message d'erreur, je suis preneur !

Bonjour,

La création d'index sur des vues est une fonctionnalité qui n'a rien de sale, et qui peut être une excellente solution pour améliorer les performances. Elle n'est possible théoriquement en SQL 2000 qu'avec une version entreprise.
Le premier index sur la vue est obligatoirement ordonné (clustered), cela fait partie des contraintes d'une vue indexée.
Si l'INSERT ne fonctionne pas, c'est peut-être à cause d'une autre contrainte, qui oblige certains paramètres de la connexion à être fixés. Regardez dans l'aide en ligne sous "Creating an Indexed View", ou "créer une vue indexée" (je suppose).
Les options settées par la connexion qui a créé la vue doivent être les mêmes dans les connexions qui font les INSERT, pour garantir que les données matérialisées dans la vue seront toujours cohérentes.