Discussion :

[fflores]

bonjour, j'ai un petit problème que je compte résoudre par une solution que je souhaite soumettre à vos avis éclairés:

Nous avons une base de données dont environ 80% des tables ont pour clé primaire un UNIQUEIDENTIFIER sur lequel est défini l'index clustered.
Ces clés sont générées de façon non séquentielle par une application. Pourquoi? parce que cela permet aux développeurs de pouvoir insérer les clés étrangères sans avoir à faire de SELECT pour les récupérer puisqu'elles sont générées avant insertion dans la base.

C'est pratique, mais provoque une fragmentation importante, à cause du fait que l'index clustered est sur ces colonnes. C'est un problème dont nous n'avions pas conscience à l'époque.

Pour résoudre ce problème, sans modification de l'application, je pensais à la solution suivante, et j'aimerais avoir votre avis:

- Ajouter dans mes tables un champ de type INT IDENTITY
- Placer l'index clustered sur ce champ,
- conserver la clé primaire sur le champ UNIQUEIDENTIFIER mais en changeant l'index Clustered en nonclustered.

J'attends vos avis avec impatience.

[SQLpro]

Conserver ce GUID n'a aucun intérêt et engorge votre tables de données inutile qui grèveront les performances. De plus par sa nature, en l'indexant il sera toujours aussi fragmenté et vous serez obligé d'effectuer un maintenance draconienne. Mieux vaut donc s'en débarrasser définitivement.
C'est le genre de stupidité que l'on rencontre chez les développeurs n'ayant pas de formation à la modélisation des données ni à l'administration des SGBDR.

Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p7...nt-le-verdict/

Au passage pour récupérer un ID autoincrémenté il suffit d'interroger la fonction SCOPE_IDENTITY() et non @@IDENTITY. Pas besoin (et surtout ne pas le faire...) de faire un SELECT sur la table. En effet si quelqu'un d'autre ajoute une ligne au même moment en // alors vous récupérerez l'ID de l'autre utilisateur.


A +

[fflores]

Merci pour ces explications.
J'avais tout à fait conscience du fait que le type uniqueidentifier occupe beaucoup plus d'espace. C'est la notion de fragmentation que je n'avais pas intégrée au moment de la modélisation.

Malheureusement, le mal est fait, et il parait difficile de demander aux développeurs aujourd'hui de refaire l'application.

Le scope_identity est en effet intéressant, je ne connaissais que le @@Identitiy.

Encore une question, je suis d'accord que l'index posé sur ce champ sera fragmenté, qu'il soit clustered ou non clustered mais ce qui m'importe aujourd'hui, dans l'urgence, c'est de limiter les effets négatifs de notre erreur. Confirmez-vous que le fait d'avoir de la fragmentation sur un index non clustered est moins pénalisant que de la fragmentation sur un index clustered et donc sur les données?

D'avance merci.

[SQLpro]

OUI, si vous maintenez le GUID, passer le en index non clustered et avec un FILL FACTOR d 75%. Prévoyez une maintenance systématique des index (une fois par jour), par exemple avec les routines que j'ai données ici :
http://blog.developpez.com/sqlpro/p8...es-index-et-s/

Bien entendu utilisez un INT IDENTITY comme clef si vous êtes en 32 bits et un BIGINT si vous êtes en 64 bits.

A +

[iberserk]

C'est le genre de stupidité que l'on rencontre chez les développeurs n'ayant pas de formation à la modélisation des données ni à l'administration des SGBDR.

Et chez notre ami commun MICROSOFT dont c'est la technique de modélisation de base (par exemple toutes les tables générées pour leurs providers .NET:
MEMBERSHIP,PROFIL,USERS/ROLES etc).

[SQLpro]

Je sais bien hélas.... Rare sont aujourd'hui les personnes correctement formé à l'art de la modélisation. Et bien évidemment ça pète de partout. Aujourd'hui je suis en Suisse pour ce genre de chose... Pour ma part je suis tellement sollicité pour de tels problématiques, que j'augmente en continu mes tarifs. Actuellement mes devis d'audit sont à 1200 € la journée et si ça continu je vais passer à 1 500 au printemps... Parce que je n'ai plus de journée avant juillet !

A +