clé primaire entière pour la réplication

Je pondère mes options pour les clés primaires entières pouvant être utilisées dans la réplication multi-maître. (Je suis vendu à l'aide de clés entières au lieu de GUID)clé primaire entière pour la réplication

Le meilleur que je peux trouver est d'avoir les données les plus significatives en premier et ayant le dernier numéro de serveur: par exemple. facture 1 sur le serveur 1 = 101 facture 1 sur le serveur 2 = 102 où la partie non serverno (de InvoiceNo) provient d'un numéro de db générateur

algorithmiquement: gen_id (INVOICENO_GEN, 1) * 100 + serverno et vous pouvez obtenir le numéro de serveur en regardant à la fois la valeur et mathématiquement.

Ce qui laisse de la place pour 99 serveurs tout en restant court et lisible et n'entrera pas en collision. L'utilisation de ce schéma et de la colonne de taille entière normale ferait les lignes max (21 474 836) ou si bigint est utilisé plusieurs milliards.

par exemple les clés de table de la facture se présente comme suit:

Donc, ma question est la suivante: toutes les critiques ou les défauts que j'ai oublié?

La base de données est Firebird.

Source

2009-10-14 AngelBlaZe

Que diriez-vous juste de créer une clé primaire composite?

Définissez un "ServerID" pour définir sur chaque serveur, par ex. 1, 2, 3, 4 etc. comme INT. Ayez ensuite le "InvoiceID" comme INT sur votre table de facture.

Créez la clé primaire à être (ServerID, InvoiceID). De cette façon, vous avez suffisamment de place pour plus de 99 serveurs, et vous n'avez pas besoin de manipuler/calculer les ID ou quoi que ce soit de ce genre. Bien sûr, n'importe quelle table référençant votre table Facture doit maintenant utiliser (ServerID, InvoiceID) comme clé étrangère, mais je suppose que le fait d'avoir le ServerID partout dans vos tables ne sera pas un problème si vous avez besoin pour reproduire ces tables, aussi.

Marc

Source

2009-10-14 16:48:23

Je ne voudrais pas introduire une clé composite pour cela. Pour un, les clés composites sont un PITA à traiter, et il ne semble pas qu'il s'intéresse réellement à la mise en relation de ces données en fonction des informations supplémentaires. –

La plupart de notre code et les bibliothèques que nous utilisons sont optimisés pour une utilisation avec une seule clé primaire. Donc, une clé primaire composite est la "bonne" réponse du point de vue de la base de données, mais pas du point de vue du développement. – AngelBlaZe

juste pour clarifier nous aurons une colonne serverno aussi bien à des fins d'interrogation. Nous n'avons pas de colonne invoiceno (sans le serverno) car c'est ce que nous voulons imprimer sur les factures, les recherches, etc. – AngelBlaZe

En général, ne pas utiliser les types numériques pour tout ce qui est pas un nombre. Traiter les chiffres avec une signification spéciale fait que vos chiffres ne sont plus strictement numériques. Une chaîne est généralement plus adaptée aux scénarios de ce type où vous souhaitez ajouter des données spécifiques à l'environnement (généralement pour la réplication).

Source

2009-10-14 16:49:09

Eh bien, nous n'avons pas l'intention d'utiliser les chiffres incorporés, par exemple. dans les requêtes. C'est juste un moyen de séparer plusieurs valeurs d'incrémentation similaires à changer l'étape ou le début du générateur. – AngelBlaZe

mais vous faites un bon point. Devra faire quelques benchmarks pour voir si une clé primaire entière est vraiment un gros gain ou pas. – AngelBlaZe

clé primaire entière pour la réplication

Répondre

Questions connexes