Consejo por favor: Identidad de SQL Server vs claves de identificador único al usar Entity Framework

Question

Estoy en el proceso de diseñar un sistema bastante complejo. Una de nuestras principales preocupaciones es el soporte de la replicación de igual a igual de SQL Server. La idea es soportar varios nodos separados geográficamente.

Una preocupación secundaria ha sido usar un ORM moderno en el nivel medio. Nuestra primera opción siempre ha sido Entity Framework, principalmente porque a los desarrolladores les gusta trabajar con él. (Les encanta el soporte de LiNQ).

Así que aquí está el problema:

Con la replicación de igual a igual en mente, decidí usar el identificador único con un valor predeterminado de newsequentialid () para la clave principal de cada tabla. Esto pareció proporcionar un buen equilibrio entre evitar colisiones clave y reducir la fragmentación del índice.

Sin embargo, resulta que la versión actual de Entity Framework tiene un limitación muy extraña : si la columna clave de una entidad es un identificador único (GUID), no puede configurarse para usar el valor predeterminado (newsequentialid ()) proporcionado por la base de datos. La capa de aplicación debe generar el GUID y completar el valor clave.

Así que aquí está el debate:

1. abandone Entity Framework y use otro ORM:
   • use NHibernate y renuncie al soporte de LiNQ
   • use linq2sql y renuncie a la asistencia futura (sin mencionar el enlace a SQL Server en DB)
2. abandona los GUID y ve con otra estrategia de PK
3. diseñar un método para generar GUIDs secuenciales (COMBs?) en la capa de aplicación

Me estoy inclinando hacia la opción 1 con linq2sql (a mis desarrolladores realmente les gusta linq2 [cosas]) y 3. Eso es principalmente porque soy un tanto ignorante de las estrategias clave alternativas que apoyan el esquema de replicación al que aspiramos, al mismo tiempo que mantenemos Cosas sensatas desde la perspectiva de un desarrollador.

Cualquier percepción u opinión sería muy apreciada.

Answer 1

Otra opción (no disponible cuando se publicó) es actualizar a EF 4, que admite GUID generados por el servidor.

Answer 2

Respaldo la sugerencia de Craig - opción 4.

Siempre puedes usar la columna GUID, rellenada por el nivel medio, como tu CLAVE PRINCIPAL (que es una construcción LÓGICA).

Para evitar la fragmentación masiva del índice (por lo tanto: tabla), use alguna otra clave (idealmente una columna de IDENTIDAD INT) como la CLUSTERING KEY - es una construcción de base de datos física, que PUEDE estar separada de la clave principal.

De forma predeterminada, la clave principal es la clave de agrupación en clústeres, pero no tiene por qué ser así. De hecho, mejoré el rendimiento y reduje drásticamente la fragmentación haciendo eso en una base de datos que heredé " - agregue una columna de IDENTIDAD INT y coloque la clave de agrupación en esa INT pequeña, cada vez más grande y que nunca cambia - ¡funciona como un encanto!

Marc

Answer 3

¿Eh? Creo que tus tres opciones son una elección falsa. Considere la opción 4:

  

4) Use Entity Framework con no secuencial , GUID generados por el cliente.

El EF no puede ver los GUID generados por el servidor de DB para las nuevas filas insertadas por el propio framework , por supuesto, pero no es necesario que genere los GUID en el servidor de DB. Puede generarlos en el cliente cuando cree sus instancias de entidad. El punto principal de un GUID es que no importa dónde lo genere. En cuanto a los GUID generados por una base de datos replicada, el EF los verá muy bien.

Sus GUID del lado del cliente no serán secuenciales (use Guid.NewGuid ()), pero serán mundiales, con garantía única.

Hacemos esto en el envío, software de producción con replicación. funciona .

Answer 4

¿Por qué no usar la columna de identidad? Si está realizando la replicación de mezcla, puede hacer que cada sistema comience en una semilla separada y trabaje en una dirección (por ejemplo, el nodo a comienza en 1 y agrega 1, el nodo b comienza en 0 y resta uno) ...

Answer 5

Puede usar procedimientos almacenados si está realmente atascado al usar NewSequentialID (). Puede vincular las columnas de resultados del procedimiento a la propiedad correspondiente y, una vez insertadas, el GUID generado por SQL se devolverá al objeto.

Lamentablemente, tiene que definir SP para las tres operaciones (insertar, actualizar, eliminar) aunque las otras operaciones se completen correctamente utilizando los valores predeterminados. También debe mantener el código SP y asegurarse de que esté sincronizado con su modelo EF cuando realice cambios, lo que puede hacer que esta opción no sea atractiva debido a la sobrecarga adicional.

Hay un ejemplo paso a paso en http://blogs.msdn.com/bags/archive/2009/03/12/entity-framework-modeling-action-stored-procedures.aspx que es bastante sencillo -en adelante.

Answer 6

use newseqid con su propio orm (no es tan difícil) con linq