2009-10-16 6 views
0

Lorsque vous attachez une vue SQL Server en tant que table liée MS Access, un identifiant unique vous est demandé. Au cours des derniers essais, j'ai remarqué qu'à plusieurs reprises, NE PAS définir l'identifiant unique a pour effet que la table liée s'ouvre beaucoup plus rapidement (vous n'avez pas besoin de chronomètre, vous pouvez vraiment le VOIR).Liaison de la vue SQL Server à Access db: question de performance

Donc je demande aux experts s'il y a une explication à cela, et quelle est la règle: définir ou ne pas définir une clé primaire pour la vue attachée?

Mes comparaisons ont été faites sur la même machine, la même Access 2007 db, les mêmes vues, le même pilote (SQL Server 10), le même serveur SQL Server 2008.
Pour mon cas, je n'ai pas besoin de mettre à jour les tables liées (qui sont des vues SQL).

+0

Ceci est un vrai tour de performance! –

Répondre

1

L'accès nécessite uniquement un identifiant unique pour pouvoir effectuer des mises à jour. Si vous ne définissez pas l'identifiant unique (et vous n'en avez pas besoin), il ne les suit pas, donc je suppose que c'est plus rapide. Je ne suis pas sûr de savoir pourquoi la différence est si perceptible. Quelle est la largeur (colonnes et octets) de l'identifiant unique que vous avez choisi sur la version lente?

+0

ID sont petites, comme 10 char, et les données autour de 15000 enregistrements. Le serveur est puissant et pas occupé. La prochaine fois, j'essaierai d'examiner l'utilisation du processeur sur l'ordinateur client. –

+0

La différence de performance peut être liée à la possibilité d'utiliser une stratégie de verrouillage des performances car elle sait que les données seront en lecture seule. – JohnFx

1

J'ai répliqué vos résultats sur mon ordinateur de test, et j'ai même exécuté le profileur pour voir si je pouvais le comprendre. Je me suis connecté à une vue deux fois, une fois avec un identifiant unique spécifié et un sans. Les mêmes résultats que vous.

Le profil n'était pas très éclairant; pour la vue UNindexed, il s'agissait d'une vue SELECT columnList FROM standard. Pour la vue indexée, elle ne spécifiait que la colonne clé (même si les résultats affichent clairement toutes les colonnes). La seule chose que je peux penser est que puisque vous spécifiez une clé unique dans Access, l'ensemble de données doit être complètement tiré en mémoire afin qu'Access associe la colonne clé sur le serveur avec l'index local. S'il n'y a pas d'index local, il n'est pas nécessaire que cette association se produise.

+0

Je m'attendrais à ce que Jet tire des métadonnées sur l'index et pas grand chose d'autre. Il n'aurait certainement pas besoin de tirer toute la table, et probablement pas même l'ensemble de l'indice PK. –

+0

Peut-être; Ce qui me déroutait, c'est que même si je voyais des données dans l'affichage de la table liée dans Access, la requête qui était en cours d'exécution sur la version indexée ne faisait que sélectionner la colonne indexée. D'où vient le reste des données? –

+0

Heureux de vous voir trouvé la chose sam. Mes résultats ici juste en raison d'un retard notable lors de l'ouverture manuelle de la table (plusieurs fois). Je me demande si Access construit un index local unique à l'ouverture? –

Questions connexes