Como projetar banco de dados para vários domínios?

votos
3

Como projetar banco de dados e organizar os dados se eu tiver dois ou mais domínios e um banco de dados? Todos os sites para fins de e-commerce e um bom pode estar à venda em cada site. Então, eu tenho apenas duas ideias:

  1. Eu preciso criar mais um campo (site_id) em quase todas as mesas e duplicar os dados.
  2. Eu preciso criar uma tabela com informações site_id para todos os outros campos de outras tabelas.

Ambas as idéias têm uma enorme contras. Alguma ideia? Obrigado.

Publicado 18/06/2009 em 22:46
fonte usuário
Em outras línguas...                            


5 respostas

votos
4

Este é um problema clássico na construção de sistemas multi-tenant. Eu ouvi algumas opiniões diferentes sobre este assunto, mas, basicamente, dividem-se em dois campos:

  1. Use o ID de arrendatário ( site_idno seu caso) em cada tabela que contém dados para um inquilino específico. Os defensores desta abordagem citar a facilidade de identificar o inquilino que dados pertencem a como um dos principais benefícios com implicações na forma como os dados são arquivados (viz. Diferentes espaços de tabela para clientes diferentes).

  2. Use o ID de inquilino somente em tabelas de alto nível. Os defensores desta abordagem tipicamente descrever os benefícios sendo uma estrutura de banco de dados mais limpo.

não I'n um fã de criar diferentes tabelas físicas para o mesmo tipo de dados de diferentes clientes. Há uma série de consequências desfavoráveis ​​para isso:

  • Torna-se difícil para criar um modelo de objeto coerente através de uma ferramenta ORM
  • Esta abordagem não escala bem com grande número de clientes - se você tem 70.000 clientes que devem ser servidos a partir de um único banco de dados, você terá 70.000 conjuntos de mesas.
  • nomes de tabelas devem ser gerados dinamicamente para instruções SQL.
Respondeu 18/06/2009 em 22:56
fonte usuário

votos
2

É provável que haja um pequeno punhado de mesas em algum lugar no seu esquema que apontam para todas as suas outras mesas. São estas tabelas que você precisa para colocar os site_id está, nem toda a tabela em seu banco de dados.

Para (a altamente artificial) exemplo, se meu esquema inclui uma mesa de clientes, uma mesa de Facturas, e uma tabela de Linha artigos da fatura, eu não preciso site_id de em todas as três tabelas. Eu só preciso de um site_id na tabela do Cliente.

Respondeu 18/06/2009 em 22:50
fonte usuário

votos
0

É multi-banco de dados fora de questão? Parece ser o mais fácil e mais limpo um, você não pode possivelmente bagunça um Tennants dados com o outro .. Você está indo precisar um banco de dados mestre para informações inquilino, e um db para cada Tennant.

Respondeu 21/06/2009 em 22:16
fonte usuário

votos
0

Minha preferência é para criar tabelas de mapeamento, quando necessário. Pensar que um produto pode existir para Site 1, Site 2, etc. Os detalhes do produto não mudam através dos sites. O preço dos produtos pode embora! Caso em que a tabela de preços pode precisar da SiteID eo ProductID onde ProductID podem ser replicados para cada entrada através dos diferentes sites. Isso pode ser dito para os usuários muito, exceto que os usuários podem achar que este é "big brother" no sentimento. Então, enquanto isso pode funcionar para os clientes que eu geralmente sugiro que os clientes têm contas diferentes em diferentes sites! Às vezes o que vai fisicamente trabalho não significa que logicamente vai funcionar. Coloque o SiteID onde você vai precisar dele, em vez de apenas colocá-lo ao acaso em todos os lugares. Tenha em mente que você pode precisar este SiteID em lugares além de onde você aplicativo precisar dela ... pensar sobre desligada consultando também. Ter que fazer 5 junta-se a filtrar o SiteID vai sugar! Manter os índices é melhor do que ter que caçar para o filtro!

Com relação ao particionamento horizontal por meio de mesas separadas com nomes semelhantes ... usar o SQL Server 2005 e para cima. Ele tem características de particionamento para que se preocupar com o tamanho dos dados não é mais um problema.

Respondeu 18/06/2009 em 23:10
fonte usuário

votos
0

Eu acho que uma das abordagens utilizadas por Wordpress e Drupal é a tabelas de prefixo com um nome:

dom1_Customers
dom2_Customers

Desta forma, as tabelas não crescem fora de proporção e você não tem que manter um índice extra de site_id. Dito isto, seu código tem que compensá-lo, o que pode exigir alguma reinstrumentation (e procedimentos armazenados são basicamente fora sem alguma maldade).

Respondeu 18/06/2009 em 22:53
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more