[firebase-br] Re: qual o melhor jeito de modelar ?
Almir Fiorio
almir74 em gmx.net
Ter Maio 10 16:54:06 -03 2005
*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
>
>
>
>
Mais detalhes sobre a lista de discussão lista