Les colonnes d'identité ou UDF qui génère explicitement un identifiant unique?

Question

Je suis au milieu d'un débat pour savoir s'il est préférable de faire un PRIMARY KEY sur un Colonnes identité , notre d'un UDF qui génère explicitement une expérience unique id.

• Je défends la colonne d'identité.
• Mon partenaire plaide pour générer les valeurs manuellement, il prétend
  • en mettant l'UDF sur une autre table où l'on peut avoir une UDF
    • verrouiller la ressource
    • incrémenter une table d'identité avec un champ appelé ID_Value par 1
    • utiliser comme identifiant unique global
  • Ou avoir la table faire une id+1 lors de l'insertion
  • Qu'il est plus simple de déplacer les données entre les serveurs et / ou les environnements ne présentant pas l'identité de contrainte; passer d'une base de données où il existe des données à une autre base de données similaire avec la mise en scène permet de dire ou des données fictives. Pour tester la non production, nous pouvons vouloir tirer tous les enregistrements d'hier jusqu'à la mise en scène pour les tests.

Quelle mise en œuvre est plus logique?

Answer 1

Votre collègue est un idiot.

La solution ne sera pas évolutive, l'UDF ne coïncide pas ( même raison que cette ). Et comment gérez-vous avec des inserts multi-lignes: cela nécessiterait un appel UDF par ligne

Et la migration vers d'autres SGBDR ne se produit pas souvent dans la vie réelle ... vous pouvez aussi bien utiliser SQL Server ne maintenant et les séquences d'utilisation sur Oracle et espère que vous ne migraient pas, loin.

Edit:

Vos états de mise à jour des données en mouvement est pour rafraîchir les bases de données non-production.

Dans ce cas, vous ignorez les colonnes d'identité lors de l'actualisation. Vous ne compromettez pas votre mise en œuvre pour faciliter le chargement non prod plus facile. Ou tables utilisent temp pour suivre les changements de valeur d'identité.

Ou les processus d'utilisation: nous renouvelons notre système de test tous les soirs de la production qui évite la question tout à fait. (Et assure notre sauvegarde prod peut être trop restauré)

Answer 2

Utilisez une valeur d'identité. Générez votre propre table de séquence et les valeurs séquence prendra beaucoup de frais généraux et causer beaucoup de verrouillage et de bloquer tout en essayant de générer des nombres.

Identité existe pour une raison, l'utiliser.

Lorsque SQL Denali sort, il soutiendra des séquences qui seront plus efficaces que l'identité, mais vous ne pouvez pas créer quelque chose de vous-même plus efficace.

En ce qui concerne le déplacement des enregistrements d'un environnement à l'autre, soit tourner identity_insert lorsque vous faites l'insert, ou cocher la case SSIS.

Answer 3

La colonne d'identité sonne bien pour moi. Je ne suis pas sûr que je suis la logique de savoir pourquoi il est difficile de déplacer les données entre les serveurs.

Si vous ne voulez chaque ligne d'avoir une identité unique au monde, vous pouvez utiliser un UUID mais je ne le ferais pas, sauf si vous êtes sûr que l'unicité globale est nécessaire - en général ce n'est pas. En utilisant UUID comme ids diminuera les performances, les exigences d'espace disque d'augmenter et de rendre le débogage plus difficile -. En raison de la longueur, il est difficile de se rappeler un UUID, dites à quelqu'un au téléphone, ou l'écrire sur le papier sans erreur

Answer 4

Pour les ID numériques simples, rendez-vous avec l'identité et d'oublier tous les problèmes de les générer manuellement.

Vous pouvez toujours créer une « table super » qui utilise une identité en tant que PK et une colonne de type, et toute autre information. Lorsque vous avez besoin d'un nouvel ID (en supposant que vous voulez dire IDS uniques à travers des tables différentes) il suffit d'insérer dans cette table et prenez la SCOPE_IDENTITY() puis insérez dans la table réelle dont vous avez besoin.

Fondamentalement, vous créez une table: MasterIDs avec un PK identité, lorsque vous avez besoin d'insérer une ligne dans votre tableau 1, INSERT INTO MasterIDs et obtenir l'identité générée par cette ligne à l'aide SCOPE_IDENTITY() puis insérer dans Tableau 1 en utilisant cette valeur comme PK.

Tableau 1 un int non-identité PK. Vous feriez le même procédé pour insérer dans Tableau2, etc. Soit SQL Server gérer les valeurs d'identité dans le MasterIDs table, que vous pouvez ensuite utiliser dans vos autres tables. MasterIDs peut contenir d'autres tables, comme le type (vous pouvez donc savoir quelle table, ou Tableau 1 Tableau 2, etc., utilise cette valeur d'identité.

Answer 5

Tant asyou utilisent des contraintes de clés étrangères correctement (en cascade, mise à jour, etc.), alors vous serez très bien avec l'aide d'un champ d'identité. Je ne vois vraiment pas un avantage à l'autre solution dans ce cas.

Answer 6

Identité a été faite pour adapter à votre scénario. Vous avez des outils tels que la réplication pour l'échange de données serveur / environnements qui maintiennent tous ensemble.

Answer 7

Je viens de terminer un travail où je l'ai remplacé une colonne de identity SQL Server avec un champ de int normale et contrôlée allocation Id moi-même.

J'ai vu des gains de performance assez impressionnant. Contrairement à l'OP, je n'ai pas une UDF pour générer l'identifiant. Mais le principe est à peu près la même chose: Il fait partie du logiciel qui maintient un pool de numéros d'identification. Quand ils courent, il obtient un autre lot en interrogeant la base de données pour la prochaine Low valeur et incréments ce à l'autre High .

Ceci nous permet de générer ids et relions toutes les entités en dehors d'une transaction dans notre ORM avant de présenter les lots à la base de données et également soumettre plus gros lots sans allers-retours supplémentaires pour obtenir l'identité simplement insérée (nécessaire par des colonnes d'identité).

Dans le tableau identifiant nous il y a plus d'une ligne, ce qui nous permet d'utiliser des gammes spécifiques de si l'on veut. à savoir pour la réutilisation de blocs supprimés et ids négatifs.

Answer 8

Je me sers de l'identité depuis des années et envisage sérieusement de remplacer le numéro d'identité avec UNIQUEIDENTIFIER. Il est un cauchemar quand vous avez besoin de changer le type de données si quelqu'un a conçu pour être compact et db cauchemar si vous avez besoin d'ajouter l'identité à une colonne, également, vous ne pouvez pas mettre à jour la colonne d'identité. Imaginez que vous mettez un int et votre base de données croît au-delà 2milliards records, nouveau cauchemar pour le changement (pensez FKs)! Rien changer avec l'identité est un cauchemar et pas à l'échelle amicale à moins que vous mettez bigint! UNIQUEIDENTIFIER vs Identité = confort et robustesse vs peut-être notable amélioration des performances (n'a pas fait de référence).

Mise à jour: Après que je l'ai vu ce Je me penche vraiment vers UNIQUEIDENTIFIER. Cela montre pas de véritable avantage de l'identité bigint et un tas d'avantages pour UNIQUEIDENTIFIER! Les différentes versions de SQL Server pourraient avoir un résultat différent. Il y a juste la beauté d'avoir un identifiant unique dans toutes les bases de données et systèmes (robustesse)! Déplacer, copier, transformer les données que vous s'il vous plaît! https://www.mssqltips.com / sqlservertip / 5105 / sql-server-performance comparaison int-contre-guid /