Discussion :

[escartefigue]

Je ne suis pas du tout partisan d'utiliser dans une base de données des "auto increment".
Ce genre de colonne est une solution technique qui vient en remplacement d'un manque de finalisation fonctionnelle sur un MCD.

Certainement pas ! c'est même le contraire
Cette solution est proposée par la plupart des SGBD (tous ?) afin de répondre aux exigences de choix des colonnes constitutives d'une clef primaire : la clef doit être stable, asémantique et concise
Ceci n'a rien à voir avec la modélisation conceptuelle et je dirai même que c'est presque l'inverse : par exemple, une adresse ne possède aucun identifiant fonctionnel répondant aux exigences d'une clef primaire.
Seul un identifiant technique permet de les satisfaire, et dans ce cas, une identity column est l'une des solutions
Expliquez moi comment vous identifiez une adresse avec une colonne fonctionnelle !
A noter que je préfère utiliser le terme d'identity column, plutôt que de colonne auto-incrémentée, puisque l'incrément est une option, le décrément en est une autre

Quand j'étais administrateur DB2, je n'ai quasiment jamais rencontré ce genre de solution. Je parle bien de l'auto incrément.
Inversement, pour distinguer différentes lignes dans une table, une solution parfois utilisée est de mettre un timestamp, dont la valeur descend jusqu'au millionième de seconde.

Bien que DB2 (la version mainframe en tout cas), propose les identity column depuis très longtemps (au moins la V6), la solution a tardé à s'imposer dans certaines entreprises, probablement par méconnaissance des désavantages d'une clef sémantique, et aussi par défaut de maitrise des identity column.

J'ajoute que j'interviens depuis les années 80 dans des entreprises du monde de l'industrie, de l'assurance, la banque et la retraite, entreprises qui ont leur bases métier sur DB2 mainframe et leur bases annexes sur des systèmes open (oracle, sql-server voire, de moins en moins, sybase), dans tous les cas, l'usage des identity column est courant.

[escartefigue]

L'usage d'un auto_incrément est à l'identique d'un fichier VSAM de type RRDS (Relative Record Data Set) où l'accès ce fait par un numéro relatif d'enregistrement.
C'est le seul usage, en Cobol sous gros système IBM z/Os où l'on gère un fichier par rapport à un incrément.
L'organisation LDS (Linear Data Set), qui est utilisé pour le DB2 offre plus de possibilité pour se limiter à un incrément.
Attention, je parle bien d'un auto_incrément qui sert comme clef primaire à une table.

C'est complètement faux !
Les VSAM RRDS utilisaient bien un mode d'accès par n° d'enregistrement, mais certainement pas les index issus des identity column !

Ce que je reproche à l'usage de cet auto_incrément repose sur deux points :
1) le manque d'imagination du concepteur de la base de données pour trouver un véritable identifiant fonctionnel.
2) insertion des lignes selon l'ordre de stockages. C'est ce qu'il y a de pire comme organisation dans une table. --> Cf. Les clusters.

Pour le 1) voir ma réponse précédente, il faut vraiment ne rien connaitre à la modélisation conceptuelle pour affirmer de telles choses
Pour le 2) c'est faux,

• il n'y a aucune garantie que les n° identifiants respectent l'ordre d'arrivée : en fonction du paramétrage et du SGBD, les n° sont attribués par plage, et c'est la 1ère transaction qui commit qui utilise son numéro, sans garantie que ce soit le plus petit (en cas d'incrément) ou le plus grand (en cas de décrément)
• après delete, un identifiant peut être réutilisé (là aussi, en fonction du paramétrage)

[SergioMaster]

Bonjour,

je remarque que l'on s'éloigne beaucoup du sujet de départ, qui d'ailleurs est clos.
Une 'pseudo polémique' de ce genre aurait plus la place dans le forum SQL.

@escartefigue j'aime bien le terme de colonne identitaire (tant qu'à faire appliquons les termes français)

[Artemus24]

Salut Escartefigue

Cette solution est proposée par la plupart des SGBD (tous ?) afin de répondre aux exigences de choix des colonnes constitutives d'une clef primaire : la clef doit être stable, asémantique et concise

