O relacionamento um para um é normalizado?

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?

— Googlebot
fonte

'Normalizado' significa a primeira forma normal (1NF) e é um requisito fundamental do modelo relacional. 'Totalmente normalizado' significa 5NF ou superior. Sua tabela proposta de 'relacionamento um a um' tem mais chances de estar em uma forma normal mais alta (possivelmente até em 6NF) do que a atual porque está decomposta! Quais formulários normais sua tabela existente atende?

— onedaywhen

@onedaywhen Como muitos outros, não sigo a normalização passo a passo, pois às vezes a desnormalização também é útil. Em geral, todo o banco de dados deve ter um nível de normalização entre 3NF - 5NF (eu sempre tenho problema com 4FN!)

— Googlebot

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.

— Joel Brown
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 é)?

— Gili

@ Gili - Se sua suposição fosse verdadeira, este caso não se aplicaria. A segregação de colunas grandes e raramente necessárias permite que mais linhas sejam ajustadas em uma página, permitindo uma recuperação mais rápida das colunas usadas com mais freqüência. Obviamente, a leitura das colunas segregadas, juntamente com as colunas mais usadas, seria mais lenta, pois é necessária uma junção.

— Joel Brown

Quero megregar ao longo das colunas mais usadas por motivos de design (separação de preocupações, aumento da reutilização de código). Alguém postou uma estimativa do custo de tais junções? Eles são insignificantes ou algo que eu deveria me preocupar a longo prazo?

— Gili

@ Gilili - re: o custo das junções: Não há resposta certa para essa pergunta além de "depende". O custo da união é impactado por muitos fatores. Se eles são desprezíveis é ainda mais difícil de responder, porque isso é subjetivo. A melhor maneira de responder sua pergunta é simular alguns dados de teste e fazer testes de volume. Tente dos dois lados e veja se você consegue distinguir a diferença usando volumes de dados do mundo real (o que isso implica para o seu aplicativo).

— Joel Brown

Consegui e obtive resultados surpreendentes: dba.stackexchange.com/q/74693/4719 Admito que este não é um exemplo típico de normalização, mas não destaca que os JOINs (ainda) são muito caros.

— Gili

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.

— Stephen Senkomago Musoke
fonte

ponto muito bom para esclarecer a questão!

— Googlebot