Estou tentando descobrir qual é a melhor abordagem ao projetar um esquema de banco de dados multilocatário que precisará ser particionado horizontalmente no futuro.

lguns números aproximados no banco de dado

O número total de inquilinos será de aproximadamente 10.000. A quantidade de dados armazenados por inquilino varia entre 500 MB -> 3 GB. O número de inquilinos começará pequeno e aumentará para 10.000 ao longo de alguns anos. Inicialmente, podemos começar com um único banco de dados de vários inquilinos, mas, a longo prazo, será necessário escalar horizontalmente por motivos de desempenh

Update - um fator complicador é que ocasionalmente os inquilinos (empresas) podem se fundir e preciso também apoiar isso ...,

multilocação será implementada usando uma arquitetura de banco de dados compartilhado e esquema compartilhado, conforme descrito neste documenthttp: //msdn.microsoft.com/en-us/library/aa479086.asp

Dado que seremos confrontados com o particionamento horizontal no futuro e que provavelmente moveremos clientes de um banco de dados para outro várias vezes antes que as coisas se acalmem, acho que é melhor usar GUIDs como chaves primárias em todos os tabela junto com uma coluna única tenantID.

Sei que há uma sobrecarga de desempenho no uso de GUIDs como chave primária, mas isso é uma troca que eu só preciso aceitar? Existe outra maneira de projetar para particionamento horizontal no futuro

Heres um exemplo - digamos que eu quero mesclar empresas com inquilinos 100 e 200 no futuro, se o PK for um número inteiro, poderá haver uma colisão quando eu copiar as linhas do banco de dados 2 para o banco de dados 1, com {guids}. garantido que não haverá colisão ...

database 1 database 2 tenantid, id, descrição tenantid, id, descrição 100, 1, 'foo' 200, 1, 'xxx' 100, 2, 'boo' 200, 2, 'yyy'

database 1 database 2 tenantid, id, descrição tenantid, id, descrição 100, {aaa}, 'foo' 200, {ccc}, 'xxx' 100, {bbb}, 'boo' 200, {ddd}, 'aaaa '