Est-ce une façon standard de concevoir une base de données?

J'ai récemment appris comment les relations sont définies dans la base de données au travail et je me demandais s'il s'agissait d'une pratique standard.

Supposons que nous ayons deux processus: le processus A et le processus B. Le processus B dépend des résultats du processus A, il existe donc une relation qui doit être définie entre une exécution du processus B et une exécution du processus A. Voici comment la relation est définie:

TableProcessA:
Id

et

TableProcessB:
Id
ProcessAId

Jusqu'à présent, les choses ont du sens pour moi, mais les choses deviennent un peu étranges pour moi et ma compréhension de la conception des tables. Chaque fois qu'une ligne est créée dans TableProcessA ou TableProcessB, une fonction est appelée qui crée un identifiant globalement unique pour chacune. Donc, fondamentalement, tous les champs Id de TableProcessA et TableProcessB ne contiendront aucune correspondance car les ID ne sont pas seulement uniques à sa table, mais à toute la base de données.

Ma question est, quelle est la norme? J'ai été amené à l'idée que chaque table devrait simplement avoir un identifiant d'auto-incrémentation qui est unique à la table et non à la base de données entière.

Ce n'est pas une pratique aussi étrange. Ceux-ci sont appelés GUID ou ID globaux uniques. L'idée est que, étant donné un GUID, vous pouvez dire exactement à quelle pièce de données l'ID appartient, car il sera unique partout . Les GUID sont mieux utilisés lorsque vous fusionnerez différentes sources de données similaires; par exemple l'inventaire pour différents magasins.

Je ferais des recherches et découvrirais pourquoi c'est une pratique courante dans votre environnement. Peut-être que c'est nécessaire, peut-être pas.

En principe, avoir des identifiants uniques dans une base de données n'est pas trop mauvais mais c'est plutôt inhabituel dans mon expérience. À moins qu'il n'y ait une exigence spécifique pour le maintien d'une clé d'identification unique au monde, l'utilisation de l'identité normale devrait être correcte car les types d'entité ou les objets ont tendance à être spécifiques au type et n'entraînent généralement pas de jointures inappropriées.

En aparté à votre question, je vous suggère fortement de ne pas utiliser les GUID comme clés primaires ou de substitution car elles occupent 4x l'espace d'un int. À l'époque des disques de plusieurs gigaoctets, vous pourriez dire que ce n'est pas important, mais lorsque vous avez quelques millions de lignes de données, il faut toujours des ressources pour lire à partir du disque ou les transférer sur un réseau, d'autant plus si elles sont incluses dans des index. Pendant que je suis sur les index des sujets, les GUID sont mauvais dans les clés primaires en raison de leur nature aléatoire et provoquent généralement une fragmentation importante.

Maintenant, il est probablement trop tard pour cette base de données, mais gardez cela à l'esprit pour l'avenir

Vos processus peuvent créer des enregistrements qui contiennent le GUID comme référence à l'instance de processus, mais l'utilisation des GUID comme clé n'est pas nécessairement optimale.

Je vois trois principaux inconvénients de l'utilisation des GUID comme clés de base de données et je les éviterais à moins que vous n'ayez une raison impérieuse de les utiliser. Notez que la propriété globalement unique ne vous procure aucun avantage par rapport à l'utilisation d'une clé qui est localement unique dans une table, car vous savez déjà de quelle table proviennent les données.

Inconvénient: il n'est pas très facile de saisir un GUID si vous souhaitez effectuer une requête ad hoc sur la base de données, par exemple:

select *
  from Foo
 where FooID = 12345

contre

select *
  from Foo
 where FooID = convert (uniqueidentifier, '5E64E653-35F0-4803-B459-F5F59C701F22')

Ce dernier signifie pratiquement que vous avez besoin d'une source du GUID pour couper et coller.

2. Ordinalité naturelle: une clé primaire à auto-incrémentation a pour effet secondaire de classer naturellement vos transactions dans l'ordre dans lequel elles ont été entrées dans le système. C'est souvent très utile. Les GUID ne sont normalement pas générés dans l'ordre, ils ne sont donc d'aucune utilité à cet égard.

3. Taille: moins un problème de nos jours, mais un GUID fait 16 octets de long. Il prend plus d'espace dans la table et tous les index qui l'incluent.

Je ne dirai pas que c'est normal, mais ce n'est pas anormal non plus de configurer les choses de cette façon.