[firebase-br] Re: qual o melhor jeito de modelar ?

Pha-Lista lista em pha.com.br
Qua Maio 11 08:47:18 -03 2005 

Se houver diferenca de velocidad sera minima.

Quanto a tabela de de Clientes e Fornecedores, deve ser unica para evitar duplicacoes, pois se um cliente devolve uma mercadoria voce tem que dar entrada no livro fiscal de entradas e o cliente passa a ser fornecedor e vice-versa, alem de outros casos com Clientes que sao fornecedores e clientes ao mesmo tempo, remessa para conserto etc.

Na minha opiniao nao existe Cliente e Fornecedores, existe sim um cadastro unico de Pessoas Fisicas e Juridicas, e neste cadastro voce deve ter campos que indique se o Cliente, Forncedor, Transportados, Vendedor, Comprador, estes campos devem ser separados pois a mesma entidade pode ser varias coisas ao mesmo tempo.

Alem disso acho que se deve criar duas tabelas, uma para a Entidade (Codigo, Nome, Razao Social, etc) e outra para o Endereço (CNPJ, CPF, IE, RG, Logradouro, Cidade, etc), pois muitas empresas tem filiais e ha muitos casos onde queremos tratar a empresa como um todos, nao importando a filial.

Ja para os parametros voce pode criar tabelas separada para compras, vendas, etc.

Tenha tambem em mente que a maioria dos cadastros de enderecoes entao bem separados (Tipo do Logradouro "Rua, Avenida, Travessa, etc", Logradouro, Numero, Complemento, Bairro, etc), o do IRPF e um otimo exemplo disso, alem do mais e mais facil juntar do que separar depois.

PHA
Nova Odessa / SP - Brazil

-----Mensagem original-----
From: Almir Fiorio almir74 em gmx.net
Date: Tue, 10 May 2005 16:51:10 -0300
To: FireBase lista em firebase.com.br
Subject: Re: [firebase-br] Re: qual o melhor jeito de modelar ?

