Question optimisation - index

Bonsoir,

J'ai une table nommée tableA qui comporte deux champs ip1 et ip2 au format Long. Il s'agit d'adresses IP converties en Long. Cette table comporte également un champ info.
Je voudrais faire une requête sur ce modèle pour alimenter un autre champ info pour toute la table TableB :

Code:

---

1 2 3 4 5 6

update TableB set TableB.info = (select top 1 TableA.info from TableA where TableB.ip >= TableA.ip1 and TableB.ip <= TableA.ip2) where TableB.info is null;

---

Mes questions sont les suivantes: je voudrais créer un index cluster sur les champs (ip1,ip2). Est-ce une bonne solution compte tenu du fait que je vais faire une sélection par comparaison ?

La forme de requête imbriquée est elle un choix pertinent ? Les tables tableA et tableB vont comporter en effet un grand nombre d'enregistrements...

D'avance merci pour vos réponses !

Le type "LONG" n'existe ni pour SQL Server ni dans la norme SQL ! De quoi parlez vous ? Soyez clair !!!

Il n'y a pas d'enregistrement dans les tables, mais des lignes et "un grand nombre d'enregistrements" ne veut rien dire... Quelle volumétrie : 1 Go, 10 Go, 100 Go dans la table ?

Enfin quel est l'intérêt de dupliquer les informations ? En principe dans une base de données relationnelle aucune information ne doit être redondante sauf les valeurs des clefs étrangères, ou sauf cas fortuit ! Plutôt que de faire un update pourquoi ne pas faire une vue ?

A +

Pardon, je me suis mal exprimé.

Je ne voulais pas parler de Long mais de BigInt.

Impossible de faire une clef étrangère entre tableA et tableB puisque la relation entre les champs info se fait sur une plage et non sur une correspondance de valeurs. Ce point est peut être discutable. Perso ça me choque un peu de faire un join avec un intervalle comme condition de jointure, non ? Dans ce cas aussi il faudra que je créé un index cluster sur les champs ip1 et ip2, c'est pareil ?
J'imagine que votre suggestion de vue c'est de faire un select avec jointure entre tableA et tableB dans cette vue ?
De toutes façon, d'un point de vue fonctionnel, je suis obligé d'alimenter le champ info de la table tableB.

Merci

Citation:

---

d'un point de vue fonctionnel

---

HUM HUM...

En lieu et place d'utiliser directement la tableB dans vos programmes utilisez directement une vue V_TABLEB par exemple qui ira chercher directement 'info' dans la table A ainsi vous respectez les règles de modélisation en évitant les redondances d'informations.

En outre pensez au BETWEEN dans vos requètes :

Code:

---

1 2	...WHERE TableB.ip BETWEEN TableA.ip1 and TableA.ip2)

---

Oui en fait je suis d'accord du début avec vos remarques mais pour être tout à fait clair, il y a déjà un programme de fait (pas par moi) qui utilise la tableB et qui n'utilisera pas autre chose que la tableB Donc tant pis pour merise...

Est ce que le fait d'utiliser between est plus performant que d'utiliser un filtre >= and <= ?

Et je reviens à ma question initiale, vous me conseillez quoi comme indexes sur tableB ? Que l'on créé une vue ou pas il faudra bien indexer cette table non ?

Merci

Cette requête sera plus performante :

Code:

---

1 2 3 4 5

UPDATE TB SET TB.info = TA.INFO FROM TableB TB, TableA TA WHERE TB.IP BETWEEN TA.IP1 AND TA.IP2 AND TB.info IS NULL

---

Elle permet en outre de profiter pleinement d'un index placé sur le couple IP1 IP2.

En surveillant les problématiques de volumétrie vous pouvez même songer à un index COUVRANT en ajoutant TableA.info en tant que colonne incluse dans l'index.

Citation:

---

Est ce que le fait d'utiliser between est plus performant que d'utiliser un filtre >= and <=

---

Vous viendait-il à l'idée de recoder dans vos requêtes des fonctions comme RIGHT() ?
C'est pareil pour BETWEEN, s'il existe ce n'est pas pour nous embêter...

D'autant que SQL Server "retraduit" le BETWEEN a AND b en >= a AND <= b ;)

@++ ;)

Ok pour l'index couvrant, c'est une fonctionnalité que j'avais l'habitude d'utiliser sous Mysql.

Par contre je ne comprend pas pourquoi mais dans le management studio je ne peux pas faire d'index couvrant en index cluster. Je suis obligé de faire un index non cluster. C'est normal ?

Merci d'avance

Un index couvrant possède la clé d'index + les colonnes couvrantes au niveau feuille alors que celui d'un index cluster est en réalité la table elle même.

C'est la raison pour laquelle qu'un index couvrant est forcément non cluster.


++

De plus un index cluster est par essence unique (contrainte d'unicité).
Comme il contient la table il ne peux y en avoir qu'un puisque les autres indexes de la table(non cluster donc..) référence cet index

Citation:

---

Envoyé par iberserk

De plus un index cluster est par essence unique (contrainte d'unicité).
Comme il contient la table il ne peux y en avoir qu'un puisque les autres indexes de la table(non cluster donc..) référence cet index

---

Absolument pas... Unicité et CLUSTER n'ont rien à voir l'un avec l'autre.

EXEMPLE :

Code:

---

1 2 3 4 5

CREATE TABLE T (C INT)   INSERT INTO T VALUES (0), (0), (0);   CREATE CLUSTERED INDEX X ON T (C);

---

Apprenez SQL ! Mon site web, comme mon bouquin est là pour vous y aider !

A +

Autant pour moi je voulais dire unique (un seul par table).
Amalgame avec le fait que SQL SERVER place par défaut un index unique cluster lors de la définition d'une PK sur une table.