A te comprendre, une clef fonctionnelle n'aurait pas les qualités requises pour être une clef primaire ! Là oui, c'est du grand n'importe quoi.
Et le seul argument pour étayer ton opinion, c'est que tu as une expérience datant depuis 1980.

Prenons l'exemple du code iso d'un pays : https://fr.wikipedia.org/wiki/ISO_3166-1
En quoi le fait d'utiliser un code alphabétique de deux caractères serait moins bien que d'utiliser le code numérique sur trois chiffres ?
Voire même utiliser une numérotation toute personnelle indépendante de toutes normes ?

Ce sont des choix qui doivent répondre à la définition de la clef primaire : stable, unique et concise.
Tu fais usage du terme asémantique, c'est à dire porteur d'aucun sens ou de signification.
Si le concepteur d'un MCD a fait le choix du code pays alphabétique sur deux caractères, tu ne peux pas venir modifier son choix car cela est porteur d'une information utile.
Voire le remplacer par une autre numérotation qui selon un choix hasardeux, serai mieux adapté à l'usage que l'on voudrait faire au final.

Ceci n'a rien à voir avec la modélisation conceptuelle

C'est là où nous divergeons totalement. Cela a exactement à voir avec la modélisation.
Et plus précisément du passage du logique au physique !

par exemple, une adresse ne possède aucun identifiant fonctionnel répondant aux exigences d'une clef primaire.

Comme contre-exemple, tu prends l'adresse d'une personne qui est le moins bien adapté à une clef primaire.
Trop longue, unicité non prouvé, et une personne peut changer d'adresse, c'est-à-dire manque de stabilité.

C'est bien ce que je dis depuis le départ, ce sont des notions qui sont très mal comprises et fréquemment mal utilisés dans une base de données.

Seul un identifiant technique permet de les satisfaire, et dans ce cas, une identity column est l'une des solutions

Non ! Une colonne technique n'a rien à faire dans un modèle conceptuel de donnée. C'est juste pour répondre à un besoin technique et non fonctionnelle.
Maintenant si tu viens à te tromper dans le choix des clefs candidates, cela ne remet pas en cause l'aspect fonctionnel, mais juste les performances.

Expliquez moi comment vous identifiez une adresse avec une colonne fonctionnelle !

C'est très simple. Il suffit de créer un code d'identification qui va pointer sur une adresse. Ce code identification répondra aux exigences d'une clef primaire.
Dans une banque, l'accès de fait par un code client ou un numéro de compte principale.
A partir de cet identifiant, on trouve toutes les adresses postal, fiscal, de résidence ... dont le client à usage pour son courrier personnel.

A noter que je préfère utiliser le terme d'identity column, plutôt que de colonne auto-incrémentée, puisque l'incrément est une option, le décrément en est une autre

C'est juste de la sémantique et cela ne change pas la nature même de cette colonne.

Bien que DB2 (la version mainframe en tout cas), propose les identity column depuis très longtemps (au moins la V6), la solution a tardé à s'imposer dans certaines entreprises, probablement par méconnaissance des désavantages d'une clef sémantique, et aussi par défaut de maîtrise des identity column.

J'ai commencé à travaillé en DB2 en 1986 avec la version 2. J'ai commencé à faire de l'administration avec la version 5.
L'identity n'existait pas et on n'en avait pas besoin pour créer une clef primaire.

Ce n'est pas parce qu'il existait un manque dans les versions précédentes, que l'on ne savait pas résoudre ce genre de problème.
Maintenant venir dire que c'est la panacée à tous vos problèmes, c'est faire un raccourcis des plus dangereux.
Autrement dit, la solution technique va prendre le pas sur la fonctionnelle, et devenir au final ingérable !

L'externalisation des données des programmes informatiques, pour devenir les bases de données, ont été une solution pour les dissocier des problèmes techniques de la programmation.
Entre autre le choix des structures ou encore le typage. Et là, vous introduisez des aspects techniques pour résoudre des problèmes de performances dans une organisation fonctionnelle des données.
Désolé de le dire mais c'est un non sens !

Les VSAM RRDS utilisaient bien un mode d'accès par n° d'enregistrement, mais certainement pas les index issus des identity column !

