Oi Geroge, > From: George Silva <georger.si...@gmail.com> > > No primeiro caso, terei um monte de colunas (o padrão das análises químicas > são 31 elementos, mas nem sempre o resultado sai com 3 unidades ppm, ppb e > pct - ou seja, 93 colunas) e no outro terei geralmente entre 31 registros > (garantidos, não importa a unidade) à 40 registros (em casos muito > especiais).
Segundo as regras de normalização, a segunda abordagem é conceitalmente mais correta, pois deixará a base com menos campos nulos. Entretanto... > ...mas me digam aí, o que acham mais viável? Depende do que você irá fazer com estes dados. Vai comparar os valores de um elemento com outro?! Acho pouco provável que isso tenha alguma utilidade. Vai mostrar os valores de uma análise de apenas parte dos elementos (mais de um e não todos)?! Acho igualmente pouco provável. Normalizar a unidade tendo no máximo 3 me parece um exagero conceitual. Portanto, os poucos motivos que me fariam pender para o lado de mais registros e menos campos parecem não fazer parte dos requisitos. > Estou advogando > a segunda alternativa, onde repito um id_amostra diversas vezes, mas > flexibilizando a entrada do elemento e da unidade de medida. Ter muitos registros para representar um mesmo objeto nem sempre é uma boa idéia. Você sempre mexerá com todos os dados de uma vez (seja exibindo, seja gravando), logo não há vantagem em armazená-los de outro jeito. Lembre que essa tabela pode ter muitos registros, e se tiver você dependerá de uma inteligência que o otimizador do Postgres pode não ter para retornar seus dados em tempo hábil. Se precisar buscar todos os elementos de mais de uma análise, por exemplo, vai precisar dar um SELECT com um OUTER JOIN que pode deixar o servidor de joelhos. Se a amostragem estatística não for perfeita em todas as tabelas relacionadas o otimizador pode ter a idéia idiota de dar um TABLE SCAN para trazer os dados de uma análise. O espaço que você supostamente iria ganhar se livrando dos nulls pode se tornar uma desvantagem pelo armazenamento de vários ID_Amostra e ID_Resultado a mais, que não só estarão repetidos na tabela como também precisarão entrar em maior número em índices que você pode precisar criar para ter desempenho. Não vejo ganho em se ater a conceitos puristas neste caso, muito pelo contrário. Prefiro ter a certeza de que os dados chegarão em tempo hábil na aplicação, que por sinal pode ficar cheia de Cut-Paste, porém vai ser muito simples de entender e dar manutenção, além de mais rápida. Voto na alternativa 1. Mozart Hasse _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
