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

[Eduardo Jedliczka]

Quando se fala de aplicações concorrentes, com milhões de registros, o tempo
de espera deve ser da casa de poucos décimos de segundos... 3 segundos para
um operador parece uma eternidade... (mil registros é uma miséria para um
banco como o FireBird, ele filtra isto num tempo tão pequeno que nem dá para
contar)

Quem dirá minutos.

Mas deixe-me pronunciar pela última vez sobre este assunto.

Almir, ou separa tudo ou junta tudo... esse negócio de meio a meio vai te
dar uma dor de cabeça que você não faz idéia.

Se as tabelas forem exatamente iguais, e não houver previsão de mudanças
individualizadas, por menor que seja, deixem juntas, terá menos tabelas,
menos telas de cadastro e muito menos desperdício de tempo.

Se houver uma possibilidade de mudança, por menor que seja, deixe separado,
e ganhe flexibilidade...

[s]

==========================
Eduardo Jedliczka
Gerasoft Informática
Apucarana - Pr
==========================

----- Original Message ----- 
From: "Almir Fiorio" <almir74 em gmx.net>
To: <lista em firebase.com.br>
Sent: Wednesday, May 11, 2005 12:45 PM
Subject: Re: [firebase-br] Re: qual o melhor jeito de modelar ?


> Amigo Eduardo!
>
> > *
> > Eu  Entendi !!!
> > Justamente por causa disso que eu disse em nao separar por que as duas
> > tabelas usam os mesmos campos !!
> >
> > Acho que vou separar entao somente as tabelas de clientes e
> > fornecedores pra dar uma velocidade
> > por que aki  temos cerca de 1000 clientes contra 50 fornecedores
> > melhor separar ne ?
> >
> > Essa diferença que aparece depois de milhoões de registros é muito
> > absurda?
> > Diferença de quantos minutos de leitura?
> >
> > Grato
> > Almir*
> >
> >
> > Eduardo Jedliczka escreveu:
> >
> >>Cara, definitivamente você não entendeu absolutamente nada do que eu
> >>escrevi...
> >>
> >>Eu disse que praticamente não há diferença de desempenho se deixar junto
ou
> >>separado, a diferença só aparece depois de alguns milhões de registros.
> >>
> >>Eu só disse para tomar cuidado com as PKs e FKs, para não ter que
corrigir a
> >>modelagem com triggers.
> >>
> >>E que o que faz um sistema rápido ou lento é mais o Front-End (forma de
> >>programar) e o conjunto de componentes (e transacional) do que a
modelagem
> >>em si...
> >>
> >>Se as tabelas são iguais, não perca tempo, deixe tudo junto, mas se
amanhã
> >>aparecer campos distintos entre clientes e fornecedores, ou entre as
contas
> >>à pagar e receber, que devem ser obrigatórios, vai ter que consistir com
> >>triggers, ou seja, ficar remendando....
> >>
> >>
> >>[s]
> >>
> >>==========================
> >>Eduardo Jedliczka
> >>Gerasoft Informática
> >>Apucarana - Pr
> >>==========================
> >>