Ou voyez-vous que j'aborde la question des index issus des identity column ? Nul part.
Pour votre gouverne, ce dont vous parlez n'existe pas dans l'organisation RRDS des fichiers VSAM.
Vous faites une interprétation erronée de ce que j'explique. Je parle de l'accès à un enregistrement par le numéro de rang dans le fichier de type RRDS.

il faut vraiment ne rien connaitre à la modélisation conceptuelle pour affirmer de telles choses

A bon, parce qu'un analyste dans le cadre de sa modélisation fonctionnelle va aborder des questions techniques ???
Là oui, c'est encore du grand n'importe quoi. Un analyste n'est pas censé connaitre le type de support physique sur lequel sa conception va se faire.

il n'y a aucune garantie que les n° identifiants respectent l'ordre d'arrivée : en fonction du paramétrage et du SGBD, les n° sont attribués par plage, et c'est la 1ère transaction qui commit qui utilise son numéro, sans garantie que ce soit le plus petit (en cas d'incrément) ou le plus grand (en cas de décrément)

Encore du grand n'importe quoi. Vous utilisez une clef primaire basée sur un incrément (voire identity column), donc une attribution de la valeur de la clef au moment de l'insertion dans la table et celle-ci ne serait pas insérer dans l'ordre.
Ce que vous affirmez, c'est que l'ordre est complétement aléatoire et ne dépend pas de la clef primaire. Donc pas de notion de cluster et encore moins la possibilité de gérer les performances à cause d'un désordre permanent.
Vous n'avez pas dû faire beaucoup d'administration dans votre expérience professionnelle.

après delete, un identifiant peut être réutilisé (là aussi, en fonction du paramétrage)

Depuis le départ, on vous parle de clef primaire et d'insertion dans une table et vous argumentez avec un delete ????
Franchement, je ne voie pas le rapport entre la question posée sur les clef technique et fonctionnelle, avec les conditions requises sur la clef primaire et le delete.

@+

[escartefigue]

A te comprendre, une clef fonctionnelle n'aurait pas les qualités requises pour être une clef primaire ! Là oui, c'est du grand n'importe quoi.
Et le seul argument pour étayer ton opinion, c'est que tu as une expérience datant depuis 1980.

Ce n'est pas ce que j'ai dit, j'ai dit que dans certains cas, on ne peut pas utiliser d'identifiant fonctionnel qui réponde aux exigences requises, nuance

Prenons l'exemple du code iso d'un pays : https://fr.wikipedia.org/wiki/ISO_3166-1
[. . .]
Ce sont des choix qui doivent répondre à la définition de la clef primaire : stable, unique et concise.

Contrairement à ce que vous énoncez, cette norme n'est pas stable, elle a été révisée à plusieurs reprises et pour cause : les lois de la géopolitique font que les frontières évoluent ainsi que les pays. Du coup si vous appliquez cette norme pour des clefs primaires, vous êtes assujetti aux modifications décidées par l'ISO.
Mauvaise pioche
Par contre, il va sans dire que utiliser des normes externes (ISO par exemple) pour des attributs autres que les identifiants primaires est souvent très utile

Non ! Une colonne technique n'a rien à faire dans un modèle conceptuel de donnée.

Qui dit le contraire ?
D'un point de vue conceptuel, on parle d'identifiant, pas de clef, et encore moins de "comment la clef est calculée" (par le SGBD, par programme ou par ma grand mère, peu importe)

C'est très simple. Il suffit de créer un code d'identification qui va pointer sur une adresse. Ce code identification répondra aux exigences d'une clef primaire.

... C'est exactement ce que fait une identity column, de façon automatique
Le fait de calculer l'identifiant manuellement vous affranchirait de votre propre remarque ??? que voici :

Ce que je reproche à l'usage de cet auto_incrément repose sur deux points :
1) le manque d'imagination du concepteur de la base de données pour trouver un véritable identifiant fonctionnel.[. . .]

-

Ce n'est pas parce qu'il existait un manque dans les versions précédentes, que l'on ne savait pas résoudre ce genre de problème.
Maintenant venir dire que c'est la panacée à tous vos problèmes, c'est faire un raccourcis des plus dangereux.
Autrement dit, la solution technique va prendre le pas sur la fonctionnelle, et devenir au final ingérable !

