Estoy tratando de descubrir cuál es el mejor enfoque al diseñar un esquema de base de datos de múltiples inquilinos que deberá dividirse horizontalmente en el futuro.

Algunos números aproximados en la base de datos ...

El número total de inquilinos será de aproximadamente 10,000. La cantidad de datos almacenados por inquilino varía entre 500 MB -> 3 GB. El número de inquilinos comenzará siendo pequeño y crecerá a 10,000 en unos pocos años, por lo que inicialmente podemos comenzar con una única base de datos de múltiples inquilinos, pero a largo plazo esto tendrá que escalar horizontalmente por razones de rendimiento.

Update: un factor complicado es que ocasionalmente los inquilinos (empresas) pueden fusionarse y yo también necesito apoyar esto ...,

l multicliente se implementará utilizando una base de datos compartida, arquitectura de esquema compartido como se describe en este documentohttp: //msdn.microsoft.com/en-us/library/aa479086.asp

Dado que nos enfrentaremos a la partición horizontal en el futuro y que es probable que traslademos clientes de una base de datos a otra varias veces antes de que las cosas se calmen, creo que es mejor usar GUID como las claves principales en cada tabla junto con una columna de tenantID única.

Sé que hay una sobrecarga de rendimiento en el uso de GUID como clave principal, pero ¿es esto una compensación que solo necesito aceptar? ¿Hay otra forma de diseñar particiones horizontales en el futuro?

Aquí hay un ejemplo: digamos que quiero fusionar compañías con inquilinos 100 y 200 en el futuro, si el PK es un entero, puede haber una colisión cuando copio las filas de la base de datos 2 a la base de datos 1, con {guids} estoy garantizado que no habrá una colisión ...

database 1 base de datos 2 tenantid, id, descripción tenantid, id, descripción 100, 1, 'foo' 200, 1, 'xxx' 100, 2, 'boo' 200, 2, 'aaa'

database 1 base de datos 2 tenantid, id, descripción tenantid, id, descripción 100, {aaa}, 'foo' 200, {ccc}, 'xxx' 100, {bbb}, 'boo' 200, {ddd}, 'aaa '