Vários bancos de dados V / s únicos

Criei este aplicativo da web (php e mysql) que armazena informações para várias organizações (atualmente cerca de 20 clientes).

O cenário atual armazena informações relacionadas ao cliente em bancos de dados individuais, para que haja 20 bancos de dados do cliente e 1 banco de dados mestre.

Uma das principais vantagens aqui é que, à medida que cada banco de dados do cliente é isolado, a numeração dos artefatos do cliente (relatórios, auditorias) etc. é sequenciada; dando aos nossos clientes uma sensação de segurança.

Cada banco de dados possui aproximadamente 15 tabelas, e o maior número de linhas em uma tabela é de cerca de 2000. Espera-se que ele atinja 5.000 registros, no máximo.

Gerenciar uma única alteração no nível de banco de dados significa alterar 20 bancos de dados, mas no raro evento em que preciso fazer essa alteração, uso um script que faz isso em uma única chamada de função.

Estamos em um acordo de hospedagem compartilhada, e nosso ISP nos fornece um número limitado. de bancos de dados; e foi isso que me levou a pensar em termos de centralização do banco de dados; para que TODOS os dados do cliente possam ser armazenados no banco de dados mestre.

Obviamente, algumas questões importantes que surgem são:

uma. Mantendo a sequência do artefato (isso pode ser solucionado através da criação de uma chave de referência adicional) b. Velocidade e desempenho (nesse caso, posso criar índices para acelerar as coisas) c. Segurança: isso será gerenciado a cada consulta que buscar informações do cliente. também acompanhará o client_id

No futuro, poderemos considerar a comparação de conjuntos de dados de uma organização com outra, mas acredito que isso também pode ser alcançado em um banco de dados centralizado. Estou um pouco inclinado (por razões de desempenho e capacidade de manutenção) a mudar para um banco de dados centralizado.

Você acha que mudar para um banco de dados centralizado faz mais sentido do que permanecer como estamos (em bancos de dados individuais)?

Obrigada pelo Conselho.

Existem riscos e recompensas herdados para ambos os sistemas. Eu trabalhei para uma empresa financeira que suportava aproximadamente 40 clientes (bancos nacionais) em um banco de dados. Em seguida, adquirimos outra empresa que vendia software semelhante e possuía 1 banco de dados por cliente. Finalmente, a empresa faliu e tivemos que exportar todos os dados do usuário. Aqui está o que as pessoas com quem trabalhei e encontrei:

Profissionais do banco de dados único:

1. Atualizações de software e correções de bugs são mais fáceis.
2. Fácil de gerenciar e relatar todos os dados do cliente.
3. A atualização de dados se torna mais fácil.
4. Fácil de criar funcionalidades modulares que um cliente deseja, desative-as para os outros clientes e, em seguida, desative-as quando desejarem no futuro.

Con's do banco de dados único:

1. Integridade dos dados - tivemos 2 ou 3 casos em que os usuários de um banco viram os dados de outro banco. Isso foi um pesadelo. Especialmente porque os usuários do site não eram apenas funcionários do banco, mas clientes reais do banco! Este é de longe o maior problema com 1 banco de dados
2. Exportando dados do cliente - Quando tínhamos isso, geralmente não era grande coisa. Você termina com 1 tabela com todos os clientes e fecha essa tabela para obter dados específicos do cliente.

Profissionais de vários bancos de dados:

1. Não há preocupação de contaminação ou violação de dados entre clientes
2. A exportação de dados de um cliente é fácil.

Contras de vários bancos de dados:

1. Atualizações e correções de bugs - Esse foi o verdadeiro pesadelo. Quando você tem 20 clientes em 20 bancos de dados diferentes, encontra rapidamente um caso em que um cliente deseja que um bug seja corrigido e outro pensa que o bug é um recurso ou não quer arriscar a atualização. Além disso, você terá instâncias em que 1 cliente deseja um aprimoramento na mudança do jogo, mas os outros clientes não. Quando isso acontece, os bancos de dados começam a divergir. De repente, você precisará atualizar os clientes 1-15 com 1 script 16-19 com outro e 20 com um terceiro. Vimos esse problema se tornar um problema que levaria de 15 a 20 vezes mais tempo para a empresa que compramos do que para nós, porque eles precisavam executar todos os testes para cada cliente e lidar com o código especial de cada cliente. Efetivamente, eles precisavam de uma nova pessoa de suporte para cada novo cliente,
2. Gerenciamento de banco de dados - Quando você obtém um grande número de clientes que gerenciam todos os bancos de dados, torna-se um verdadeiro aborrecimento. Você sem dúvida precisará de mais tempo do DBA para gerenciá-los.

