none
Modelagem de Dados - Tabela de pagamentos para profissionais - Pagamentos podem ser referentes à tipos de registros diferentes

    Question

  • Boa tarde,

         Estou montando uma tabela que será utilizada para controlar pagamento dos profissionais. Algo do tipo TB_PROFISSIONAL_PAGAMENTOS.

         Até ai tudo bem, a questão é:
         Esses pagamentos podem ser referentes à Serviços ou Produtos(ou futuramente qualquer outra coisa).
         Eu tenho uma tabela de Serviços e uma tabela de Produtos.

         Como fazer esse relacionamento dos Pagamentos com os tipos(Serviços ou Produtos) da melhor maneira ?

         Criar 2 tabelas diferentes(para relacionar) ? O que causaria um campo sempre vazio(nulo) na tabela de Pagamentos.
         ou
         Criar 1 campo só na tabela de Pagamentos e um outro campo TIPO(que teria algo assim: 1-Serviço 2-Produto). 
         E através desse campo eu sei se o ID de relacionamento é de Serviço ou Produto.

         Espero ter conseguido explicar minha questão.
         Bem parecido com uma tabela de Contas à Pagar de uma empresa. Essas contas podem ser para funcionários da empresa, como também para fornecedores por exemplo. Como relacionar esses registros ?
    Friday, December 18, 2009 5:40 PM

Answers

  • Boa tarde Kaue

    Tenho muitos casos parecidos com o seu, e baseado não só na questão da modelagem e da normalização, mas também conversando com arquitetos cheguei a conclusão que modelo ideal é o de criar na tabela os dois atributos diferentes (campos) Id_Servico e Id_Produto , pelo fato de pertencerem a  entidades (tabelas) diferentes, esse é o ponto principal.



    Espero ter ajudado
    Anderson - DBA/MCP/MCTS/MCITP/MCT - Sua pergunta foi respondida ? Marque-a como tal! www.myspace.com/andersondpa
    • Marked as answer by kauebranco Monday, December 21, 2009 12:18 PM
    Friday, December 18, 2009 6:01 PM
  • Boa Tarde,

    Eu acredito que tenha havido uma falha no projeto anterior e você agora está "sofrendo" com essa falha.
    O pagamento é referente a "algo" e esse "algo" atualmente pode ser um produto ou um serviço. "Algo" sempre será pago independente do que seja. O mais comum seria você especializar produtos e serviços em "algo" e relacionar "algo" com a tabela de pagamentos. Ex:

    Algo (IDAlgo (PK), <Características Comuns de Produtos e Serviços>)
    Produtos (IDAlgo (PK, FK), <Características Únicas de Produtos>)
    Serviços (IDAlgo (PK, FK), <Características Únicas de Serviços>)
    Pagamentos (IDAlgo (FK), <Características de Pagamentos>)

    Ou opcionalmente

    Produtos (Características de Produtos)
    Serviços (Características de Serviços)
    PagamentosProdutos (IDProduto (FK), <Características de Pagamentos de Produtos>)
    PagamentosServiços (IDServiço (FK), <Características de Serviços>)

    Acredito que se o pagamento tiver as mesmas características para produtos e serviços a primeira abordagem seja melhor. Se o pagamento de serviços e produtos for muito diferenciado, talvez a segunda seja mais interessante.

    Utilizar dois atributos (hora para Produto e Hora para serviço) é uma abordagem possível, mas envolve uma série de controles adicionais de validação (quando uma for preenchida a outra não pode ser nula e vice-versa) nas operações DML. Basta aparecer outra coisa e isso representa mais uma coluna, mais dois campos nulos e mais validações. Se não for aparecer mais nada ela pode ser considerada.

    A idéia de criar um campo só não é interessante, pois, você não conseguirá fazer o relacionamento entre as tabelas. Isso irá abrir brechas para dados inválidos e (ou) mais validações.

    Sugiro dar uma olhadinha nos links abaixo:

    A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte I
    http://gustavomaiaaguiar.spaces.live.com/Blog/cns!F4F5C630410B9865!794.entry

    A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte II
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!814.entry

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    SQL Server Saturday Night
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!878.entry


    Classifique as respostas. O seu feedback é imprescindível
    Friday, December 18, 2009 8:37 PM
    Moderator
  • Kauê,
    eu criaria somente um campo de ID na tabela de pagamentos e outro pra dizer de qual tipo ele é...
    já fiz coisas desse tipo e também conversei com o pessoal que trabalhar aqui com ERP junto comigo...
    O tempo de um INNER JOIN para isso seria minimo...

    Abraços,
    Monday, December 21, 2009 1:11 PM

