2017-06-09 3 views
2

Je travaille actuellement avec une base de données d'environ 10 000 enregistrements et de plus en plus. C'est une base de données avec des journaux de maintenance sur lesquels j'effectue des analyses pour extraire des données sur la maintenance. Les résultats de l'analyse sont stockés dans la même base de données dans une table différente.Réinitialisation de l'ID d'enregistrement de base de données après suppression

table entretien

:

------------------------------------------ 
|id  remainingdata 
|1  testing 
|2  alsotesting 
|3  testing1 
tableau

résultats d'analyse:

------------------------------------------ 
|id  maintenanceid  remainingdata 
|1  1     result1 
|2  1     result2 
|3  2     result3 
|4  3     result4 
|5  3     result5 

Les journaux de bord peuvent être mis à jour après l'analyse a été réalisée, pour cette raison, l'analyse peut se faire à nouveau. Lorsqu'un enregistrement de maintenance est réanalysé, tous les enregistrements de l'analyse (qui contiennent une clé étrangère dans l'enregistrement de maintenance) sont supprimés de la table et réintroduits. Alors disons que je ré-analyse tous les 3 dossiers de maintenance. Ma table de résultats ressemble maintenant à ceci;

------------------------------------------ 
|id  maintenanceid  remainingdata 
|6  1     result1 
|7  1     result2 
|8  2     result3 
|9  3     result4 
|10  3     result5 

Le problème que je suis face est que lorsque les enregistrements 10.000+ sont supprimés et sont entrées possibles par semaine, le nombre très élevé AUTO_INCREMENT obtient très rapidement. Et puisque je veux mettre à l'épreuve ma base de données, j'ai besoin de trouver une solution à ce problème. REMARQUE: les identifiants de la table des résultats sont uniquement utilisés pour conserver les doublons, il n'y a aucune référence dans les autres tables.

J'ai pensé à deux solutions possibles à cela moi-même, à la fois avec des hauts et des bas pour eux;

  1. Modifier le Pk à un BIGINT et espère qu'il ne marche pas frappé valeurmax

Bien que la valeur maximale est très grande, il y a toujours un risque de toucher à l'avenir et je ne Je veux vraiment avoir ce risque.

  1. Lors de la suppression de tous les enregistrements, réinitialiser le AUTO_INCREMENT au TOP(id)

Cela semble la meilleure solution pour moi, mais je suis intéressé s'il y a des arguments contre , cela réinitialiserait la valeur de l'id à l'ID max actuellement dans le tableau, si tous les enregistrements sont ré-analysés, il reviendrait à 1.

Je me demande ce que les opinions sur mes solutions sont ou si quelqu'un a une meilleure solution à ce problème. Merci d'avance

+0

Vous ne pouvez pas utiliser l'option TRUNCATE TABLE pour réinitialiser la colonne AUTO_INCREMENT? – Sujith

+0

@Sujith tous les enregistrements ne sont pas toujours supprimés, parfois juste 1 ou 2 –

Répondre

1

Optez pour la solution BIGINT. Vraiment.

Un non signé BIGINT peut hold numbers aussi grand que 9223372036854775807.

Avec le taux prévu de 10k par semaine, cela signifie que votre application est la preuve future pour 922337203685477 semaines, ou 17737253917028 ans, ou la vie des personnes 221715673962 séquentiellement, avec l'âge prévu d'environ 80 ans par personne. C'est environ trois fois la population mondiale.

il y a encore un risque de toucher à l'avenir et je ne veux pas vraiment avoir ce risque

Vous pouvez être tout à fait sûr que lorsque la limite est atteinte, votre vie est finie , et la tâche de résoudre le problème est pour quelqu'un d'autre.