Pergunta

Se minha mesa tiver um grande número de colunas (mais de 80), devo dividi-la em várias mesas com um relacionamento de 1 a 1 ou apenas mantê-lo como é? Por quê? Minha principal preocupação é o desempenho.

PS - Minha tabela já está na 3ª forma normal.

PS2 - Estou usando o MS SQL Server 2008.

PS3 - Não preciso acessar todos os dados da tabela de uma só vez, mas possui três categorias diferentes de dados dentro dessa tabela, que acesso separadamente. É algo como: preferências de membros, conta de membro, perfil de membros.

Foi útil?

Solução

80 colunas realmente não são muitas ...

Eu não me preocuparia com isso do ponto de vista do desempenho. Ter uma única tabela (se você estiver normalmente usando todos os dados em suas operações padrão) provavelmente superará várias tabelas com relacionamentos 1-1, especialmente se você estiver indexando adequadamente.

Eu me preocuparia com isso (potencialmente) do ponto de vista da manutenção. Quanto mais colunas de dados em uma única tabela, mais compreensível será o papel dessa tabela em seu grande esquema. Além disso, se você normalmente você está usando apenas um pequeno subconjunto dos dados e todas as 80 colunas nem sempre são necessárias, a divisão em mais de 2 tabelas pode ajudar o desempenho.

Outras dicas

Re a questão do desempenho - depende. Quanto maior a linha A maior é, menos linhas podem ser lidas no disco em uma leitura. Se você tem muitas linhas e deseja ler as informações principais da tabela muito rapidamente, pode valer dividi -las em duas mesas - uma com pequenas linhas com apenas as informações principais que podem ser lidas rapidamente , e uma tabela extra contendo todas as informações que você raramente usa que você pode procurar quando necessário.

Tomando outra abordagem, do ponto de vista de manutenção e teste, se você diz que tem três grupos distintos de dados na tabela, embora com o mesmo id exclusivo (por exemplo, membro_id), pode fazer sentido dividi -lo em tabelas separadas .

Se você precisar adicionar campos para dizer que a seção Detalhes do seu perfil da tabela de informações dos membros, você realmente deseja correr o risco de ter que testar novamente as preferências e detalhes da conta também os elementos do seu aplicativo para garantir nenhum impacto nos impactos.

Também para fins de trilha de auditoria, se você deseja rastrear o último ID do usuário/registro de data e hora para alterar os dados dos membros. Se o aplicativo administrador permitir que as preferências/detalhes da conta/perfil sejam atualizadas separadamente, fará sentido tê -las em tabelas separadas para rastrear mais facilmente atualizações.

Não é uma resposta SQL/Desempenho, mas talvez algo a olhar de um DB & App Design POV

Depende do que são essas colunas. Se você tem campos duplicados com codificação dura como Colour1, Colour2, Colour3, esses são candidatos a mesas infantis. Minha regra geral é que, se houver mais de um campo do mesmo tipo (cor), você também pode codificar para n deles, não um número fixo.

Roubar.

1-1 pode ser mais fácil, se você disse que membro_info; Membro_pref; Membro_profile. Ter muitas colunas pode fazê -lo funcionar se você quiser muito Varchar (255), pois você pode passar pelo limite do LOWSIZE, e isso apenas o torna muito confuso.

Apenas certifique -se de ter as restrições de chave forgein corretas e assim, para que sempre haja 1 linha em cada tabela com o mesmo membro_id

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top