Eu preciso criar um sistema que represente vários "projetos", um por cliente no SQL Server, algo semelhante ao StackExchange ... mesmo modelo de dados, sites diferentes (um por cliente). Cada projeto tem o mesmo modelo de dados, mas é independente de todos os outros. Minha inclinação é usar um banco de dados para armazenar todos os projetos. Qual é a sua recomendação?
Eu faria bancos de dados separados, porque, caso contrário, se cada cliente estiver usando um esquema semelhante, você terá que combinar tabelas ou usar muitos prefixos ou ter tabelas de links contendo informações de identificação do cliente. Além disso, será muito mais fácil gerenciar backups / restaurações de dados do cliente se eles tiverem seus próprios bancos de dados.
Não há uma boa razão para não usar DBs separados, IMO.
Uma desvantagem de bancos de dados separados é a implantação de alterações de esquema; Se você tem algumas centenas de db's, esteja preparado para encontrar uma maneira inteligente de empurrar novas tabelas, procedimentos armazenados, índices de atualizações para eles. Outra desvantagem é que o espelhamento se torna menos atraente para uma solução de DR à medida que o número de bancos de dados cresce.
A menos que haja necessidade urgente de manter os dados em um só lugar, sugiro separá-los. Isso facilitará a transferência dos dados entre os servidores (se você quiser dividi-los em vários servidores de banco de dados quando o carregamento crescer a ponto de ser um problema, por exemplo, ou se um cliente quiser pagar para levar o aplicativo internamente), Ele pode tornar os backups e as restaurações subseqüentes mais convenientes (dependentes ou não dos métodos de backup que você usa) e reduz o risco de erros de código, permitindo que os clientes (acidentalmente ou por meio de hacking intencional) vejam os dados uns dos outros.
Não há resposta certa aqui. A rota purista-dba estaria toda em um DB. Se você é bom no design / config / sql você ficaria surpreso com o que você pode obter de um servidor moderno de $ 8K. A rota de escala da Web barata e suja seria 1: 1 cliente: db. Dessa forma, se um cliente for muito mais popular do que outros, você poderá dividi-lo e dimensionar sua configuração. A rota purista do desenvolvedor web seria "um" db, mas construída em uma forma bigtable / dynamo para escalar em larga escala.
Isso realmente se torna menos uma questão de tecnologia e mais de negócios. Quantos desenvolvedores e administradores você tem agora, quão talentosos eles são, o que eles já sabem, que tipo de tráfego você espera no curto prazo, que tipo de receita seria necessário para comprar / arrendar 10x o hardware necessário para isso, etc.
Em geral, é por isso que a maioria das mãos de startups mais antigas dirá "apenas trabalhe e foque".
edit: também, não tem como este ser um administrador de sistema fazendo a pergunta. Devs sempre gostam de pensar em projetos que 10x a complexidade de configuração do servidor "apenas no caso".
Eu não uso o MS SQL, mas como princípio, um DB por cliente. Muito mais fácil de lidar. Além disso, se um banco de dados for danificado, e isso acontecer, isso não afetará seus outros clientes. Qualquer procedimento de manutenção pode ser roteirizado para vários bancos de dados tão facilmente quanto um.
Eu tenho usado um banco de dados por cliente e, como mencionado, atualizar o esquema e os backups serão complicados.
Mas não tanto assim.
Você precisa registrar todo o seu banco de dados separadamente (em um banco de dados diferente, pelo menos, se não uma máquina diferente), ter uma tabela chamada schema_update_log ou algo assim e escrever um script que atualize o esquema para cada banco de dados e registre sucesso nisso. Portanto, se você tiver 100.000 dbs, mesmo em muitos servidores físicos, basta consultar cada um deles e registrar o sucesso, se por algum motivo ele falhar, tente os bancos de dados com falha novamente.
Então, seria algo assim:
master_databases: (registro de cada banco de dados por cliente e sua string de conexão) db_id base de dados ...
schema_update_log pk query_id db_id status (pendente, sucesso, falha) timestamp erro (apenas no caso)
schema_query query_id (referenciado no schema_update_log) consulta
em seguida, escreva um script para percorrer cada consulta dataasem e atualizar o log, mantendo-o até que, para cada query_id, cada banco de dados retorne um sucesso em schema_update_log.
isso levará tempo, mas será mais confiável do que atualizações ad hoc.
DBs separados. Além de outras razões dadas:
Basicamente, é muito mais claro ou mais correto: se as linhas de uma tabela não têm absolutamente nada a ver uma com a outra, elas não devem estar juntas em uma tabela. (Ok, eu acabei de fazer essa regra.)
Como cagenut diz, isso depende. No entanto ...
Um banco de dados por cliente parece estar tornando as coisas mais difíceis para você no longo prazo. O que acontece se você acabar com 100.000 clientes? O SQL Server lidará com muitos bancos de dados? Você vai acabar com 100.000 backups de banco de dados? Como você vai conseguir isso? Se isso vai fazer mais trabalho para você, por que tomar essa opção agora, se poderia ser alterado mais tarde?
Pode ser uma ideia usar um único banco de dados agora, mas pense em como você poderia particionar os dados se acabasse com muitos clientes.
Tags database sql-server schema