> *Amigo Eduardo
> 
> Compreendo que todo mundo recomende que tem que criar uma tabela pra 
> cada situação
> 
> Um Amigo disse assim :
> *
> */"" Eu uso 1 Tabela pra Clientes/fornecedores
> Eu uso 1 Tabela pra Pedidos Compra/Venda
> Eu uso 1 Tabela pra Contas Pagar/Receber
> E fica tão rapido quanto se eu separasse as tabelas! Dividir é 
> redundancia!! ""
> /*
> *
> Eu ja percebi e vi que tabela as tabelas acima tem os mesmos campos! ate 
> cliente e fornecedor!!
> Por isso que tenho a duvida, eu so quero saber se deixar tudo junto nao 
> vai haver perda de velocidade
> do que se deixasse as tabelas separaradas !!
> Por que ai em vez de 4 tabelas (Pedidos tem tambem a tabela de itens) 
> serão  8 tabelas !!
>  
> *
> /*Como disse isto não depende da modelagem, depende da sua qualidade de
> implantação e da qualidade de definição das chaves primárias e estrangeiras.
> Se fizer direitinho isto só fica lento com alguns milhões de registros
> (concordo com seu amigo DBA o FireBird dá conta do recado). Se tem dúvida,
> faça absolutamente separado e trabalhe com mais entidades. Crie visões que
> fazem selects com union / union all, e utilize SP (Stored Procedures) para
> fazer cálculos mais pesados no banco. Assim não há como ficar lento.*/
> 
> *Nao tenho dúivida, so quero fazer do modo mais rapido independente de Triggers, SP, Querys e Views!! Realmente nesse ponto que nao da pra entender! por que vc diz pra separar
> mas depois concorda com meu amigo DBA quando ele diz que  o firebird da conta do recado
> se deixar tudo junto!! mas ele da conta do recado coma mesma velocidade do que estivesse separado ou perde velocidade se todos estiverem usando a mesma tabela ? 
> 
> Aguardo Respostas
> 
> Grato
> Almir Fiorio*
> 
> Eduardo Jedliczka escreveu:
> 
> >Almir....
> >
> >A Boa prática de programação, diz que cada "entidade" é um conjunto único,
> >estável e não redundante de informações.
> >
> >Dependendo de seu ponto de vista, clientes, fornecedores, empregados,
> >representantes ou contatos são todos "membros" de uma entidade "relações"
> >(contatos)
> >
> >Dependendo de seu ponto de vista, clientes e fornecedores podem ser
> >entidades distintas por que simplesmente possuem campos que não combinam.
> >p.e.: não há necessidade de saber o prazo médio de entrega de um cliente ou
> >faturamento mensal de um fornecedor...
> >
> >A mesma regra vale para pagamentos e recebimentos, baixas e
> >(re)parcelamentos...
> >
> >Como disse isto não depende da modelagem, depende da sua qualidade de
> >implantação e da qualidade de definição das chaves primárias e estrangeiras.
> >Se fizer direitinho isto só fica lento com alguns milhões de registros
> >(concordo com seu amigo DBA o FireBird dá conta do recado). Se tem dúvida,
> >faça absolutamente separado e trabalhe com mais entidades. Crie visões que
> >fazem selects com union / union all, e utilize SP (Stored Procedures) para
> >fazer cálculos mais pesados no banco. Assim não há como ficar lento.
> >
> >[s]
> >
> >==========================
> >Eduardo Jedliczka
> >Gerasoft Informática
> >Apucarana - Pr
> >==========================
> >
> >[s]
> >
> >==========================
> >Eduardo Jedliczka
> >Gerasoft Informática
> >Apucarana - Pr
> >==========================
> >
> >----- Original Message ----- 
> >From: "Almir Fiorio" <almir74 em gmx.net>
> >To: "FireBase" <lista em firebase.com.br>
> >Sent: Tuesday, May 10, 2005 3:39 PM
> >Subject: Re: [firebase-br] Re: qual o melhor jeito de modelar ?
> >
> >
> >  
> >
> >>*Depende
> >>
> >>se for pedido de venda é cliente  !!! se for pedido de compra é fornecedor
> >>
> >>Mas isso nao é problema pq eu tb posso unificar clientes e fornecedores
> >>numa unica tabela
> >>diferenciando eles por um cmapo chamado categoria a tabela
> >>
> >>E ao fazer pedido de compra eu coloco pra listar apenas
> >>    
> >>
> >categoria="cliente"
> >  
> >
> >>E ao fazer pedido de venda eu coloco pra listar apenas
> >>categoria="fornecedor"
> >>
> >>a unica duvida é realmente se com as tabelas unificadas posso ter a
> >>mesma velocidade
> >>do que se elas estivesssem separadas!
> >>
> >>quem disse que ele vai ficar rapido tanto junto quanto separado foi um
> >>DBA amigo meu!
> >>pq ele disse que firebird é um SGBD que sabe gerenciar bem as
> >>    
> >>
> >tranbsacoes!!!
> >  
> >
> >>Nao sao milhoes de registros! sao 40 pedidos por dia com 50 produtos
> >>cada !!!
> >>
> >>Mas eu quero fazer de modo que fique o mais rapido possivel
> >>pq quero estar pronto pro futuro! e nmão penso em mexer nisso aki depois
> >>
> >>Abraços
> >>Almir*
> >>
> >>
> >>
> >>
> >>
> >>
> >>Eduardo Jedliczka escreveu:
> >>
> >>    
> >>
> >>>E código do pedido está ligado no cliente ou fornecedor ????
> >>>
> >>>Quanto à velocidade, quantos milhões de registros você pensa em armazenar
> >>>      
> >>>
> >em
> >  
> >
> >>>cada tabela para isto aí ficar lento ??? Disse que se obedecer os
> >>>      
> >>>
> >conceitos
> >  
> >
> >>>do ambiente C/S, o seu sistema vai ficar rápido independente de estar
> >>>      
> >>>
> >junto
> >  
> >
> >>>ou separado...
> >>>
> >>>
> >>>[s]
> >>>
> >>>==========================
> >>>Eduardo Jedliczka
> >>>Gerasoft Informática
> >>>Apucarana - Pr
> >>>==========================
> >>>
> >>>----- Original Message ----- 
> >>>From: "Almir Fiorio" <almir74 em gmx.net>
> >>>To: "FireBase" <lista em firebase.com.br>
> >>>Sent: Tuesday, May 10, 2005 3:10 PM
> >>>Subject: Re: [firebase-br] Re: qual o melhor jeito de modelar ?
> >>>
> >>>
> >>>
> >>>
> >>>      
> >>>
> >>>>Amigo Eduaredo
> >>>>
> >>>>se eu agrupar eu nao vou ter problem a não
> >>>>
> >>>>1* - a tabela de contas terá relacionamento pelo codigo do pedido
> >>>>2* - na tabela de pedidos vai ter um campo de status dfizendo se é
> >>>>compra ou venda!!
> >>>>
> >>>>Grato
> >>>>almir
> >>>>
> >>>>
> >>>>
> >>>>Eduardo Jedliczka escreveu:
> >>>>
> >>>>
> >>>>
> >>>>        
> >>>>
> >>>>>é muito relativo, se você agrupar as tabelas, terá um problema na
> >>>>>consistência das Foreign Key (ou terá que duplicar as chaves em campos
> >>>>>distintos e fazer a consistências em "arco" utilizando triggers).
> >>>>>
> >>>>>Acho que não vale a pena!!! faça tudo separado, assim você respeita a
> >>>>>individualidade de cada entidade.
> >>>>>
> >>>>>Quanto à performance (neste tipo de problema), se vai ficar tudo junto
> >>>>>          
> >>>>>
> >ou
> >  
> >
> >>>>>separado pode ser lento ou rápido, depende mais do seu aplicativo do
> >>>>>          
> >>>>>
> >que
> >  
> >
> >>>>>          
> >>>>>
> >>>da
> >>>
> >>>
> >>>      
> >>>
> >>>>>modelagem..
> >>>>>
> >>>>>
> >>>>>[s]
> >>>>>
> >>>>>==========================
> >>>>>Eduardo Jedliczka
> >>>>>Gerasoft Informática
> >>>>>Apucarana - Pr
> >>>>>==========================
> >>>>>
> >>>>>----- Original Message ----- 
> >>>>>From: "Almir Fiorio" <almir74 em gmx.net>
> >>>>>To: "FireBase" <lista em firebase.com.br>
> >>>>>Sent: Tuesday, May 10, 2005 12:57 PM
> >>>>>Subject: [firebase-br] Re: qual o melhor jeito de modelar ?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>            
> >>>>>>
> >>>>>>>Amigos
> >>>>>>>
> >>>>>>>Eu tenho que colocar pedidos de compra e de venda no meu banco de
> >>>>>>>dados assim como contas a pagar e a Receber ! Tem gente que usa a
> >>>>>>>mesma tabela pra pedidos de Compra e Venda e  tambem usam a mesma
> >>>>>>>tabelça pra Contas a pagar e contas a receber colocando um campo pra
> >>>>>>>diferenciar como status por exemplo que indica se é compra ou venda!!
> >>>>>>>eu acho a unificação boa pq vc nao precisa ficar criando tabela com
> >>>>>>>campos repetidos e deixa o banco com menos tabelas e mais leve!!
> >>>>>>>
> >>>>>>>Mas ai eu tava pensando bem e acho que unificar pedidos de compra e
> >>>>>>>venda na mesma tabela nao é uma boa!
> >>>>>>>da mesma forma que contas pagar/receber devem ficar separados!
> >>>>>>>isso pode atrapalhar a performance do banco nas pesquisas, inserts e
> >>>>>>>updates
> >>>>>>>Tendo em vcista que as pessoas que forem mecher com as duas coisas
> >>>>>>>estarão acessando a mesma tabela
> >>>>>>>
> >>>>>>>imagina dois usuarios diferentes estarem consultando contas a receber
> >>>>>>>e a pagar ao memso tempo ?
> >>>>>>>imagina vc gravar registros em contas a receber se tiver os outros
> >>>>>>>usuarios usando ao memso tempo pra consultar ou incluir contas a
> >>>>>>>              
> >>>>>>>
> >pagar
> >  
> >
> >>>>>>>              
> >>>>>>>
> >>>?
> >>>
> >>>
> >>>      
> >>>
> >>>>>>>o que vcs acham desta unificação ?  Atrapalha ?
> >>>>>>>
> >>>>>>>Ou é melhor separar pra ganhar mais velocidade nos acessos, inclusoes
> >>>>>>>e alterações ?
> >>>>>>>
> >>>>>>>Grato
> >>>>>>>Almir Fiorio
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>______________________________________________
> >>>>>>FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> >>>>>>Para editar sua configuração na lista, use o endereço
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>______________________________________________
> >>>>>FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> >>>>>Para editar sua configuração na lista, use o endereço
> >>>>>
> >>>>>
> >>>>>          
> >>>>>
> >>>http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> >>>
> >>>
> >>>      
> >>>
> >>>>>Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>          
> >>>>>
> >>>>______________________________________________
> >>>>FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> >>>>Para editar sua configuração na lista, use o endereço
> >>>>
> >>>>
> >>>>        
> >>>>
> >>>http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> >>>
> >>>
> >>>      
> >>>
> >>>>Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>        
> >>>>
> >>>______________________________________________
> >>>FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> >>>Para editar sua configuração na lista, use o endereço
> >>>      
> >>>
> >http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> >  
> >
> >>>Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >>>
> >>>
> >>>
> >>>
> >>>      
> >>>
> >>______________________________________________
> >>FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> >>Para editar sua configuração na lista, use o endereço
> >>    
> >>
> >http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> >  
> >
> >>Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >>
> >>
> >>    
> >>
> >
> >
> >______________________________________________
> >FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> >Para editar sua configuração na lista, use o endereço http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> >Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >
> >
> >  
> >
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa

Mais detalhes sobre a lista de discussão lista