É melhor Unificar Tabelas ou Separar pra Ganhar Velocidade?

Modelagem

06/05/2005

[b:149c2aa1b5]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 achma desta unificação ? Atrapalha ?

Ou é melhor separar pra ganhar mais velocidade nos acessos, inclusoes e alterações ?

Grato
Almir Fiorio[/b:149c2aa1b5]


Almirf

Almirf

Curtidas 0

Respostas

Almirf

Almirf

06/05/2005

Obs : Eu estou criando o banco em FIREBIRD (SGBD)


GOSTEI 0
Camilo

Camilo

06/05/2005

caro almirf,
naum acho uma boa unificar contas a receber e contas a pagar, pois são opostos.... e nas telas de consulta, quem tiver consultando contas a receber naum precisa retornar nenhuma informação de contas a contas a pagar, por outro lado vc economizaria 50¬ de tempo em desenvolvimento, pq as insersões, alterações, exclusões, impressões e pesquisa... vc iria fazer cada um deles uma unica vez, sendo pra contas a receber e a pagar, em uma tela só pra os dois... é um caso particular de se pensar... tem q ter cuidado com o tafego na rede, q é muito importante... e q com o passar do tempo aumenta cada ve mais.....


GOSTEI 0
Afarias

Afarias

06/05/2005

particularmente prefiro 1 tabela apenas. tomando-se os devidos cuidados (técnicas c/s) não deve haver impácto na performance.

só pensaria em separar as tabelas em casos de sistemas muito ´pesados´, onde o número de transações diárias ou por hora seja *muito* grande.

T+


GOSTEI 0
Beppe

Beppe

06/05/2005

Há inúmeras medidas que pode adotar.

Analize quais os principais usos. Se fizer a divisão horizontal, as tabelas precisaram ser reunidas. Nunca analizei esta questão de performance com UNION, veja os planos de acesso gerados.

Pode criar views que te retornam apenas os dados desejados. Alguns bancos materializam elas para que possam ser acessadas tanto em separado como juntas com pouco overhead. Mas não é este o caso do FB/IB.

Pode tanbém escolher fazer inserts em tabelas sepadaras, que serão carregadas na tabela posteriormente em batch.

Etc.


GOSTEI 0
Raserafim

Raserafim

06/05/2005

eu sempre usava de forma unificada. porém um sistema feito a uns 5 anos atrás em que fiz a base em Access, hoje estou sofrendo com isso por causa do grande número de registros e com isso a performance tá lá em baixo. esse sistema não aguanta mais muito tempo, vou ter q fazer outro.
mas claro que hoje não usaria Access, uso o firebird, e apesar de a performance não cair com a quantidade de dados que teria no banco access, mas pelo menos sinalisa que pode ter sim uma queda de performance com uma quantidade maior.
então vou passar a utilizar de forma separada.


GOSTEI 0
Raserafim

Raserafim

06/05/2005

pensando um pouco mais...
qual é o mais correto, ou o mais aconselhavel, diante da perspectiva da modelagem de dados?
apesar de os campos serem os mesmos, mas a lógica da transação não outra? exatamente o oposto?
então?


GOSTEI 0
POSTAR