É melhor Unificar Tabelas ou Separar pra Ganhar Velocidade?
[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]
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
Curtidas 0
Respostas
Almirf
06/05/2005
Obs : Eu estou criando o banco em FIREBIRD (SGBD)
GOSTEI 0
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.....
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
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+
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
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.
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
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.
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
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?
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