[firebase-br] Dúvidas de estrutura de tabelas /

[Gladiston Santana]

comentando...

Em qua., 22 de jul. de 2020 às 16:15, Luciano Griep <lucianogriep em gmail.com>
escreveu:

> Bom dia/tarde/noite pessoal.
>
> Tenho duas dúvidas relativas à estrutura do banco de dados:
>
> 1)  Imaginamos que uma tabela vai ter 100k+ registros que cresce
> diariamente. Destes, somente uns 20 terão determinada coluna preenchida,
> para todos os demais esta será null.
> Vale a pena criar o campo nesta tabela ou o melhor a se fazer é criar uma
> tabela nova com os campos necessários?
> Exemplo real: preciso criar o vínculo de Contas Pagar/Receber com sua
> origem, no sistema onde trabalho, até o momento, tenho 23 possíveis origens
> de titulos e hoje todos esses 23 campos estão na própria tabela master de
> contas_pag_rec, estamos reorganizando um pouco a bagunça e gostaria de
> saber vale a pena eu criar uma tabela única (Contas_Pag_Rec_Vinc) com os 23
> campos lá ou ainda 23 tabelas de vínculos específicos?
>
> Situações hipotéticas deve se levar em consideração outros fatores além do
gosto pessoal.
Não é porque geralmente repetimos uma solução que vamos impô-la todas as
vezes.
Se você prevê uma situação que será corriqueira, sua solução deverá ser
evolutiva em lidar com o problema no futuro e de preferência sem alterar a
estrutura existente.
Alterar uma estrutura existente pode afetar os programas que estão
funcionando bem, e a manutibilidade.
Geralmente soluções assim, envolvem a criação de novas tabelas e
interligá-las por meio de joins, PK e FK. Esse tipo de solução é bem
elegante, mas só é aplicável em '1 para n', se for '1 para 1' talvez queira
reconsiderar alterar a tabela.

Dividir em tabelas também aumenta a performance em alguns banco de dados,
por exemplo, o Oracle e MSSQL(firebird não) possuem recursos de
particionamento de dados onde tabelas mais usadas pode ficar numa área do
disco separada das demais, se acaso algum dia alguém quiser melhorar a
performance do banco de dados em algumas tabelas ou indices, poderá fazer
esse fatiamento em dispositivos diferentes, é o caso por exemplo de colocar
em SSD as tabelas mais corriqueiras.

2)  Nesta mesma tabela, tenho um campo de percentual, hoje ele está criado
> como numeric(15,2), sabendo que o limite é 100%, eu ganho algo em
> armazenamento/desempenho alterado seu valor para numeric(5,2)?
> Pesquisando encontramos a seguinte informação:
> Até 4 de precisão, o FB aloca 2B pro field, de 5 até 9, são 4B, acima
> disso, são 8B
> Só gostaria de validar, se alguém tem esse conhecimento. rs
>
> Olha, se você lidar com soma é melhor guardar tudo em float e depois
mascarar o resultado na aplicação.
Por causa da questão de arredondamento, numeric(x,y) sempre falha nos
resultados gerais quando auditados porque o que jogaram nele via aplicativo
não era um BCD similar ao numeric(x,y), mas um TFieldAsFloat.
Se for possivel desprezar os decimais, eu usaria o smallint.