¿PK como ROWGUIDCOL o usa una columna separada de rowguid?

9

Hay un largo debate aquí, así que me gustaría escuchar otras opiniones.

Tengo muchas tablas con PK de clúster de identificador único. Si esta es una buena idea está fuera de alcance aquí (y no va a cambiar en el corto plazo).

Ahora, la base de datos debe ser publicada y los DEV están abogando por el uso de una columna separada de guias de fila en lugar de marcar la PK existente como ROWGUIDCOL.

Básicamente, dicen que la aplicación nunca debería traer a su dominio algo que se usa solo para la replicación (es solo "material DBA" para ellos).

Desde el punto de vista del rendimiento, no veo ninguna razón por la que deba agregar una nueva columna para hacer algo que podría hacer con una existente. Además, dado que son solo "cosas de DBA", ¿por qué no dejar que el DBA elija?

Entiendo un poco el punto de los DEV, pero aún no estoy de acuerdo.

Pensamientos?

EDITAR: Solo quiero agregar que soy minoría en este debate y que los DEV que cuestionan mi posición son personas a las que respeto y en las que confío. Esta es la razón por la que recurrí a pedir opiniones.
También podría estar perdiendo algo y podría haber entendido mal su punto.

sql-server database-design merge-replication spaghettidba
fuente
¿Hay alguna posibilidad de que un valor PK deba cambiar en el futuro?
Robert L Davis
No en realidad no. Es una clave sustituta, por lo que la aplicación realmente no hace mucho con esa columna. Nunca cambia y nunca se muestra a los usuarios.
spaghettidba
¿Por qué quieren un rowguidcol separado? ¿Y qué esquema en general elegirían, si pudieran, para el PK, y por qué?
JustinC
@spaghettidba Hablando de cruzar dominios, ¿con qué frecuencia les dice qué patrones de diseño deberían o no deberían usar en su código de aplicación? ¿Quizás deberían atenerse a su "dominio"? ;-). Además, agregar una columna de 16 bytes a todas las tablas sería horrible para el rendimiento y no proporcionaría ningún beneficio.
Solomon Rutzky

Respuestas:

7

Básicamente, dicen que la aplicación nunca debería traer a su dominio algo que se usa solo para la replicación (es solo "material DBA" para ellos).

Concuerdo completamente. Pero ... la clave primaria no solo se usa para la replicación (presumiblemente la aplicación la usa de alguna manera). El argumento no tiene sentido en este contexto.

En cualquier caso, hasta donde yo sé, solo hay 2 formas para que estas "cosas de DBA" crucen el límite del dominio:

  1. Si la aplicación está utilizando consultas que hacen referencia a la ROWGUIDCOLcolumna de esta manera:

    DECLARE @a table (id uniqueidentifier ROWGUIDCOL);

SELECT ROWGUIDCOL FROM @a;

    Supongo que ninguna de sus columnas tiene esta propiedad todavía, por lo que la aplicación no estaría haciendo esto. (Por cierto, ROWGUIDCOLes un concepto completamente separado de la replicación. Resulta que la replicación por fusión lo usa).

  2. La columna de clave principal ya no sería actualizable. Si la aplicación está haciendo esto y no se van a realizar cambios para utilizar otro algoritmo, no hay más remedio que agregar una nueva columna a la tabla y, por lo tanto, no es necesario discutirlo.

Aparte de esos comportamientos, la ROWGUIDCOLpropiedad es completamente transparente. Puede agregarlo, y la aplicación nunca lo sabría. Cualquier tipo de escenario de replicación de datos debe ser lo más transparente posible para las aplicaciones.

Jon Seigel
fuente
Gracias por responder. No, la aplicación no está haciendo 1. ni 2. En aras de la exhaustividad, algunas tablas ya están decoradas con la propiedad ROWGUIDCOL en el PK.
spaghettidba
Si bien estoy de acuerdo en que la replicación debe ser transparente para las aplicaciones, también creo que las bases de datos que deben publicarse deben pensarse para la replicación desde cero. La gestión de la identidad en la replicación de fusión es totalmente PITA, por ejemplo: si sabe desde el principio que tendrá que fusionar la publicación, es una cosa que debe evitar.
spaghettidba
@spaghettidba: Sí, estoy completamente de acuerdo en que si la replicación está en las tarjetas, la base de datos definitivamente debe estar diseñada para ello. A menudo, simplemente siguiendo las mejores prácticas obtendrá la mayor parte del camino allí; son las bases de datos heredadas feas y peludas las que tienden a tener la mayoría de los problemas de diseño. Desde mi experiencia, la replicación de fusión en particular es más desafiante que cualquiera de los otros mecanismos de replicación.
Jon Seigel
@spaghettidba y Jon: Solo para su información, el uso de ROWGUIDCOLen ese contexto (es decir, no en una declaración CREATE TABLE/ ALTER TABLE) ha quedado en desuso desde al menos SQL Server 2008 R2 (busque FeatureID 182) a favor $ROWGUID.
Solomon Rutzky
6

Estoy de acuerdo. Siempre que no sea necesario que el valor de PK pueda cambiar, sería mejor usar la columna de identificador único existente como rowguidcol.

Robert L Davis
fuente
5

"Básicamente, dicen que la aplicación nunca debería traer a su dominio algo que se usa solo para la replicación (es solo" material DBA "para ellos)".

Pero no se usa solo para la replicación. También es (y ya) tu PK.

Robert Zeurunkl
fuente