C'est très mal de déformer les propos d'autrui
J'ai dit, je cite :

Ceci n'a rien à voir avec la modélisation conceptuelle et je dirai même que c'est presque l'inverse : par exemple, une adresse ne possède aucun identifiant fonctionnel répondant aux exigences d'une clef primaire.
Seul un identifiant technique permet de les satisfaire, et dans ce cas, une identity column est l'une des solutions

Et là, vous introduisez des aspects techniques pour résoudre des problèmes de performances dans une organisation fonctionnelle des données.
Désolé de le dire mais c'est un non sens !

Qui parle de performances ? je n'ai pas utilisé une seule fois ce mot ni aucun synonyme dans ce sujet !
Encore une fois vous me citez en déformant mes propos !
De plus "résoudre des problèmes de performances dans une organisation fonctionnelle des données" n'a aucun sens

-

Pour votre gouverne, ce dont vous parlez n'existe pas dans l'organisation RRDS des fichiers VSAM.
Vous faites une interprétation erronée de ce que j'explique. Je parle de l'accès à un enregistrement par le numéro de rang dans le fichier de type RRDS.

Pourtant c'est vous qui avez écrit, je cite fidèlement vos propos :

L'usage d'un auto_incrément est à l'identique d'un fichier VSAM de type RRDS (Relative Record Data Set) où l'accès ce fait par un numéro relatif d'enregistrement

Et bien non, la notion de fichier RRDS qui est une notion de support physique de données n'a strictement aucun rapport avec les identity column

Encore du grand n'importe quoi. Vous utilisez une clef primaire basée sur un incrément (voire identity column), donc une attribution de la valeur de la clef au moment de l'insertion dans la table et celle-ci ne serait pas insérer dans l'ordre.
Ce que vous affirmez, c'est que l'ordre est complétement aléatoire et ne dépend pas de la clef primaire.
Donc pas de notion de cluster et encore moins la possibilité de gérer les performances à cause d'un désordre permanent.

1- vous n'avez rien compris à la notion d'index cluster : celui ci n'a rien à voir avec la chronologie de création des identifiants
2- oui, un identifiant calculé par le SGBD n'est pas systématiquement ajouté dans l'ordre des valeurs : certains SGBD, SQL server et DB2 for Z/OS par exemple, permettent d'attribuer des plages d'identifiants plutôt que de identifiants à l'unité (c'est plus rapide, et là je parle de perfs ), les identifiants sont ensuite consommées par les transactions en fonction des commit.
Cela dit, puisqu'on est dans Firebird, je ne crois pas que Firebird propose cette fonctionnalité.
Puisque vous avez pratiqué DB2, informez vous sur les paramètres "ORDER" (qui par défaut est à NO) et "CACHE" des identity column, vous en aurez le cœur net !

Vous n'avez pas dû faire beaucoup d'administration dans votre expérience professionnelle.

C'est l'hôpital qui se fout de la charité ou l'arroseur arrosé ?

[Artemus24]

Salut Escartefigue.

j'ai dit que dans certains cas, on ne peut pas utiliser d'identifiant fonctionnel qui réponde aux exigences requises, nuance

C'est justement cette "nuance" que je mets en doute !

Je vais reformuler ma phrase. Il y a des clefs fonctionnelles et des clefs techniques. Tous ces identifiants sont des candidats en tant que clef primaire.
Pourquoi choisir une clef technique, non porteuse d'information, à la place d'une clef fonctionnelle qui est celle préconisé par le MCD ?

il va sans dire que utiliser des normes externes (ISO par exemple) pour des attributs autres que les identifiants primaires est souvent très utile

On est déjà d'accord sur ce point.

cette norme n'est pas stable, elle a été révisée à plusieurs reprises et pour cause : les lois de la géopolitique font que les frontières évoluent ainsi que les pays. Du coup si vous appliquez cette norme pour des clefs primaires, vous êtes assujetti aux modifications décidées par l'ISO.
Mauvaise pioche

