De manière générale, une clé à incrémentation automatique n'entrera pas en collision; en fait, je ne sais pas comment y arriver (puisque la plupart des définitions dans SQL incluent une contrainte Unique). Vous pourriez obtenir des erreurs duplicate key, cependant. Pourquoi laissez-vous les fournisseurs extérieurs dicter quelles sont vos clés internes? Acceptez un enregistrement terminé et générez les clés vous-même. Si vous n'avez plus de clés, augmentez la taille de la colonne (à long). Vous pouvez générer une nouvelle colonne GUID, oui, mais vous générez probablement toujours les GUID, alors quelle serait la différence?
Souvent, la plupart des tables d'une base de données possèdent plusieurs clés 'uniques'. Ce sont les clés «naturelles» - les colonnes réelles qui constituent un ensemble de données unique; malheureusement, cela peut finir par être toute la largeur de la table (c'est pourquoi les colonnes id sont utilisées). De même, à moins d'un cas d'utilisation bizarre, ne faites pas connaître au serveur les identifiants des clients - informez les clients des identifiants des serveurs et gardez-les dans une colonne séparée (si nécessaire) sur le client. Puis peuvent alors avoir leurs propres identifiants internes qu'ils utilisent avant le téléchargement, qui n'ont aucun rapport avec les clés que vous redonnez - et qu'ils ne partagent jamais avec le serveur.
Peu importe l'identifiant du serveur (int ou un GUID), même si je vous recommande de conserver ce que vous avez. Chaque fois que le client vous donne une rangée à mettre sur le serveur, donnez-leur l'identifiant généré par le serveur. Cela empêche les clients de tenter d'insérer des identifiants déjà utilisés, et des problèmes connexes (comment savez-vous que l'identifiant qu'ils vous ont donné ne devrait pas avoir été généré par un autre périphérique?). Je dirais que les clients ne reçoivent pas de dicter ids internes sur le serveur
EDIT:
À la lumière de quelques recherches rapides dans la réplication (en réponse à HLGEM), et en relisant la question initiale; J'ai d'abord pris la question comme demandant de laisser les clients dicter les clés primaires internes (ce qui est encore mauvais), et/ou en remplaçant les clés primaires int avec le GUID. Bien que vos besoins exacts ne le requièrent pas, l'ajout d'une colonne GUID supplémentaire que le client peut remplir fonctionnerait. Quelques recommandations:
1) Traiter les violations clés uniques (accidentelles ou malveillantes) sur la colonne GUID comme une exception entreprise, pas un système exception. Je recommanderais probablement au client de recréer le GUID et de le soumettre de nouveau (en silence). 2) Le client jamais n'arrive à dicter les valeurs de colonne de clé primaire acutal dans la base de données.En fait, si vous utilisez une colonne GUID, le client peut même ne jamais avoir besoin de savoir à leur sujet.
De manière générale, une clé à incrémentation automatique ne va pas entrer en collision; en fait, je ne sais pas comment y arriver (puisque la plupart des définitions dans SQL incluent une contrainte 'Unique'). Vous pourriez obtenir des erreurs 'duplicate key', cependant. Pourquoi laissez-vous les fournisseurs extérieurs dicter quelles sont vos clés internes? Acceptez un enregistrement terminé et générez les clés vous-même. Si vous n'avez plus de clés, augmentez la taille de la colonne (à long). Vous pouvez générer une nouvelle colonne GUID, oui, mais vous générez probablement toujours les GUID, alors quelle serait la différence? –
Eh bien parce qu'ils seraient dans un environnement déconnecté, c'est-à-dire sur des appareils mobiles dans lesquels ils ont leur propre copie d'un sous-ensemble de leurs données et la possibilité d'ajouter des enregistrements - si vous ajoutez ou mettez à jour des enregistrements raison d'envisager d'utiliser le GUID pour le processus de synchronisation et de synchronisation. – TheTiger
Je vois où vous allez avec le 'Accepter l'enregistrement complété d'eux' bien que j'ai encore besoin d'un processus de correspondance - ie je dois redonner au client quelque chose pour l'enregistrement - un ID (ne peut pas utiliser un INT car il pourrait entrer en collision - comme J'ai des milliers de clients potentiels qui font tous des insertions sur leur propre sous-ensemble et sycning à la base de données centrale (alors que la base de données centrale fait également des insertions directement) – TheTiger