� melhor Unificar Tabelas ou Separar pra Ganhar Velocidade?

Question

[b:149c2aa1b5]AmigosEu 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  ta...

Almirf · Answer

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

Camilo · Answer

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

Afarias · Answer

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+

Beppe · Answer

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

Raserafim · Answer

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.

Raserafim · Answer

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