Pas du tout d'accord avec vous. La seule question que l'on doit se poser, c'est l'existant.
Si la norme ne vient que compléter un existant qui ne change pas, alors oui, c'est la bonne façon de faire.
Inversement, si l'existant change tout le temps, je suis d'accord avec vous.

Qui dit le contraire ?

Vous !

Quand on passe du modèle logique au modèle physique, on se fait le traducteur fidèle de ce qui a été préconisé par le concepteur, et non l'interprète.
Si une clef fonctionnelle a été préconisée, pourquoi la remplacer par une clef technique ? C'est là mon incompréhension.
Pour moi, ce n'est pas à DBA d'interpréter les désire du concepteur, mais bien au concepteur de revoir sa copie.

et encore moins de "comment la clef est calculée"

Désolé de le dire, mais vous avez tort. C'est le rôle du dictionnaire des données de définir comment elle sera calculée.
C'est bien dans les attributions du concepteur que d'envisager les choix fonctionnelles (puisqu'il s'agit de cela) afin de faciliter la réalisation technique.

C'est exactement ce que fait une identity column, de façon automatique

C'est ce genre de raccourci que je n'aime pas. Pourquoi mettre 1, 2, 3, 4 au lieu d'un code mnémonique ? A oui, je sais, parce que c'est concis.

C'est très mal de déformer les propos d'autrui

Je ne déforme rien, c'est ce que j'ai compris.

Seul un identifiant technique permet de les satisfaire, et dans ce cas, une identity column est l'une des solutions

Et bien non, je ne suis pas d'accord.

1) ce n'est pas à vous de réécrire les choix qui ont été préconisés par le concepteur de la base de données.
Si une table a été externalisée afin d'y mettre des adresses, il y a nécessairement déjà un identifiant.

2) si la conception a été mal faite, et que le DBA envisage justement d'externaliser ces adresses, alors seulement dans ce cas là, on peut envisager une clef technique.
Mais cette clef technique ne devra pas apparaître dans l'application. Comme le nom l'indique, c'est technique, c'est-à-dire pour remédier à un manque.

Qui parle de performances ?

C'est moi qui parle de cela. La raison d'introduire une clef technique, c'est juste pour répondre à un problème de performance.
Si vous avez une très grosse table, à cause des adresses qui prennent trop de place et sont peu consultés, externaliser les adresses est bien une réponse à une question de performance.
Sinon, quel est l'intérêt d'externaliser les adresses, si le concepteur ne l'a pas envisagé dès le départ ?
Parque ce concepteur n'a rien à faire des questions techniques et de performances. Ce n'est pas son rôle.

De plus "résoudre des problèmes de performances dans une organisation fonctionnelle des données" n'a aucun sens

C'est bien ce que je dis aussi, cela n'a pas de sens.

Et bien non, la notion de fichier RRDS qui est une notion de support physique de données n'a strictement aucun rapport avec les identity column

C'est l'exemple même d'une incompréhension dans nos propos.

L'organisation relative de type RRDS-VSAM consiste à désigner un enregistrement logique de fichier mémoire à accès sélectif à partir du numéro d'enregistrement, compté à partie de 1 pour le premier enregistrement. Le fichier est préformaté en "slots" blocs de longeur fixe, ce qui impose exclusivement des enregistrements de longueur fixe.

Ceci est extrait du livre "les extensions au cobol A.N.S. de Christian Bonnin.

Les accès se font à partir d'une numérotation, à l'identique des "identity columns". C'est de cela dont je parle.
Qu'est-ce que vous avez imaginé ? Que l'utilisateur pouvait numéroter les lignes à sa convenance ????

1- vous n'avez rien compris à la notion d'index cluster : celui ci n'a rien à voir avec la chronologie de création des identifiants
2- oui, un identifiant calculé par le SGBD n'est pas systématiquement ajouté dans l'ordre des valeurs : certains SGBD, SQL server et DB2 for Z/OS par exemple, permettent d'attribuer des plages d'identifiants plutôt que de identifiants à l'unité (c'est plus rapide, et là je parle de perfs ), les identifiants sont ensuite consommées par les transactions en fonction des commit.
Cela dit, puisqu'on est dans Firebird, je ne crois pas que Firebird propose cette fonctionnalité.
Puisque vous avez pratiqué DB2, informez vous sur les paramètres "ORDER" (qui par défaut est à NO) et "CACHE" des identity column, vous en aurez le cœur net !

