Temos um cenário de tempo de projeto do banco de dados do SQL Server. Temos que armazenar dados sobre Organizações diferentes em nosso banco de dados (ou seja, como Cliente, Fornecedor, Distribuidor, ...). Todas as organizações do diff compartilham o mesmo tipo de informação (quase) ... como Detalhes do endereço, etc ... E elas serão referenciadas em outras tabelas (isto é, ligadas via OrgId e nós temos que procurar OrgName em muitos lugares diferentes)

Eu vejo duas opções:

Criamos uma tabela para cada organização como OrgCustomer, OrgDistributor, OrgVendor, etc ... todas as tabelas terão estrutura similar e algumas tabelas terão campos extras especiais como o cliente possui um campo HomeAddress (que as outras tabelas Org não possuem ) .. e vice versa.

Criamos uma tabela comum do OrgMaster e armazenamos TODAS as diferenças orgânicas em um único lugar. A tabela terá um campo OrgType para distinguir entre os tipos de diferenças de Orgs. E os campos especiais serão anexados à tabela OrgMaster (somente os registros Org relevantes terão valores em tais campos, em outros casos, serão NULL)

Alguns Prós e Contras de # 1:

PROS:

Ele ajuda a distribuir a carga enquanto acessa o tipo diff dos dados da Organização, portanto acredito que isso melhora o desempenho.Fornece um escopo completo para personalizar qualquer tabela Org sem afetar os outros tipos de organização existentes.Não tenho certeza se os índices diff nas tabelas diff / distributed funcionam melhor que uma única tabela grande.

CONS:

Replicação de design. Se eu tiver que aumentar o tamanho do campo ZipCode - eu tenho que fazer isso em TODAS as tabelas.Replicação na implementação de manipulação (por exemplo, usamos procedimentos armazenados para operações CRUD, de modo que a replicação seja n-fold. 3-4 SP Inertes, 2-3 SELECT SPs, etc ...)Tudo cresce à dobra das restrições de DB \ indexing para SP para os objetos Business no código do aplicativo.Mudança (comum) em um lugar tem que ser feita em todos os outros lugares também.Alguns Prós e Contras de # 2:

PROS:

N-fold se torna 1-fold :-)A manutenção é fácil porque podemos tentar implementar pontos de entrada únicos para todas as operações (ou seja, um único SP para lidar com operações CRUD, etc.)Temos que nos preocupar em manter uma única mesa. A indexação e outras otimizações são limitadas a uma única tabela.

CONS:

Isso cria um gargalo? Pode ser gerenciado pela implementação do Views e outras estratégias de acesso a dados otimizados?O outro lado da implementação centralizada é que uma única mudança deve ser testada e verificada em TODOS os locais. Não é abstrato.O design pode parecer um pouco menos 'organizado \ estruturado' esp. devido às poucas Organizações para as quais precisamos adicionar campos 'especiais' (que são irrelevantes para as outras tabelas)

Eu também tenho em mente uma opção # 3 - manter as tabelas org separadas mas criar uma tabela OrgAddress comum para armazenar os campos comuns. Mas isso me deixa no meio do # 1 e # 2 e está criando ainda mais confusão!

Para ser honesto, sou um programador experiente, mas não sou um DBA igualmente experiente, porque esse não é meu trabalho principal, então, por favor, ajude-me a obter o equilíbrio correto entre parâmetros como o design - complexidade e desempenho.

Desde já, obrigado. Sinta-se livre para pedir quaisquer dúvidas técnicas e sugestões são bem vindas.

Hemant