Quelle est la taille appropriée pour une clé primaire générée par une séquence?

Question

Actuellement, les clés primaires de notre système ont une longueur de 10 chiffres, un peu plus que la limite autorisée pour les entiers Java. Je souhaite éviter les problèmes de maintenance ultérieurs causés par le débordement numérique de ces clés, mais je ne souhaite pas non plus sacrifier une grande partie des performances du système pour stocker des quantités infiniment importantes dont je n'aurai jamais besoin.

Comment gérez-vous la gestion de la taille d'une clé primaire? Suis-je mieux de rester avec les entiers Java, pour des performances supérieures à Long, et pour augmenter la taille si nécessaire, ou devrais-je mordre la balle, utiliser Java Long pour la plupart de mes PK, et ne jamais avoir à craindre de déborder taille de la séquence?

Answer 1

Je suis toujours allé avec de longues clés (nombre (18,0) dans la base de données) car elles suppriment simplement la possibilité que cette situation se produise dans à peu près toutes les situations (mises à part les applications de style de stockage de données extrêmes). Avoir le même type de données dans toutes les tables pour la clé signifie que vous pouvez partager ce champ avec tous vos objets de modèle dans une classe parent, en plus d'avoir un code cohérent dans vos getters SQL, etc.

.

Answer 2

Il semble que la réponse dépend de la probabilité que vous dépassiez les entiers Java avec vos données. Et il n’ya aucun moyen de le savoir sans une certaine idée de la nature de vos données.

Answer 3

Les performances étant négligeables, mon conseil est d’aller avec les clés longues. Le fait de devoir faire face à cela plus tard serait probablement un problème majeur.

Answer 4

Il s'agit d'un équilibre entre le coût de stockage et d'utilisation des entiers longs et la probabilité de déborder d'un entier 32 bits.

Considérez qu’un entier 32 bits non signé stocke plus de 4 milliards de valeurs. Si vous pensez que vous allez avoir en moyenne plus d’une nouvelle ligne par seconde dans ce tableau pour les 136 prochaines années, vous devez utiliser une valeur Long.

Answer 5

Les entiers 32 bits en java sont des entiers signés, soit 2 milliards seulement. Si, pour une raison quelconque, votre SEQUENCE continue de sauter de temps en temps, il y aura des écarts entre vos PK.

Cela ne fait pas mal d’avoir une longue période (rappelez-vous que le problème de l’an 2000 est dû au fait que certains développeurs COBOL pensaient qu’ils économiseraient des octets dans les dates ??): -)

Par conséquent, j'utilise toujours Long.