Je n'ai rien compris de vos explications. Parlez-vous des clusters ou des identity columns ?
Et en quoi une clef primaire basée sur un identity column ne respecterait pas l'index cluster ?

L’idée de l’index cluster est de faire une pierre deux coups : mélanger l’index et la table. On s’évite ainsi une redondance et les lignes de la table sont physiquement triées selon l’ordre de la clef d’index.
Ainsi, une table dotée des colonnes Nom, Prénom, DateNaissance, Sexe, si elle est dotée d’un index cluster sur Nom est physiquement triée sur les valeurs des noms des personnes. Les autres colonnes n’étant pas triées.
On s’économise ainsi une redondance de données.

Je tire c'est extrait de ce lien : http://blog.developpez.com/sqlpro/p5...t_ce_que_c_est
C'est exactement la définition que j'ai du cluster. En quoi cette définition serait fausse ?
Je dis cela car vous affirmez que je n'ai rien compris à la notion d'index cluster.

En faite, je constate que nous avons un problème de compréhension, de définition et non de connaissance.

@+

[escartefigue]

Nous sommes très loin du sujet initial...

Sur l'essentiel des questions, j'ai déjà répondu il suffit de relire avec attention mes post précédents

Su le dernier point, la définition donnée par SLQ Pro (sous réserve que votre citation soit complète) est juste mais imparfaite, car elle ne s'applique que si la table est réorganisée,
Mais il n'en reste pas moins que votre remarque que j'ai déjà dénoncée plus haut et que je recopie à nouveau ci-dessous reste fausse :

Encore du grand n'importe quoi. Vous utilisez une clef primaire basée sur un incrément (voire identity column), donc une attribution de la valeur de la clef au moment de l'insertion dans la table et celle-ci ne serait pas insérer dans l'ordre.
Ce que vous affirmez, c'est que l'ordre est complétement aléatoire et ne dépend pas de la clef primaire.
Donc pas de notion de cluster et encore moins la possibilité de gérer les performances à cause d'un désordre permanent

Car vous confondez chronologie d'insertion et séquence des clefs et clef primaire et index cluster

Quand une table est réorganisée selon son index cluster, ses clefs sont rangées dans l'ordre des VALEURS et non pas de leur ANCIENNETE
Un index cluster doit répondre à un besoin réel. Exemple : si j'ai un besoin fréquent de recherche par nom, dans une appli ou j'ai beaucoup d'homonymes, la création d'un cluster sur le nom permet de faire une index scan très rapide sur toutes les occurrences semblables (tous les dupond par exemple).
Votre index cluster n'est pas forcément unique, alors qu'une colonne de type identifiant l'est forcément
C'est pourquoi votre phrase "Donc pas de notion de cluster et encore moins la possibilité de gérer les performances à cause d'un désordre permanent" est fausse
J'espère que c'est plus clair maintenant


Pour les codes pays, retournez faire un tour dans l'article Wikipédia, vous constaterez (mais je me répète) que des codes pays ont disparu (plus précisément sont obsolètes)
Et ce n'est pas une erreur Wiki, c'est le reflet des évolutions géopolitiques
La Haute Volta, l'Indochine, le Dahomey et bien d'autres pays ont disparu, d'autres, la Serbie, la Croatie (qui faisaient jadis partie de la Yougoslavie) etc... sont apparus récemment
Selon l'usage que vous faites de ces codes pays, c'est dommageable ou non, il faut juste en avoir conscience.
Des mises à jour en masse de clefs primaires avec des effets cascades liés aux contraintes d'intégrité peuvent avoir un cout rédhibitoire !

[Artemus24]

Salut Escartefigue.

Il est de plus en plus difficile de vous suivre.

Car vous confondez chronologie d'insertion et séquence des clefs et clef primaire et index cluster

Je ne confonds rien du tout. Que je m'exprime mal, je le veux bien, mais vous aussi !

