MS SQL Server
  1. MS SQL Server
  3. Utilisation du schéma de encoding personnalisé au lieu du GUID comme key primaire
Intereting Posts
UPDATE colonne pour une grande table avec une seule valeur Entity Framework IsRowVersion () sans vérification de concurrency Requête pour étoffer les loggings en double dans SQL Server? Récupère les "users connectés" de la "table d'historique de connection" (simulation de session) Gérer une énorme quantité de données en utilisant Java EE Comment afficher les journaux de transactions dans SQL Server 2008 Limite supérieure de la key primaire d'auto-incrémentation dans SQL Server Filtrage de plusieurs dates en ligne avec des parameters facultatifs vers et depuis Bibliothèque de synchronisation du système de files? Comment puis-je forcer SQL Server à reconnaître un nouveau count de machine de domaine? Pourquoi ma nouvelle relation FK n'apparaît-elle pas dans l'explorateur d'objects? Insérer des lignes NULL dans SQL lorsque des données sont manquantes T-SQL Affichage des données dans une colonne sur la condition / datatables d'une autre colonne Comment détecter les fuites de connection SqlServer dans une application ASP.net? FullText dans une vue indexée – Population incrémentielle

Utilisation du schéma de encoding personnalisé au lieu du GUID comme key primaire

Je migre une database MS Access backend vers SQL Server. Le client frontal restra pour le moment une application Access (environ 30k lignes de code).

L'objective est de permettre éventuellement la synchronisation de la database sur plusieurs servers (sans utiliser la réplication, mais probablement le framework de synchronisation).
Actuellement, toutes les keys primaires dans les tables Access sont des substituts d'entiers auto-incrémentés.

Je ne parle pas du process de migration, mais de savoir si je devrais utiliser GUID ou une autre codification pour le PK (je sais que je pourrais split la plage de numéros sur les servers, mais je ne veux pas faire cela et permettre au PK d'être créé sur le client si nécessaire, par exemple en mode hors ligne).

GUID

Pro:

  • format standardisé.
  • Unicité assurée (pratiquement de toute façon)

Les inconvénients:

  • pas facile à manipuler dans Access, surtout quand on les utilise comme filters pour les sous-formulaires ou dans les controls.
  • dégrader les performances INSERT en raison de leur caractère random.
  • a plus d'une représentation: string, forme canonique, binary qui doit être converti.

Schéma de codification personnalisé

Je pensais que peut-être un schéma utilisant un code plus uniforme comme PK éviterait la pénalité de performance et, surtout, assurerait que le PK rest utilisable dans les controls de formulaire si nécessaire (et ne nécessite pas ces conversions vers / de string).

Mon idée d'un schéma de codification serait le long d'un code de 10 caractères divisé en:

  • 8 numbers pour un horodatage
  • 4 numbers pour un identifiant client unique
  • 2 numbers comme un nombre random pour les colisions potentielles Chaque chiffre serait en base 34, composé de lettres de AZ et 2-9, en évitant O , 0 , 1 , I raison de leur similitude (au cas où nous aurions besoin de manipuler manuellement ces PK, par exemple pendant le debugging).

Pro:

  • plus facile à manipuler manuellement quand le cas se présente.
  • ne nécessite pas de conversion entre différentes représentations puisque c'est fondamentalement une string (donc less de code existant pour s'adapter).
  • unicité assurée (pratiquement)

Les inconvénients:

  • la performance dans JOIN n'a pas été prouvée
  • la performance dans INSERT devrait être plus rapide que GUID mais pas prouvée
  • Chaque machine server / client doit avoir son propre UID, même si cela ne devrait pas poser trop de problèmes.

Donc, devrais-je utiliser GUID ou un autre schéma pour mon PK?

pas facile à manipuler dans Access, surtout quand on les utilise comme filters pour les sous-formulaires ou dans les controls.

-> Access a GUID comme Number-> Replication Identificator. Nous avons une application dans Access avec chaque PK comme GUID et nous n'avons aucun problème avec les filters (et avec les filters pour les sous-images aussi).

dégrader les performances INSERT en raison de leur caractère random.

-> Si vous avez un problème de performance basé sur ceci, vous pouvez avoir un index de cluster sur une autre colonne (horodatage par exemple). Mais le server MSSQL a deux fonctions pour générer de nouvelles valeurs GUID – "newid ()" et "newsequenceid ()". Les deuxièmes methods – comme son nom l'indique – génèrent de nouvelles valeurs en séquence, de sorte que le problème de performance d'insertion ne doit pas se produire.

a plus d'une représentation: string, forme canonique, binary qui doit être converti.

-> son "PRO" à mes yeux :). Mais pour les users-développeurs et les users-admins est dans Access et MSSQL représenté et consommé sous forme de string ..

Le GUID est dans le kernel "seulement" le nombre 128bit. Je ne pense pas que vous devriez vous soucier de l'efectivité des JOINs sur les colonnes GUID. Les colonnes GUID de jointure sont beaucoup plus efficaces que les conditions sur les colonnes de text par exemple.

Je ne fais pas de hink Le schéma de codification Custom est une bonne idée, car vous devez résoudre beaucoup de choses. D'autre part, le GUID est utilisé de manière standard et les outils sont prêts à l'utiliser.

Combien de dossiers prévoyez-vous? Bigint n'est-il pas assez gros? Jusqu'à 9,223,372,036,854,775,807 loggings (si vous n'incluez pas les négatifs)

Si c'est seulement pour les insertions, et pas de sélections sur datatables, optez pour n'importe quel schéma, (je dirais toujours bigint ou GUID / uniqueidentifier). Si vous avez besoin de faire des sélections, un int, ou bigint est beaucoup plus rapide que GUID ou tout autre PK personnalisé.