[firebase-br] OFF - Opinião sobre tabelas...

[Pedro]

Vou comentando logo abaixo, nas entrelinhas...

At,
Pedro.

2006/5/26, Arno <arno35 em gmail.com>:
> Olá pessoal,
>
> tenho acompanhado a lista a algum tempo e tenho percebido que esta é uma
> lista muito boa, talvez uma das melhores do país.
>
> Por isso, venho pedir uma ajuda sobre modelagem de banco de dados, peguei um
> sistema para dar manutenção, ele está rodando o Delphi 6 + zeoslib 5.5 +
> mysql 4.0.

Seu sistema é codificado em delphi 6 utilizando a biblioteca zeoslib
5.5  e acessando banco de dados mysql 4.

>
> Estou mudando todo o banco, tornando ele um banco relacional, porque da
> forma como se encontra hoje, ele não tem integridade de chave entre as
> tabelas.

Até onde eu sei o mysql tb é um banco de dados relacional. Vide
http://dev.mysql.com/doc/refman/4.1/pt/what-is.html . Talvez o que vc
pretenda seja normalizar o banco.

>
> Para isso estou utilizando o Delphi 6 + zeoslib 6.1 + firebird 1.53.

>

Fez uma boa opção.

> Mas o meu problema está no seguinte:
>
> Tem duas tabelas em uma parte semi-contábil do sistema, que controlam os
> títulos a pagar e a receber.
>
> Hoje, a cada novo título lançado no sistema, é feito automaticamente o
> número de lançamentos correspondentes a quantidade de parcelas, por exemplo:
> se um título tiver parcela única, será efetuado um único lançamento dentro
> do banco mas, se um título tiver duas ou mais parcelas, é feito o lançamento
> do mesmo título tantas vezes quanto forem o número de parcelas.
>
> Para efetuar a baixa, o sistema escreve em outra tabela, uma cópia do título
> digitado acima, e faz a baixa do mesmo, ou seja, ele está reescrevendo o
> registro do lançamento e anexando alguns campos, como data da baixa e
> outros...
>
> Basicamento o desenho das tabelas são estes:
>
> =====================================================
> tabela titulos
> id               -> chave primária
> idclifor      -> chave da tabela de clientes/fornecedores
> nrdoc        -> nr do documento
> datalanc  -> data do lançamento
> tipodoc     -> tipo do documento
> valor          -> valor da parcela
> valordoc   -> valor total do documento
> nrparcela -> número da parcela
> qparcela  -> quantidade de parcelas
>
> tabela de movimentação
> id                -> chave primária
> idclifor       -> chave da tabela de clientes/fornecedores
> nrdoc         -> número do documento
> databaixa  -> data da baixa do documento
> tipodoc      -> tipo do documento
> valor           -> valor da parcela
> nrparcela  -> número da parcela
> ========================================================
>
> Entre outros campos, estes são os principais.
>
> Bom, montei um modelo relacional no qual o título era lançado uma única vez
> dentro da tabela de títulos, não havendo mais a repetição de campos e
> registros, e de acordo com a quantidade de parcelas era feito o lançamento
> dentro da tabela de movimentação, aguardando assim a data da baixa com o
> respectivo número da parcela, deste modo o cliente pode escolher qual
> parcela pagar, como ainda é feito hoje. Ou seja, a tabela de movimentação
> ficou com uma chave estrangeira da tabela de títulos e sem os campos
> repetidos.
>

Alguns acreditam que ter redundância de campos pode trazer ganho de
performance. E não deixa de ser verdade, apesar de ferir as formas
normais, por evitar buscas cruzadas entre as tabelas que provocam uma
certa perda de tempo. Por outro lado o controle sobre os dados nesses
campos muitas vezes passa para a aplicação. Ou seja, mais trabalho
para o programador ou o para o DBA, que pode tentar ajudar manter as
coisas no lugar através de triggers ou SPs. Assim, pode-se tornar
inserções, edições e exclusões mais lentas pelo volume de restrições e
operações a serem realizadas antes ou durante o processo. Mas isso me
parece bastante relativo. Acho que o que se deve fazer é pesar o que
se quer em termos de performance em detrimento da simplificação da
codificação, pq além de tudo complica para manutenção futura.
Normalizar o banco é o ideal, mas nem sempre temos um oracle nas mãos.
Ainda é necessário um certo malabarismo para lidar com performance em
bancos como o firebird para baixo quando se trata de milhoões de
registros. Se bem que lidar com milhões de registros não é mole em
nenhum SGBD...

Enfim, o modelo transacional deve ser o mais enxuto possível para se
ter ganho de performance se o foco é o cadastro, modificação ou
exclusão de dados. É a hora de cuidar de integridade referencial,
normalização, etc... Se o foco está nas consultas em sistemas
informações gerenciais, vale a pena aplicar os conceitos de
datawarehouse, olap, enfim, business intelligence. Só que aí a
modelagem é outra e os mecanismos de coleta de dados também. É outra
história.

Acho que vale a pena tentar entender pq as coisas estão como estão...

> Na semana passada percebí um problema neste sistema que estou montando. Como
> a quantidade de parcelas determina o número de lançamentos dentro da tabela
> de movimentação, o sistema não comporta pagamento de parcelas parciais, ou
> seja, se uma parcela for de R$ 300,00 e for efetuado o pagamento de somente
> R$ 200,00, ficam sobrando R$ 100,00 que não tenho aonde colocá-lo. E isso é
> uma prática comum para este cliente.
>
> Bom, tenho que repensar estas duas tabelas novamente, e estou precisando de
> uma ajuda, se alguém tiver uma idéia ou sugestão de como resolver o problema
> e quiser compartilhá-lha, pode entrar em contato em pvt comigo.
> arno35 em gmail.com
>

Vale a pena passar o olho em Yourdon, Análise Estruturada Moderna.

> Agradeço a todos que perderam tempo lendo este jornal...
>

Que nada! Isso ajuda a praticar o que nos diferencia dos macacos.

> Arno.
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para editar sua configuração na lista, use o endereço
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>