none
Relacionando registro de uma mesma tabela.

    Pergunta

  • Senhores,

         Tenho 2 duas tabelas de cadastro uma de "professor" e outra de "instituições" e um que relaciona N:N as duas tabelas anteriores.. 

         Bom.. mas se eu quisesse ao invés de ter duas tabelas de cadastro (professor e instituições) ter uma tabela de "cadastrogeral".. relacionando assim os registros de uma mesma tabela..

         e por segurança eu crio um constraints.. que nao deixa eu relacionar professor com professor nem instituição com instituição.. é claro que pra isso vou ter que fazer uma coluna de tipo na tabela de "cadastrogeral"

       a principal vantagem é que existem muitas colunas iguais nas tabelas nas tabelas de professor e instituição... 

     oque vocês acham... será que eu teria algum problema de desempenho ... com isso...

      att

    Renan

         

    quinta-feira, 15 de março de 2012 18:27

Respostas

  • Renan,

    Esta sua ideia vem totalmente contra as regras de integridade referencial, relacional e normalização de banco de dados, com base, nas técnicas de modelagem.

    A princípio este cenário pode ser vantajoso que se diz respeito a eliminação de colunas possivelmente iguais, mas por outro lado você esta tornando sua estrutura condicionada a trabalhar em uma única tabela que vai se tornar ao longo do tempo um repositório mal dimensionado, crescendo principalmente de forma vertical.

    O desempenho com certeza será afetado, a não ser que você comece a aplicar particionamento de dados com base em partition function filtrando os seus dados por faixas de valores, ou até mesmo aplicar índices em mais colunas do que o normal para tentar acelerar o pesquisa de dados, o que vai refletir também na performance.

    Agora imagine se única tabela apresenta uma falha o risco de você ter o seu ambiente prejudicado será muito maior.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    • Marcado como Resposta RenaPVieira quinta-feira, 15 de março de 2012 19:16
    quinta-feira, 15 de março de 2012 18:32

Todas as Respostas

  • Renan,

    Esta sua ideia vem totalmente contra as regras de integridade referencial, relacional e normalização de banco de dados, com base, nas técnicas de modelagem.

    A princípio este cenário pode ser vantajoso que se diz respeito a eliminação de colunas possivelmente iguais, mas por outro lado você esta tornando sua estrutura condicionada a trabalhar em uma única tabela que vai se tornar ao longo do tempo um repositório mal dimensionado, crescendo principalmente de forma vertical.

    O desempenho com certeza será afetado, a não ser que você comece a aplicar particionamento de dados com base em partition function filtrando os seus dados por faixas de valores, ou até mesmo aplicar índices em mais colunas do que o normal para tentar acelerar o pesquisa de dados, o que vai refletir também na performance.

    Agora imagine se única tabela apresenta uma falha o risco de você ter o seu ambiente prejudicado será muito maior.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    • Marcado como Resposta RenaPVieira quinta-feira, 15 de março de 2012 19:16
    quinta-feira, 15 de março de 2012 18:32
  •      Ok, Junior.. muito obrigado pela aula... você falou uma coisa .. que me deixou com a pulga atrás da orelha..

         "tornando sua estrutura condicionada a trabalhar em uma única tabela que vai se tornar ao longo do tempo um repositório mal dimensionado, crescendo principalmente de forma vertical."

        sem querer ser abusado mas já sendo.. imagine a seguinte situação..tenho cinco tabelas, (autor,  cliente, fornecedor, professor, vendedor)... nessas 5 tabelas eu tenho 17 colunas que se repetem nelas.. fazem assim o total de 85 colunas..

       e pior... o mesmo registro pode estar nas cinco tabelas.. porque o mesmo registro pode ser, cliente, autor, vend....

      nessa situação nao seria melhor criar uma de "cadastrogeral" uma de "tipos" e uma de relacionamento...N:N

      evitando assim.. a duplicidade de registro e o numero excessivo de colunas identicas..

      mais uma vez obrigado..

      Renan

        

     

    quinta-feira, 15 de março de 2012 19:42
  • Renan,

    Imagina longe de mim querer da aula, tenho muito a aprende!

    Mas esta sua observação é importante e válida, neste caso, vale a pena sim criar uma tabela de cadastrogeral e as demais tabelas fazendo os devidos relacionamentos.

    O importante é que a tabela de cadastrogeral esteja muito bem definida e que sua estrutura não se torne complexa e também inxada.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    quinta-feira, 15 de março de 2012 20:07