Mejor enfoque para claves primarias de varios inquilinos

Question

Tengo una base de datos utilizada por varios clientes. Realmente no quiero que los valores de clave incrementales sustitutas sangren entre los clientes. Quiero que la numeración comience desde 1 y sea específica del cliente.

Utilizaré una clave compuesta de dos partes del tenant_id, así como una identificación incremental.

¿Cuál es la mejor manera de crear una clave incremental por inquilino?

Estoy usando SQL Server Azure. Me preocupan las tablas de bloqueo, las claves duplicadas, etc. Por lo general, configuré la clave primaria para IDENTIDAD y sigo.

Gracias

Answer 1

¿Está pensando en el uso de SQL Azure federaciones en el futuro? Si es así, la versión actual de SQL Azure Federations no admite el uso de IDENTIDAD como parte de un índice agrupado. Vea esto What alternatives exist to using guid as clustered index on tables in SQL Azure (Federations) para más detalles.

Si aún no ha estudiado las federaciones, le conviene verificarlo, ya que proporciona una forma interesante de fragmentar la base de datos y de aislar a los inquilinos dentro de la base de datos.

Dependiendo de su objetivo final, al usar Federaciones, es posible que pueda usar un GUID como el índice agrupado principal en la tabla y también use un campo incremental de IDENTIDAD INTELECTUAL en la tabla. Este campo INT IDENTITY podría mostrarse a los usuarios finales. Si está federando en el TenantID, cada "tabla de inquilinos" se convierte efectivamente en un silo (como yo lo entiendo al menos), por lo que el uso de IDENTIDAD en un campo dentro de esa tabla sería un valor autogenerado cada vez mayor que aumenta dentro de un determinado inquilino .

Cuando \ if los datos se fusionan (combinando datos de varios inquilinos) se producirían colisiones en este campo INT IDENTITY (de ahí por qué la IDENTIDAD no es compatible como clave principal en federaciones) pero mientras no esté Al usar este campo como un identificador único dentro del sistema en general, debería estar bien.

Answer 2

Si está buscando duplicar la conveniencia de tener una clave INT única asignada automáticamente al insertarla, puede agregar un disparador INSTEAD OF INSERT que use MAX de la columna existente +1 para determinar el siguiente valor.

Si la columna con el valor de identidad es la primera clave en un índice, la consulta MAX será una simple búsqueda de índice, muy eficiente.

Las transacciones asegurarán que se asignan valores únicos, pero este enfoque tendrá una semántica de bloqueo diferente a la columna de identidad estándar. IIRC, SQL Server puede asignar un valor de identidad diferente para cada transacción que lo solicita en paralelo y, si se retrotrae una transacción, se descartan los valores asignados. El enfoque MAX solo permitiría que una transacción inserte filas en la tabla a la vez.

Un enfoque relacionado podría ser tener una tabla de valores de clave dedicada codificada por el nombre de la tabla, el ID del inquilino y el valor de identidad actual. Se requeriría el mismo activador INSTEAD OF INSERT y más repetitivo para consultar y mantener actualizada esa tabla de claves. Sin embargo, no mejoraría las operaciones paralelas; la cerradura solo estaría en el registro de otra mesa.

Una posibilidad de corregir el cuello de botella de bloqueo sería incluir el SPID actual en el valor de la clave (ahora la clave de identidad es una combinación de int secuencial y cualquier SPID que ocurra para asignarlo y no simplemente secuencial), use la identidad dedicada tabla de valores e inserte registros allí por SPID según sea necesario; la tabla de identidad PK sería (nombre de la tabla, inquilino, SPID) y tiene una columna que no es clave con el valor secuencial actual. De esta forma, cada SPID tendría su propio conjunto de identidades dinámicamente asignado y solo tendría sus propios registros específicos de SPID bloqueados.

Otro inconveniente es mantener activadores que deben actualizarse cada vez que cambie las columnas en cualquiera de las tablas de identidades especiales.