Augmenter la taille de l'incrément pour correspondre à l'avantage du GUID

Question

Je pensais mettre en œuvre ce système, mais je ne peux pas m'empêcher de penser qu'il y a un piège quelque part. L’un des avantages de l’utilisation du GUID sur l’incrémentation est qu’à l’avenir, si vous fusionniez des bases de données, il n’y aurait pas de conflit entre la clé / l’identifiant principal. Cependant, mon approche consiste à définir la taille de l'incrément sur X, X étant le nombre de serveurs que j'aurai le plus probablement à l'avenir. Ensuite, sur chaque serveur, faites en sorte que la graine soit incrémentée du numéro de graine sur le serveur précédent. Ainsi, lors de la fusion, il n'y aurait pas de conflit avec la clé primaire. Est-ce une méthode sûre et normale ou suis-je devenu mental :)? Merci

Answer 1

Dans la réplication SQL multi-maîtres, les clés primaires sont généralement définies comme suit:

• GUID
• int est avec une taille d'incrémentation > nombre d'installations
• int est avec un décalage fixe

L’inconvénient des GUID est qu’ils peuvent être plus difficiles à lire et occuper un peu plus d’espace. Cependant, cela vous permet d’évoluer vers n instances.

Les entiers sont un peu plus faciles à gérer. Ils ont également l’avantage de pouvoir dire facilement quel serveur a créé un enregistrement. L'inconvénient est que vous devez prédire le nombre maximal de bases de données pouvant être fusionnées ou deviner le nombre maximal de lignes qu'une seule instance peut insérer.

Voici un exemple de décalage fixe: le site A commence à 0, le site B à 1 000 000 et le site C à 2 000 000. Ce schéma fonctionne bien jusqu'à ce qu'un site insère un million de lignes. Ce système pourrait bien fonctionner pour les voitures chez les concessionnaires automobiles, où il est peu probable qu'un revendeur unique vende jamais plus de 1 000 000 de voitures, et vous pourriez avoir des centaines de concessionnaires pendant la durée de l'application.

Answer 2

Ce qui me fait peur ici, c’est votre utilisation de "très probablement". Vous envisagez l'avenir, et ce n'est généralement pas une bonne chose à faire avec ce genre de choses. Pourquoi ne pas utiliser un GUID?

Et si vous ajoutiez un serveur supplémentaire à ce que vous pensiez avoir? Je pouvais voir les choses se compliquer vraiment très vite.