PK comme ROWGUIDCOL ou utiliser une colonne distincte de guide de ligne?

9

Il y a un débat de longue haleine ici, alors j'aimerais entendre d'autres opinions.

J'ai de nombreuses tables avec PK en cluster uniqueidentifier. Que ce soit une bonne idée est hors de portée ici (et cela ne changera pas de sitôt).

Maintenant, la base de données doit être publiée par fusion et les DEV préconisent l'utilisation d'une colonne distincte de rowguid au lieu de marquer le PK existant comme ROWGUIDCOL.

Fondamentalement, ils disent que l'application ne doit jamais introduire dans son domaine quelque chose qui est utilisé uniquement par la réplication (ce n'est que du "DBA stuff" pour eux).

Du point de vue des performances, je ne vois aucune raison pour laquelle je devrais ajouter une nouvelle colonne pour faire quelque chose que je pourrais faire avec une colonne existante. De plus, comme il ne s'agit que de "trucs DBA", pourquoi ne pas laisser le DBA choisir?

Je comprends en quelque sorte le point des DEV, mais je ne suis toujours pas d'accord.

Pensées?

EDIT: Je veux juste ajouter que je suis minoritaire dans ce débat et que les DEV qui remettent en question ma position sont des gens que je respecte et en qui j'ai confiance. C'est la raison pour laquelle j'ai eu recours à des avis.
Il se peut aussi que je manque quelque chose et que j'aie mal compris leur point.

sql-server database-design merge-replication spaghettidba
la source
Y a-t-il une chance qu'une valeur PK doive changer à l'avenir?
Robert L Davis
Non, pas vraiment. C'est une clé de substitution, donc l'application ne fait pas grand-chose avec cette colonne. Il ne change jamais et il n'est jamais affiché aux utilisateurs.
spaghettidba
Pourquoi veulent-ils un rowguidcol séparé? Et quel schéma choisiraient-ils en général, s'ils le pouvaient, pour le PK, et pourquoi?
JustinC
@spaghettidba En parlant de domaines croisés, à quelle fréquence leur dites-vous quels modèles de conception ils devraient ou ne devraient pas utiliser dans leur code d'application? Peut-être devraient-ils s'en tenir à leur "domaine"? ;-). En outre, l'ajout d'une colonne de 16 octets à toutes les tables serait horrible pour les performances et n'apporterait aucun avantage.
Solomon Rutzky

Réponses:

7

Fondamentalement, ils disent que l'application ne doit jamais introduire dans son domaine quelque chose qui est utilisé uniquement par la réplication (ce n'est que du "DBA stuff" pour eux).

Je suis complètement d'accord. Mais ... la clé primaire n'est pas seulement utilisée pour la réplication (probablement l'application l'utilise d' une manière ou d' une autre). L'argument n'a aucun sens dans ce contexte.

Dans tous les cas, à ma connaissance, il n'y a que 2 façons pour que ce "truc DBA" franchisse la limite du domaine:

  1. Si l'application utilise des requêtes qui référencent la ROWGUIDCOLcolonne comme ceci:

    DECLARE @a table (id uniqueidentifier ROWGUIDCOL);

SELECT ROWGUIDCOL FROM @a;

    Je suppose qu'aucune de vos colonnes n'a encore cette propriété, donc l'application ne le ferait pas. (Soit dit en passant, ROWGUIDCOLest un concept complètement distinct de la réplication. Il se trouve que la réplication de fusion l'utilise.)

  2. La colonne de clé primaire ne serait plus modifiable. Si l'application fait cela et qu'aucune modification ne sera apportée pour utiliser un autre algorithme, il n'y a pas d' autre choix que d'ajouter une nouvelle colonne à la table, et donc aucune discussion n'est nécessaire.

Outre ces comportements, la ROWGUIDCOLpropriété est complètement transparente. Vous pouvez l'ajouter et l'application ne le saura jamais. Tout type de scénario de réplication de données doit être aussi transparent que possible pour les applications.

Jon Seigel
la source
Merci de répondre. Non, l'application ne fait pas 1. ni 2. Par souci d'exhaustivité, certaines tables sont déjà décorées avec la propriété ROWGUIDCOL dans le PK.
spaghettidba
Bien que je convienne que la réplication doit être transparente pour les applications, je pense également que les bases de données qui doivent être publiées doivent être pensées pour une réplication à partir de zéro. La gestion des identités dans la réplication de fusion est totalement PITA, par exemple: si vous savez dès le départ que vous devrez fusionner la publication, c'est une chose à éviter.
spaghettidba
@spaghettidba: Oui, je suis tout à fait d'accord que si la réplication est dans les cartes, la base de données doit certainement être conçue pour cela. Souvent, le simple fait de suivre les meilleures pratiques y parviendra la plupart du temps; ce sont les bases de données héritées laides et velues qui ont tendance à avoir le plus de problèmes de conception. D'après mon expérience, la fusion de réplication en particulier est plus difficile que n'importe quel autre mécanisme de réplication.
Jon Seigel
@spaghettidba et Jon: Juste pour info, l'utilisation de ROWGUIDCOLdans ce contexte (c'est-à-dire pas dans une instruction CREATE TABLE/ ALTER TABLE) est déconseillée depuis au moins SQL Server 2008 R2 (recherche de FeatureID 182) en faveur de $ROWGUID.
Solomon Rutzky
6

Je suis d'accord. Tant qu'il n'est pas nécessaire que la valeur PK puisse changer, il serait préférable d'utiliser la colonne uniqueidentifier existante comme rowguidcol.

Robert L Davis
la source
5

"Fondamentalement, ils disent que l'application ne doit jamais introduire dans son domaine quelque chose qui est utilisé uniquement par la réplication (c'est seulement" des trucs DBA "pour eux)."

Mais il n'est pas utilisé uniquement pour la réplication. C'est aussi (et déjà) votre PK.

Robert Zeurunkl
la source