Dans le cas d'un cluster, l'insertion se fait toujours selon la clef définie par l'index. Le cluster sert à ordonner les lignes sur le support physique.
La clef primaire est juste une façon de rendre unique une valeur identifiante d'une ligne d'une table.
Et je répète que je ne confonds pas ces deux notions.

Quand une table est réorganisée selon son index cluster

Voilà encore une façon de s'exprimer où je ne comprends rien.

La table est déjà organiser autour de son index cluster. Il existe un et un seul index cluster par table.
Qu'est-ce que vous entendez par "réorganiser" ? Qu'il n'y avait pas d'index cluster au préalable ? Et maintenant vous créer un nouvel index cluster.
Ou bien elle était organisé sur un autre index cluster que vous supprimez pour la remplacer par un nouvel index cluster ?
Ou encore réorganiser la table afin de créer des espaces libres "PCTFREE" dans les pages ?
Si vous êtes flou dans vos explications, cela me sera encore plus difficile à vous comprendre.

Maintenant si vous parlez de réordonner les clefs selon un tri croisant, je ne voie pas trop l'utilité car c'est déjà le rôle de l'index cluster de trier la table selon l'index.

ses clefs sont rangées dans l'ordre des VALEURS et non pas de leur ANCIENNETE

Mais pourquoi me parlez-vous d'ancienneté ? Je n'ai jamais abordé cette question.
Soit vous n'arrivez pas à me comprendre, soit vous mélangez tout.

Un index cluster doit répondre à un besoin réel.

Ce besoin est la performance !

Exemple : si j'ai un besoin fréquent de recherche par nom, dans une appli ou j'ai beaucoup d'homonymes, la création d'un cluster sur le nom permet de faire une index scan très rapide sur toutes les occurrences semblables (tous les dupond par exemple).

Oui. Cela signifie que les homonymes, au mieux, sont contigues dans la page. Voire à cheval sur deux pages.

Votre index cluster n'est pas forcément unique,

Voilà une ambiguïté.

Un index cluster est nécessairement unique. Il n'y a qu'un seul index cluster par table.
C'est normal car c'est sur le critère de cet index que les lignes seront ordonnancées dans la table.

Maintenant si vous parlez des valeurs que peut prendre cette index, je suis d'accord.
Pourquoi ? Car cet index cluster n'est pas nécessairement associé à une clef primaire ou un index unique.

alors qu'une colonne de type identifiant l'est forcément

Et voila encore une autre ambiguïté.

Un identifiant est du domaine de la modélisation ou fonctionnelle si vous préférez.

Si l'on parle de colonne alors on la désigne sous le terme de clef (key en anglais).
Votre identifiant n'est pas nécessairement une clef d'accès à votre table. C'est pourquoi on parle de clef candidate !

Mais pour que votre identifiant fonctionnelle devienne une clef d'accès de la table, il faut alors la qualifier :
--> soit de clef primaire
--> soit d'index unique

Sans cette qualification, on ne peut pas garantir la valeur de cet identifiant comme unique dans la table.
L'ambiguïté est de parler d'identifiant (terme fonctionnelle) associé à colonne (terme technique).

C'est pourquoi votre phrase "Donc pas de notion de cluster et encore moins la possibilité de gérer les performances à cause d'un désordre permanent" est fausse

Elle est fausse selon vous, car vous n'avez pas compris mes explications.