No final, minha recomendação de ter visto e feito as duas coisas é ter "disciplina"! Eu acho que a escolha multi-db é um pouco melhor porque protege você, mas você nunca pode permitir que os clientes façam uma escolha que faça com que você adicione funcionalidade apenas a eles ou você estará se colocando no caminho do fracasso.

Eu teria um banco de dados separado para clientes separados. Um cliente pode exigir isso por motivos de segurança - ou seja, apenas o site tem acesso aos dados. Isso também significa que, se um cliente deseja mover seus dados, será muito mais fácil gerenciar.

Isso também significa que, se houver um problema com o banco de dados de um cliente, ele não afetará todos os outros.

Se você deseja comparar dados entre clientes, faça isso separadamente.

Se você estiver ficando sem bancos de dados, talvez esteja pensando em mudar de provedor de hospedagem.

A única razão pela qual eu não teria um banco de dados individual para cada cliente é se você terá 100s ou 1000s de clientes / bancos de dados. Isso pode ser muito complicado de gerenciar, incluindo fazer alterações no banco de dados ou fazer algo em todos os bancos de dados. As ações que ocorrem em um grande número de bancos de dados múltiplos também podem ser lentas, pois você precisa abrir (e, portanto, fechar) muitas tabelas.

Mas, além desse caso, acho que vários bancos de dados são melhores.

Uma vantagem, que pode não ser importante, mas pode ser útil, é que cada cliente obtém seus próprios IDs seqüenciais (em vez de possivelmente pular um monte porque outro (s) cliente (s) adicionou registros).

Além disso, vários bancos de dados permitem que as sub-tabelas (como o tipo de telefone) sejam facilmente personalizáveis ​​por cliente, sem a necessidade de um ID de registro pai nessas tabelas.

Primeiro o sequenciamento de artefato. Presumo que você esteja usando chaves primárias inteiras para fornecer isso. Realmente, você deve ter uma coluna "número de artefato" separada. PK deve ser PK e nada mais. As pessoas falam sobre "chaves naturais" e coisas do gênero, e eu me encolho. Sempre que você confia no PK para ser mais do que um identificador, ele volta a mordê-lo. Se você deseja saber a sequência de algo, armazene uma data ou um número de sequência.

Eu acho que no seu caso, o gerenciamento de configuração o levaria a um único banco de dados. Veja quanto custa a tempo de manter e atualizar bancos de dados. Quais custos estão associados a cada versão do software? Pense também no custo quando você recebe um novo cliente e precisa criar um banco de dados e configurar o aplicativo para ele. Qualquer coisa pode ser automatizada, a questão é: valerá a pena quando você tiver 100 bancos de dados?

No futuro, é mais fácil dimensionar (particionamento, hardware, sharding etc.) um único banco de dados do que fazer o mesmo para 100 bancos de dados.

Eu acho que os outros pôsteres fizeram alguns pontos excelentes, então eu não os reparei.

Para adicionar aos prós / contras listados até agora:

Profissionais de vários bancos de dados:

1. Problemas de bloqueio são evitados; temos bancos de dados em que os clientes podem acionar alterações de DDL em algumas das tabelas. Para tabelas maiores (registros> 2m), isso bloqueia a tabela por um período considerável de tempo. As únicas pessoas em desvantagem são seus próprios usuários, portanto isso é aceitável.

2. Flexibilidade - alguns clientes têm desejos específicos em relação aos dados que desejam armazenar; o banco de dados múltiplo nos permitiu a flexibilidade de alterar seu banco de dados especificamente, sem ter que desorganizar o modelo de dados para os outros clientes.

Contras:

1. Contras principais: ingressar em outras mesas é muito mais complicado. Temos um banco de dados principal que contém a maioria dos metadados. Os usuários do banco de dados específico do cliente não têm acesso a esse banco de dados, portanto, todas as junções entre as tabelas nesse banco de dados e a específica do cliente são tratadas no aplicativo em vez de no banco de dados. Você pode resolver isso dando aos usuários específicos do cliente acesso ao banco de dados principal, mas o aplicativo pode / pode vazar informações novamente.

Boa sorte na escolha!

Sei que você já escolheu uma resposta, mas parece que há outra solução que não foi sugerida:

Mova tudo para um banco de dados, mas crie tabelas para cada cliente, usando um prefixo, como este:

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

É o melhor dos dois mundos.

• É muito fácil migrar da sua configuração atual para a nova configuração.
• Você pode criar 1 usuário por cliente e restringir seus privilégios às tabelas da empresa e nada mais
• Você pode criar um superusuário e agregar dados facilmente, se precisar.
• Use apenas um banco de dados