Migração DB: restrições de relações guardar?

Question

Com o risco de ser chamado de idiota, eu estou querendo saber o que seus pensamentos estão em manutenção de restrições de relacionamento dentro de uma MS SQL DB.

Eu estou migrando um sistema em um ambiente .NET da ASP. Isto traz consigo objetos de negócios e outras técnicas de camadas de codificação, que trabalham para abstrair o banco de dados do usuário / API. O novo aplicativo tem um API definido acima de um Entity Framework DAL.

O aplicativo DB no banco de dados antigo é grande e o propósito de algumas das tabelas estará mudando para começar contendo dados binários, na forma de arquivos, etc. Estou ansioso para dividir estes fora em bancos de dados separados para facilidade gestão nas instalações do cliente onde o espaço em disco está em um prêmio.

Existe algum valor em manter as restrições de relacionamento entre tabelas?

Pressupostos:

• O código é testado
• Onde as relações são importantes, a execução é realizada sob uma transação
• O acesso ao DB é através da API única, outro acesso por terceiros não é suportado.

razões manter restrições:

• Reforça a estrutura de dados
• JOINs são mais rápidos?
• assistência plano de consulta?

Razões para remover restrições na nova versão NET:

• Pode-se supor que a lógica API / BIZ iria gerir relações como pai / filho.
• Reduz oportunidade de alienar setores da DB para outros catálogos (o sistema é construído usando um plug-in arquitetura, a maioria das tabelas podem operar isoladamente)
• Am I corrigir em acreditar que SQL tem que fazer controlos suplementares durante INSERT em restrições, que pode ser unnecassary quando uma API acima da DB está a gerir isso?

Eu lanço minha pergunta sobre a comunidade de qualquer maneira no caso de eu ter perdido alguma coisa muda ou se isso é apenas um pesadelo esperando para acontecer ...

Muito obrigado,

Nathan

Answer 1

Eu não suportam a afirmação de que as restrições "são indexados automaticamente". Apenas original e chaves primárias fazer. chaves estrangeiras não, embora na maioria dos casos, eu recomendo ter um índice na "criança" combinando colunas do FK. No entanto eu ainda recomendo FKeys como eles

1. irá impor a integridade dos dados (Eu tenho mordido muitas vezes pela BL ter erros e não para fazer o trabalho).
2. Dê o otimizador mais informações sobre o padrão de seus dados, que por sua vez pode levar a melhores e mais rápidos planos de execução.

Mas acima de tudo, você já pensou sobre como manter seus dados em um único banco de dados, mas separando-o em vários grupos de arquivos? Você poderia conseguir seu objetivo a gestão de espaço em disco mais flexível, sem as dificuldades de chaves estrangeiras abrangendo vários bancos de dados

Answer 2

Sim, eu recomendaria manter as restrições relacionais. Certamente você tem que lidar com eles em sua BLL, mas as restrições também melhorar o desempenho, porque eles são usados ??pelo planejador consulta para consultas lidar com mais eficiência.

Veja também esta pergunta: são chaves estrangeiras em realmente necessário um projeto de banco de dados?

Answer 3

Sim, você deve ter restrições de chaves estrangeiras nas tabelas a menos que você tenha um motivo específico para não. Mesmo que a sua aplicação é testado, ele pode muito bem não ser a única coisa que sempre escreve no banco de dados. do FK impor a integridade referencial em dados de todas as fontes.

As chaves estrangeiras também atuam como uma espécie de instrumento de documentação informal para as relações no banco de dados. Onde do FK estão presentes em um banco de dados, eu posso reveerse engenharia do esquema com Visio (ou qualquer outra ferramenta que suporta a engenharia reversa) e ver os relacionamentos. Soltando chaves estrangeiras em um banco de dados em nome de desempenho é uma técnica comum usada por ISV para obfusticate seu esquema de banco de dados e trazer mais receita apoio.

Se você pode traçar um específico, desempenho questão relacionada a uma chave estrangeira, você pode precisar para soltar a chave. Esta é apenas sempre susceptível de acontecer em um pequeno número de chaves em um ou dois específica, mesas de alto volume. Também está apenas sempre susceptível de ser necessário em sistemas com volumes muito elevados de transação. Nunca há uma desculpa para não ter chaves estrangeiras em um banco de dados.