All replies

  • Boa tarde Kaue

    Tenho muitos casos parecidos com o seu, e baseado não só na questão da modelagem e da normalização, mas também conversando com arquitetos cheguei a conclusão que modelo ideal é o de criar na tabela os dois atributos diferentes (campos) Id_Servico e Id_Produto , pelo fato de pertencerem a  entidades (tabelas) diferentes, esse é o ponto principal.



    Espero ter ajudado
    Anderson - DBA/MCP/MCTS/MCITP/MCT - Sua pergunta foi respondida ? Marque-a como tal! www.myspace.com/andersondpa
    • Marked as answer by kauebranco Monday, December 21, 2009 12:18 PM
    Friday, December 18, 2009 6:01 PM
  • Boa Tarde,

    Eu acredito que tenha havido uma falha no projeto anterior e você agora está "sofrendo" com essa falha.
    O pagamento é referente a "algo" e esse "algo" atualmente pode ser um produto ou um serviço. "Algo" sempre será pago independente do que seja. O mais comum seria você especializar produtos e serviços em "algo" e relacionar "algo" com a tabela de pagamentos. Ex:

    Algo (IDAlgo (PK), <Características Comuns de Produtos e Serviços>)
    Produtos (IDAlgo (PK, FK), <Características Únicas de Produtos>)
    Serviços (IDAlgo (PK, FK), <Características Únicas de Serviços>)
    Pagamentos (IDAlgo (FK), <Características de Pagamentos>)

    Ou opcionalmente

    Produtos (Características de Produtos)
    Serviços (Características de Serviços)
    PagamentosProdutos (IDProduto (FK), <Características de Pagamentos de Produtos>)
    PagamentosServiços (IDServiço (FK), <Características de Serviços>)

    Acredito que se o pagamento tiver as mesmas características para produtos e serviços a primeira abordagem seja melhor. Se o pagamento de serviços e produtos for muito diferenciado, talvez a segunda seja mais interessante.

    Utilizar dois atributos (hora para Produto e Hora para serviço) é uma abordagem possível, mas envolve uma série de controles adicionais de validação (quando uma for preenchida a outra não pode ser nula e vice-versa) nas operações DML. Basta aparecer outra coisa e isso representa mais uma coluna, mais dois campos nulos e mais validações. Se não for aparecer mais nada ela pode ser considerada.

    A idéia de criar um campo só não é interessante, pois, você não conseguirá fazer o relacionamento entre as tabelas. Isso irá abrir brechas para dados inválidos e (ou) mais validações.

    Sugiro dar uma olhadinha nos links abaixo:

    A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte I
    http://gustavomaiaaguiar.spaces.live.com/Blog/cns!F4F5C630410B9865!794.entry

    A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte II
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!814.entry

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    SQL Server Saturday Night
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!878.entry


    Classifique as respostas. O seu feedback é imprescindível
    Friday, December 18, 2009 8:37 PM
    Moderator
  • Bom dia amigos,

       Agradeço a atenção e resposta de vocês.

       Gustavo,
       Felizmente não estou correndo atrás de um problema em um projeto antigo. Meu medo é justamente isso acontecer, e por isso estou tentando achar a solução "correta" para esse caso.
       É muito bom o seu artigo, porém, como você mesmo diz não existe um certo e um errado, que no caso é exatamente o que continua dificultando a minha tomada de decisão. 

       Mais acredito também que não existam mais opiniões em cima dessa dúvida. É um caso bem específico e com certeza milhares de variáveis(difíceis de expor) devem ser levadas em consideração.

      Obrigado mais uma vez.
       
    Monday, December 21, 2009 12:18 PM
  • Kauê,
    eu criaria somente um campo de ID na tabela de pagamentos e outro pra dizer de qual tipo ele é...
    já fiz coisas desse tipo e também conversei com o pessoal que trabalhar aqui com ERP junto comigo...
    O tempo de um INNER JOIN para isso seria minimo...

    Abraços,
    Monday, December 21, 2009 1:11 PM
  • Olá Kauebranco,

    Eu faço questão de frisar que realmente não existe resposta certa, pois, cada caso é um caso. O que eu sugiro é que você tente visualizar em qual das implementações seu projeto se encaixa melhor, ou seja, de todas qual terá mais vantagens e qual as desvantagens serão menos penosas. Eu tenho uma certa tendência pela opção (uma tabela para cada classe), pois, acho que ela é a mais "resistente" a mudanças e implementações, mas é preciso avaliar. Acho que até o fim do ano devo apresentar a parte III do artigo, mas eu diria que seguinte o que foi exposto até agora já é possível decidir muita coisa.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Monitorando bloqueios com o uso de Recursive Common Table Expressions
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!885.entry


    Classifique as respostas. O seu feedback é imprescindível
    Monday, December 21, 2009 2:22 PM
    Moderator
  • Olá,

    Uma questão que me parece que ainda não foi abordada é a possibilidade de um único pagamento referente a um ou mais produtos e serviços.

    Essa situação levaria a criação de uma outra tabela, relacionada à tabela principal de pagamentos, ou duas (uma para produtos, outra para serviços, que é a forma que eu também adotaria).
    Monday, December 21, 2009 2:51 PM
  • Olá Cláudio,

    Pois é. Evoluções de negócio podem inviabilizar umas e favorecer outras. Se isso ocorrer certamente muita coisa terá de ser revista.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Monitorando bloqueios com o uso de Recursive Common Table Expressions
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!885.entry


    Classifique as respostas. O seu feedback é imprescindível
    Monday, December 21, 2009 2:53 PM
    Moderator