Considere que temos um grande conjunto de dados estatísticos para um registro; por exemplo, 20 a 30 INTcolunas. É melhor manter o conjunto inteiro em uma tabela, pois todos eles pertencem a um registro OU criar outra tabela conectada a um relacionamento um para um.
A vantagem do primeiro é evitar JOINe ter um acesso rápido a todos os dados estatísticos para o registro correspondente.
A vantagem deste último é manter a coluna arrumada. A primeira coluna é intensiva em leitura e a segunda intensiva em gravação. Obviamente, acho que não tem efeito significativo no desempenho, pois uso o InnoDB com bloqueio no nível de linha.
Em geral, quero saber se é prático separar diferentes conjuntos de dados para um único registro?
Respostas:
Se ele se encaixa dentro das regras de normalização, os relacionamentos 1: 1 podem ser normalizados (por definição!) - Em outras palavras, não há nada nos relacionamentos 1: 1 que impossibilitem que eles obedeçam às formas normais.
Para responder à sua pergunta sobre a praticidade dos relacionamentos 1: 1, há momentos em que essa é uma construção perfeitamente útil, como quando você tem subtipos com predicados (colunas) distintos.
As razões pelas quais você usaria relacionamentos 1: 1 dependem do seu ponto de vista. Os DBAs tendem a pensar em tudo como uma decisão de desempenho. Os modeladores de dados e programadores tendem a pensar nessas decisões como orientadas ao design ou modelo. De fato, há muita sobreposição entre esses pontos de vista. Depende de quais são suas perspectivas e prioridades. Aqui estão alguns exemplos de motivações para relacionamentos 1: 1:
Você tem algum subconjunto de colunas muito amplas e deseja segregá-las fisicamente em seu armazenamento por motivos de desempenho.
Você tem alguns subconjuntos de colunas que não são lidos ou atualizados com freqüência e deseja mantê-los separados das colunas usadas com frequência por motivos de desempenho.
Você tem algumas colunas opcionais em geral, mas são obrigatórias quando você sabe que o registro é de um determinado tipo.
Você tem algumas colunas que pertencem logicamente a um subtipo e deseja modelá-las para se ajustarem bem ao modelo de objeto do seu código.
Você tem algumas colunas que podem ser aplicadas apenas a alguns subtipos de um supertipo de entidade e deseja que seu esquema imponha a ausência desses dados para outros subtipos.
Você tem algumas colunas que pertencem a uma entidade, mas precisa proteger essas colunas específicas usando regras de acesso mais restritivas (por exemplo, salário em uma tabela de funcionários).
Como você pode ver, algumas vezes o driver é o desempenho, outras é a pureza do modelo ou apenas o desejo de tirar o máximo proveito das regras declarativas do esquema.
fonte
You have some subset of columns that are very wide and you want to segregate them physically in your storage for performance reasons.Como a segregação deles melhora o desempenho (assumindo que as colunas sempre sejam acessadas toda vez que a tabela principal é)?Os principais motivos pelos quais você usaria um mapeamento um para um para dividir uma tabela grande em duas são por razões de desempenho, por exemplo:
a) A tabela possui dados binários / clob / blob em uma tabela acessada com frequência, diminuindo o desempenho, pois as colunas grandes são tratadas de maneira diferente.
b) A tabela possui muitas colunas que são acessadas por consultas diferentes; portanto, o desempenho é degradado; portanto, você move as colunas relacionadas para uma tabela separada para melhorar o desempenho do acesso
No entanto, ter muitas colunas inteiras não justifica o esforço adicional de dividir a tabela em tabelas separadas e ter que consultá-las.
fonte