SQL Server fournit le type [Rowguid]. J'aime utiliser cette clé primaire unique pour identifier une ligne de mise à jour. La prestation apparaît si vous déchargez la table et rechargez-le, pas de désordre avec des colonnes Serialno (identité).
Dans le cas particulier des bases de données distribuées telles que les copies hors ligne sur des ordinateurs portables ou quelque chose comme ça, rien d'autre ne fonctionne.
Que pensez-vous? Trop de frais généraux?
4 Réponses :
Le problème avec RowGuid est que si vous l'utilisez pour votre index en cluster, vous finissez par ré-calculer constamment vos pages de table pour des inserts d'enregistrement. Un GUID séquentiel (SEWNELIENTICIEND ()) fonctionne souvent mieux.
Intéressant mais ne fonctionne pas complètement car, selon la documentation de MSDN, le GUID séquentiel n'est que séquentiel de la dernière fois que l'ordinateur a commencé et créera des valeurs inférieures à l'avenir.
Notre application hors ligne est utilisée dans les succursales et nous avons une base de données centrale dans notre bureau principal. Pour synchroniser la base de données dans la base de données centrale, nous avons utilisé la colonne Rowguid dans toutes les tables. Peut-être qu'il y a de meilleures solutions mais c'est plus facile pour nous. Nous n'avons rencontré aucun problème majeur jusqu'à la date des 3 dernières années.
comme une clé primaire Étant donné que le GUID est par définition aléatoire, vous aurez une fragmentation d'index horrible et donc vraiment vraiment de mauvaises performances sur insertion, mise à jour, supprimer et sélectionner des déclarations.
Également, puisque la clé de clustering est ajoutée à chaque domaine de chaque index non clusterné de votre table, vous gaspillez beaucoup d'espace - à la fois sur le disque et dans la RAM du serveur - lorsque vous utilisez. GUIB 16-BYTE VS. 4-BYTE INT.
Donc: Oui, comme clé primaire, un RowGuid a ses mérites - mais si vous l'utilisez, évitez certainement d'utiliser cette colonne comme clé de clustering dans la table! Utilisez une identité int () ou quelque chose de similaire pour cela.
Pour une clé de clustering, idéalement, vous devez rechercher quatre caractéristiques:
Int identité () convient parfaitement à ce besoin. Et oui - la clé de clustering doit être unique puisqu'il est utilisé pour localiser physiquement une ligne de la table - si vous choisissez une colonne qui ne peut être garantie d'être unique, SQL Server ajoutera en réalité un joueur de quatre octets à votre clé de clustering. - Encore une fois, pas quelque chose que vous voulez avoir ....
Rowguid comme le La clé de clustering est une très mauvaise idée. Voir l'excellent GUID) En tant que clé primaire et / ou de clustering article pour des raisons approfondies pour lesquelles ne pas utiliser GUID pour le regroupement.
La taille du GUID ne devrait pas être un problème ici. En réponse directe à la question, il n'y a rien d'extra offert ici, à l'exception d'un "N'oubliez pas de choisir un autre index en clustered". Étant donné que le RowGuid est également l'ID de ligne interne, il ne devrait y avoir aucun espace gaspillé car la cible de l'index (l'ID de la ligne) sera écrite de toute façon. Ou existe-t-il une limitation / manque d'optimisation signifiant que MS doit écrire le GUID deux fois dans l'index, même lorsqu'il s'agit du RowGuid? J'en douterais, mais s'il vous plaît clarifier si vous savez autrement.
@Codechief: La taille de la clé de clustering est est très beaucoup un problème dans SQL Server! Cela devrait vraiment être aussi petit que possible, car il est également inclus dans Tous les index non clusters sur la même table. 4 octets vs. 16 octets font une différence énorme si vous avez 100 millions de lignes et 15 index non clusters!
Si ce n'était pas clair, je suggère vraiment que cela n'a rien à voir avec des indices en cluster! Si vous devez alors faire défaut de défaut () comme documenté dans MSDN et déjà répondu par d'autres personnes ici. Quoi qu'il en soit en train de parler de vastes bases de données, s'ils sont destinés à de grands clients et que vous devriez planifier l'évolutivité ou avoir une exigence très disponible, ce qui ramène à l'adresse Rowguid.
Cela le fait, car la clé primaire par défaut est également la clé de clustering de SQL Server ... et une grande majorité de DB Devs ne se soucient même pas de la différence entre la clé principale et la clé de clustering .... donc il le fait question...
Nous reviendrons donc à mon premier point, c'est juste un avertissement pas quelque chose de mal avec Rowguid lui-même. De plus, de MSDN, ils vous disent qu'il n'y a pas de relation inhérente entre l'option de colonne Rowguid et être une clé primaire, vous devez réellement définir cela sur la colonne explicitement. Il suffit de redépercuter avec SSMS 2012 et assurez-vous qu'il n'est pas défini sur la clé primaire par défaut à l'aide de l'interface graphique (lors de la définition de l'option RowGuid sur YES dans la fenêtre Propriétés) et de T-SQL. Le seul moyen de recevoir une clé principale consiste à définir cette option d'interface graphique distincte ou en ajoutant explicitement une contrainte de clé primaire dans TSQL.
Ceci est la bonne réponse, mais il y a une autre solution - vous pouvez utiliser une technique de peigne pour vous assurer que vos touches de guidage augmentent de manière séquentielle. (Voir Github.com/Richardtallent/rt.comb pour ma mise en œuvre, par exemple. ) La règle «aussi petite que possible» est toujours une bonne règle de base, la différence entre un GUID et un 32 ou 64 bits Int n'a pas d'importance autant qu'il y a presque 10 ans. YMMV, mais j'utilise des peignes pour bien plus de dix ans, sans différence de performance notable contre mes tables INT-PK.
Contrairement à la réponse acceptée, le type de données crédentifier dans SQL Server est en effet un bon candidat à une clé de clustering primaire; Tant que vous le gardez séquentiel.
Ceci est facilement accompli à l'aide de la valeur par défaut de la colonne.
Si vous lisez effectivement Si vous avez de grandes lignes avec peu d'index, plus d'octets supplémentaires dans un GUID peuvent être négligeables. Assurez-vous que le problème des composés si vous avez des lignes courtes avec de nombreux index, mais c'est quelque chose que vous devez peser en fonction de votre propre situation.
Utilisation des informations sur le caractère unique séquentielles a beaucoup de sens lorsque vous allez utiliser la réplication de la fusion, surtout lorsqu'il s'agit de semis d'identité et des malheurs qui s'ensuivent.
Le stockage CALS Server n'est pas bon marché, mais je préfère disposer d'une base de données qui utilise un peu plus d'espace que celui qui crie à une halte lorsque vos gammes d'identité automatiquement attribuées se chevauchent.