Dúvida Modelagem

Dúvidas, dicas e atualizações sobre o Treinamento DBA Júnior.
Post Reply
portilho
Site Admin
Posts: 497
Joined: Wed May 29, 2013 8:51 am

Dúvida Modelagem

Post by portilho »

Dúvida enviada pelo amigo Clayton:

Gostaria de saber sua opinião sobre uma pergunta que de vez em quando fazem pra mim.

No banco de dados existe uma tabela chamado "Processo". Esta tabela tem mais ou menos 70 milhões de registro.
O desenvolvedor necessita incluir mais uma regra de negocio chamada retorno do processo, ou seja, uma nova modalidade de processo.
A pergunta dele foi a seguinte:
O que é melhor? Utilizar a tabela de "Processo" para o mesmo fim e acrescentar uma coluna com o tipo do processo ou Criar uma outra tabela chamado por ex.: ProcessoRetorno.?
As duas tabelas teriam os mesmos campos.

Como a tabela Processo já estava grande, pedi que criasse outra pra tratar do assunto "Retorno".
Assim não cresceria tanto a tabela.

Você pensaria da mesma forma? Ou era melhor ter usado a mesma tabela
Se utilizasse a mesma tabela, utilizando um campo de tipo (com índice) seria ruim?

Só estou perguntando, não encontrei uma teoria que justificasse melhor qualquer uma das maneiras de fazer.

Muitas vezes tenho q impressão que em se tratando de desempenho, vai dar no mesmo.

portilho
Site Admin
Posts: 497
Joined: Wed May 29, 2013 8:51 am

Re: Dúvida Modelagem

Post by portilho »

Realmente quanto "mais larga" (quanto mais colunas e/ou quanto maior o comprimento destas colunas) é uma tabela, pior. Se as linhas ficarem "muito largas", algumas, muitas ou todas podem não caber mais no Bloco de 8 KB padrão do Oracle Database, e aí para ler 01 única linha, o Oracle precisa de mais de 01 I/O. Este problema chama-se Chained Rows (INSERT que não coube no bloco) ou Migrated Rows (caso de UPDATE que não coube no bloco).

E mais uma coluna, é provavelmente mais um índice para ser atualizado quando a PROCESSO sofrer DML, ou seja, mais I/O.

Portanto, mesmo se esta nova coluna ficar na tabela PROCESSO, é melhor colocar um pequeno campo ID_RETORNO, e a descrição do RETORNO em uma tabela separada.

Mas esse impacto (de adicionar um campo na PROCESSO) deve ser pesado como este campo será consultado (SELECT) este campo no futuro: se o campo for consultado sozinho (ID_PROCESSO e ID_RETORNO), esta consulta potencialmente fará menos I/Os se estiver em uma tabela separada. Mas se esta coluna for consultada junto de outras que já estão na PROCESSO, será desperdício de I/O ler esta outra tabela.
Seguindo a mesma linha, tem que pegar colunas que não são consultadas na PROCESSO (ou são consultadas de forma isolada) e ir passando para tabelas separadas.

Post Reply