Quand je parle du cluster (comprendre index cluster), la table est nécessairement ordonnée sur cet index. Donc il n'y a pas de désordre permanent.
Autrement dit, les accès à votre "dupond" (une valeur de l'index cluster) sont contigües dans la page.

Si vous ne mettez pas d'index cluster, ou si l'index cluster se fait sur un autre critère que celui de votre requête, alors les accès ne seront pas performants.
Pourquoi ? Car vous ferez plus d'accès à vos données qui ne sont pas ordonnées selon le critère de votre requête.

Selon l'usage que vous faites de ces codes pays, c'est dommageable ou non, il faut juste en avoir conscience.

J'espère que vous avez compris que je ne suis pas concepteur de base de données, mais juste un DBA.
J'ai toujours respecté le choix des concepteurs et mon travail a été de maintenir en état de marche ces bases de données.
J'ai exercé mon activité d'administrateur non pas aux études mais à l'exploitation.
A bien vous comprendre, on ne fait pas le même métier.

@+

[escartefigue]

Oui, il y en a assez de vos fanfaronnades

Voilà encore une façon de s'exprimer où je ne comprends rien.
La table est déjà organiser autour de son index cluster. Il existe un et un seul index cluster par table.
Qu'est-ce que vous entendez par "réorganiser" ? Qu'il n'y avait pas d'index cluster au préalable ? Et maintenant vous créer un nouvel index cluster.
Ou bien elle était organisé sur un autre index cluster que vous supprimez pour la remplacer par un nouvel index cluster ?
Ou encore réorganiser la table afin de créer des espaces libres "PCTFREE" dans les pages ?
Si vous êtes flou dans vos explications, cela me sera encore plus difficile à vous comprendre.
Maintenant si vous parlez de réordonner les clefs selon un tri croisant, je ne voie pas trop l'utilité car c'est déjà le rôle de l'index cluster de trier la table selon l'index.

Quelqu'un qui ne connait pas la notion de cluster ratio, et qui ne vois pas l'intérêt de réorganiser selon l'index cluster...

Un index cluster est nécessairement unique. Il n'y a qu'un seul index cluster par table.
C'est normal car c'est sur le critère de cet index que les lignes seront ordonnancées dans la table.
Maintenant si vous parlez des valeurs que peut prendre cette index, je suis d'accord.

...et qui se pose des questions sur comment interpréter la notion "d'index unique"

Ne peut certainement pas prétendre ceci :

J'espère que vous avez compris que je ne suis pas concepteur de base de données, mais juste un DBA.J'ai toujours respecté le choix des concepteurs et mon travail a été de maintenir en état de marche ces bases de données.
J'ai exercé mon activité d'administrateur non pas aux études mais à l'exploitation.

A bien vous comprendre, on ne fait pas le même métier.

La je suis tout à fait d'accord !

[Artemus24]

Je me demande même avec qui vous êtes d'accord ?
Et si, comme vous dites, mes fanfaronnades vous dérange, personne ne vous oblige à me répondre !

[FOCUS77]

Bonsoir à tous

Le but de ce post est de vous faire savoir qu'avec la version Laz 1.6, la manipulation à distance

d'un GENERATOR est devenue possible, comme le montre ces bouts de codes.
Fig:

Code :

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

1
2
3
var
  Form1: TForm1;
  np:Boolean; i:integer;

1) Insertion d'un enregistrement:

Code :

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
procedure TForm1.FormKeyDown(Sender: TObject; var Key: Word;
  Shift: TShiftState);
 begin
  if Key=VK_F2 then
  begin
  np:=True;  // np:nouveau paquet d enregistrements.
  VENTES.Insert; //insertion du premier enregistrement.
  end;
  ...
  ...
 if key=VK_RETURN then
if MessageDlg('Nouveau Produit?',mtConfirmation,[mbyes,mbno],0)=mryes then
 begin
  np:=false; 
  VENTES.Insert;//insertion des autres enregistrements.
 end;
 VENTES.ApplyUpdates;
 end;

2) Attribution d'une valeur au champs 'NUM_VNT':

Code :

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

1
2
3
4
5
6
7
procedure TForm1.VENTESNewRecord(DataSet: TDataSet);
begin
  if np=True then
   VENTES.Sequence.SequenceName:='AUTOINC'
   else
   VENTES.Sequence.SequenceName:=''
end;

Code :

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

1
2
3
4
5
6
7
procedure TForm1.VENTESAfterInsert(DataSet: TDataSet);
begin
  if VENTES.FieldValues['NUM_VNT']<>Null then
  i:=VENTES.FieldValues['NUM_VNT'];
  if np=False then
  VENTES.FieldValues['NUM_VNT']:=i;
end;

merci à tous.

[FOCUS77]

Bonsoir à tous

je viens juste ce soir de mettre en épreuve l'efficacité de cette méthode en intégrant
ses codes à mon application et en déployant cette dernière sur un réseau local formé de
trois PCs, (pour une transaction type 'Read committed') et..
le tout fonctionne parfaitement

merci à vous tous