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

[Eduardo Jedliczka]

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
>
>