Table sans PK : SGBDR permissif, pourquoi ?

[zinzineti]

Bonjour,
Il me semble que dans la théorie du modèle relationnel, chaque table DOIT avoir une clé primaire (identifiant unique).
Mais comment comprendre le fait que les éditeurs de SGBDR soient permissifs vis à vis de cette recommandation [qui devrait figurer dans les normes ISO (je ne sais plus laquelle)] et autorise la création de table sans PK ?
J'ai entendu dire que pour une table temporaire par exemple on n'a pas besoin de PK. Et que posé une clé primaire sur une table temporaire va ralentir les traitements.
Et je réponds OUI, si cette affirmation est vraie pour les tables temporaires par exemple, pourquoi pour les tables permanentes il y a aucune alerte de la part des SGBDR pour notifier l’existence de table permanente sans PK ?

Merci de m'éclairer

[dbaffaleuf]

Il n'y a pas de règle universelle pour les tables temporaires. Tout dépend de ce que l'on veut en faire. Si on a besoin de faire une jointure entre une table temporaire et une table physique, ou rechercher sur un critère dans la table temporaire par exemple, ça peut être intéressant de placer un index (par exemple pour les très longues IN-Lists). Le fait que les tables temporaires contiennent assez souvent peu de volumétrie a peut être répandu cette idée, mais ce n'est pas généralisable (pas grand chose ne l'est en définitive).

Et un SGBD ne peut pas contraindre un développeur à mettre des clés primaires partout, il y a des cas où ça n'a pas de sens (certaines tables de logs).

[SQLpro]

Le fait de faire des tables sans clef à été spécifiquement pensé pour la reprise des données. En effet rien ne dit que l'on a pas des doublons dans des fichiers... Or traiter un fichier est souvent plus long que de le faire dans les lignes d'une table.

C'est pourquoi, oui, des tables sans clef sont utile notamment pour des imports voire des exports, voire des tables de log (exemple table de hit d'un site web ou 2 utilisateur peuvent avoir affiché la même page à la même milliseconde).

En sus, une très petite table et qui le restera toujours (exemple, table des sexe, des civilités) sera en principe plus rapide sans aucune clef ni index, car il n'y aura jamais lecture que d'une page, alors qu'avec un index ce sera un minimum de deux !

A +

[zinzineti]

Envoyé par dbaffaleuf

Et un SGBD ne peut pas contraindre un développeur à mettre des clés primaires partout, il y a des cas où ça n'a pas de sens (certaines tables de logs).

Je comprends parfaitement ton point de vue. Et je le partage.
Même pour une table de logs je dirai comme toi "ça dépend !"
Quelques soit le niveau du log, je pense que les tables de logs d'application grossissent vite si elles ne sont pas purgées. Et si on utilise ces tables de logs pour faire du reporting, ou rechercher (ou étudier) un évènement particulier sur une période donnée. ça peut être utile d'avoir un PK ?

[dbaffaleuf]

Ce sont les traitements qui pilotent les choix d'indexation, donc oui.

[zinzineti]

Envoyé par SQLpro

Le fait de faire des tables sans clef à été spécifiquement pensé pour la reprise des données. En effet rien ne dit que l'on a pas des doublons dans des fichiers... Or traiter un fichier est souvent plus long que de le faire dans les lignes d'une table.

C'est pourquoi, oui, des tables sans clef sont utile notamment pour des imports voire des exports, voire des tables de log (exemple table de hit d'un site web ou 2 utilisateur peuvent avoir affiché la même page à la même milliseconde).

En sus, une très petite table et qui le restera toujours (exemple, table des sexe, des civilités) sera en principe plus rapide sans aucune clef ni index, car il n'y aura jamais lecture que d'une page, alors qu'avec un index ce sera un minimum de deux !

A +

100 % d'accord. Et c'est logique.

Dans ces conditions on peut donc s’asseoir sur les règles de la normalisation ?

[7gyY9w1ZY6ySRgPeaefZ]

Envoyé par zinzineti

100 % d'accord. Et c'est logique.
Dans ces conditions on peut donc s’asseoir sur les règles de la normalisation ?

Pour les progiciels qui utilisent ce genre de principe - pas de pk ni de fk - c'est vraisemblablement plus du à une ignorance totale de la conception de BD qu'à une réflexion profonde...
Du bricolage de stagiaire du prototype qui perdure car les priorités du développement sont ailleurs...
J'en ai un très beau exemple dans mes bds et c'est une horreur à manipuler car ça craque de partout!

[zinzineti]

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

Pour les progiciels qui utilisent ce genre de principe - pas de pk ni de fk - c'est vraisemblablement plus du à une ignorance totale de la conception de BD qu'à une réflexion profonde...
Du bricolage de stagiaire du prototype qui perdure car les priorités du développement sont ailleurs...
J'en ai un très beau exemple dans mes bds et c'est une horreur à manipuler car ça craque de partout!

C'est justement ce même constat qui m'a motivé à écrire le billet "Montre-moi tes tables et je te dirai ce que vaut ta base ..."

[dbaffaleuf]

Envoyé par zinzineti

Dans ces conditions on peut donc s’asseoir sur les règles de la normalisation ?

Il faut s'asseoir dessus quand ça ne vaut pas le coup, c'est à dire dans les cas isolés que Frédéric a évoqué. Pour le reste, ce n'est pas normal qu'une table métier dans un modèle relationnel n'ait pas été passée à la 1FN.

[Bluedeep]

Envoyé par zinzineti

Et si on utilise ces tables de logs pour faire du reporting, ou rechercher (ou étudier) un évènement particulier sur une période donnée. ça peut être utile d'avoir un PK ?

Ca peut être utile d'avoir un index, mais pas forcément une PK.

[SQLpro]

Non ce serait plutôt le contraire, car sans PK => doublons et supprimer les doublons est une horreur ! Voir impossible sans changer la structure de la table....

Or une PK créé un index...

A +