MODELAGEM E CONCORRÊNCIA DE TABELA
Eu fiz uma [Ô]normatização[Ô] na estrutura de meu banco de dados pq estava muito complicado montar relatórios.
Antes eu tinha uma tabela para entrada e saÃda de produtos, uma para matéria prima,
agora eu coloco tudo na mesma tabela, e chamei ela de EstoqueES ( Es = entrada e saÃda )
nessa tabela eu adiciono meus itens/produtos/matprima separando somente por um campo (tipocadastro)
a pergunta é!
De acordo a experiência de vcs, isso vai começar a provocar lentidão no meu sistema, já que a tabela será acessada mais vezes ?
e caso sim, a partir de quantos milhões de registros ?
ou não vai provocar lentidão ?
espero que tenha passado a dúvida corretamente.
Tive problema com a escrita fiscal onde tinha somente uma tabela de notas onde ficava nota de entrada, saÃda, serviço e com o tempo as consulta dava timeout, daà separei. Uma tabela para notas de entrada, outra de saÃda e outra de serviços e a mesma coisa para os produtos das notas. Uma tabela para Produtos da nota de entrada e outra para saÃda. O Banco que uso é o Mysql e separando assim a performance ficou melhor.
Citação:isso vai começar a provocar lentidão no meu sistema? a partir de quantos milhões de registros ?
Não sei qual banco esta usando mas mesmo assim a tendencia é ficar lento.
Bom dia.
Eu acredito que você fez a coisa certa.
Até porque se você separar em tabelas para entrada e tabelas para saÃda, um dia haverão tantas entradas e tantas saÃdas que as duas tabelas irão ficar lentas também. E não terá mais como fragmentar as tabelas.
Claro, as tabelas [Ô]faz tudo[Ô] são impraticáveis, senão o sistema precisaria ter apenas uma única tabela. Bem modelado, com as chaves primárias, estrangeiras, os Ãndices criados corretamente (Ãndices podem deixar o sistema lento, por incrÃvel que pareça, porque precisam ser alimentados em cada delete/insert/update dos campos que o compõem, então Ãndices sempre procuro usar com bastante cautela e somente campos realmente necessários indexados).
Por conclusão, penso eu, em tabelas separadas, você teria talvez um código mais complexo e comandos SQL precisariam usar UNION ou UNION ALL para achar e cruzar dados de entrada e saÃda (fazer um fluxo, por exemplo). Talvez consumisse mais recursos e tempo que em tabela única e bem indexada, com os tipos de campos bem normalizados também. Tipo, não usar bigserial para um campo que tem valores apenas positivos entre 1 e 255 (seria um exagero e desperdÃcio usar bigserial).
Acredito, de uma forma geral, que tabelas [Ô]faz tudo[Ô] são um problema. Criar tabelas desnecessárias também.
Penso que você fez o procedimento correto.
Tudo de bom.
Citação:Claro, as tabelas [Ô]faz tudo[Ô] são impraticáveis, senão o sistema precisaria ter apenas uma única tabela. Bem modelado, com as chaves primárias, estrangeiras, os Ãndices criados corretamente (Ãndices podem deixar o sistema lento, por incrÃvel que pareça, porque precisam ser alimentados em cada delete/insert/update dos campos que o compõem, então Ãndices sempre procuro usar com bastante cautela e somente campos realmente necessários indexados).
Meu banco é MYSQL.
uma vez fiz um sistema [Ô]PCP[Ô] ( produção de fábrica ) sob encomenda, que em 1 das tabelas de saÃda de matéria prima tinha mais de 5 milhões de registros.
Em uma das consultas desse sistema, englobava mais 12 tabelas (JOIN) junto com essa que tinha mais de 5 milhões de registros, e o sistema demorava no máximo 1.5 / 2 segundos para processar uma consulta em rede local.
Eu ainda imagino fazer tudo numa tabela só. pois quando olho para o emissor de nota fiscal eletrônica, são as mesmas informações para preencher tanto entrada quanto saÃda.
Valeu pelas respostas. se alguém quiser entrar com sua opinião ou experiência vou manter o tópico aberto.
Citação:
EstoqueES (entrada e saida) - cab, det, rod
=========================================================================
CAB
Codigo
CodOperacao ( tabela referências, venda/compra finalizada, venda de serviço, saida manual, entrada manual )
Agora
DataTransacao
NumeroNota
ChaveNfe
CodEmissor
CodDestinatario
ValorProdutos
ValorDesconto
CodUsuario
CodCaixa
CodParcelamento
CodEmpresa
OBS
Excluido ( boolean )
IPLocal
DET
CodCab
CodUsuario
Agora
CodigoItem
Impostos
CustoItem
VendaItem
Qtd
Cancelado
DETns //numero de serie
CodDet
CodEstoqueNumSerie
numSerie
ROD
CodCab
CodUsuario
CodCaixa
Agora
DataPgto
ValorPgto
CodFormaPgto
Até porque, vai facilitar e muito as consultas mais complexas que usariam SubSelects e UNIONs, que são duas operações que consomem muito do processamento. Fora que as consultas ficam mais legÃveis e de fácil manutenção.
Seja como for, em casos que eu sei que o banco de dados vai ser usado para armazenar grandes informações... Eu crio uma pequena aplicação para enviar dados aleatórios para o banco de dados, de forma que deixe ele num tamanho relativo a quantidade de informação armazenada prevista num perÃodo de 2 anos de produção.
E depois realizo as consultas normais no meu sistema e vejo a velocidade. (Lembrando que quanto mais próximas das condições usadas no ambiente de produção melhor)
Abraços!