Les clés primaires numériques des enregistrements supprimés dans une base de données sont-elles réutilisées pour de nouveaux enregistrements futurs?

Question

Par exemple, si j'ai un champ numéroté automatiquement, j'ajoute de nouveaux enregistrements sans spécifier ce champ et laisse le moteur de base de données le sélectionner pour moi.
Alors, va-t-il choisir le numéro de l'enregistrement supprimé? Si oui, quand?

// SQL Server, MySQL. //

Question complémentaire: Que se passe-t-il lorsque le moteur de base de données n'a plus de chiffres à utiliser pour les clés primaires?

Answer 1

NON. Les clés primaires numériques ne seront pas réutilisées, sauf si vous les spécifiez manuellement (vous devriez vraiment éviter cela!)

Answer 2

À vrai dire, cela pourrait se produire dans MySQL:

Fonctionnement de la gestion AUTO_INCREMENT dans InnoDB :

  

InnoDB utilise le compteur d’incrémentation automatique en mémoire tant que le serveur est en cours d’exécution. Lorsque le serveur est arrêté et redémarré, InnoDB réinitialise le compteur de chaque table pour le premier INSERT de la table, comme décrit précédemment.

après un redémarrage du serveur. Innodb réutilise les valeurs auto_increment générées précédemment. :

  

Solution suggérée:   La table innodb ne doit pas perdre la trace du numéro suivant pour la colonne auto_increment après   redémarrer.

Answer 3

Dépend du système de numérotation automatique. Si vous utilisez une séquence quelconque, le nombre d'enregistrements supprimés ne sera pas réutilisé, car la séquence ne les connaît pas.

Answer 4

En règle générale, non, les chiffres ne sont pas réutilisés.

Toutefois, vous pouvez, dans des produits tels que Oracle, spécifier un générateur de séquence qui effectue un cycle et réutilise les numéros.

Que ce soit le nombre d'enregistrements supprimés ou non, c'est le problème de vos applications.

Answer 5

Il faut préciser cette question:

... "avec les séquences Oracle"

... "avec les colonnes de numérotation automatique MySQL"

... etc ...

Answer 6

Tant que vous créez correctement le tableau, vous ne pourrez pas réutiliser les numéros. Cependant, vous pouvez RESERVER la colonne d’identité (IN MSSQL quand même) en utilisant ce qui suit:

- Entrez le numéro de la dernière entrée valide de la table, pas le prochain numéro à utiliser

DBCC CHECKIDENT ([TableName], RESEED, [NumberYouWantToStartAt])

Ceci est bien sûr fou ... et ne devrait jamais être fait:)

Answer 7

MySQL ne réutilisera pas les ID sauf si vous tronquez la table ou supprimez de la table sans où (dans ce cas, MySQL, en interne , effectue simplement une tronquer ).

Answer 8

Pas spécifiquement. Si la clé est lue à partir d'une séquence ou d'une colonne d'identité auto-incrémentée, la séquence se connectera et produira la valeur suivante. Toutefois, vous pouvez désactiver cette option ( définir identity_insert sur sur SQL Server) et insérer le nombre souhaité dans la colonne, dans la mesure où il ne viole pas la contrainte d'unicité.

Answer 9

Oui, cela dépend vraiment de la façon dont vous générez l'identifiant.

Par exemple, si vous utilisez un GUID en tant que clé primaire, la plupart des implémentations consistant à obtenir un nouveau Guide aléatoire ne risquent pas de choisir un autre guide à nouveau, mais cela lui donnera suffisamment de temps. Si l'insertion ne se trouve pas dans le tableau, Votre déclaration ira bien, mais s'il y a déjà un GUID, vous obtiendrez une violation de contrainte de clé primaire.

Answer 10

Je considère les fonctionnalités de MySQL " " de réutiliser id est un bug.

Pensez à quelque chose comme le traitement des téléchargements de fichiers. Utiliser l'id de la base de données comme nom de fichier est une bonne pratique: simple, aucun risque d'exploitation avec les noms de fichiers fournis par l'utilisateur, etc.

Vous ne pouvez pas vraiment tout transformer en transaction lorsque le système de fichiers est impliqué ... vous devrez valider la transaction de base de données puis écrire le fichier ou écrire le fichier et valider la transaction de base de données, mais si l'une ou les deux échouent, ou vous avez un crash, ou votre système de fichiers réseau a un ajustement, vous pouvez avoir un enregistrement valide dans la base de données et aucun fichier, ou un fichier sans enregistrement de base de données, puisque l'élément n'est pas atomique.

Si un tel problème se produit et que la première chose que fait le serveur lors du retour, c’est écraser les identifiants, et donc les fichiers, des transactions annulées, c’est nul. Ces fichiers auraient pu être utiles.

Answer 11

non, imaginez si votre banque décidait de réutiliser votre account_id - arghhhh !!