[firebase-br] modelo de dados auto relacionamento ou hierarquivo

[Gladiston Santana]

Você pode manter o modelo anterior usado no Piradox e prosseguir com a
atualização do seu banco de dados PDOX->FB.
Essa é minha primeira opção, não julgo ninguém, as necessidades de muitos
superam a necessidades de poucos.
Contudo, se você vai realmente mudar seu programa de qualquer forma e não
fará diferença mudar o método atual, então talvez devesse pensar em algo
mais simples,  tal como "999.999.999" num campo varchar simples.
Vejo assim na maioria dos programas quase sempre com 3 niveis.

Já vi alguns programas de c.resultado/plano de contas permitirem no ato da
criação definir 3-3-3(999.999.999), 3-2-3(999.99.999), etc... mas apenas no
inicio enquanto ainda não foi populado, afinal apenas os numeros são
armazenados, os pontos são apenas mascaras usadas na digitação de dados ou
exibidos na saida no caso de relatórios.
Se mudar para este novo método, deve impedir fortemente a digitação de
plano de contas no formato diferente do que foi definido no inicio senão
você terá uma dor de cabeça enorme depois.
Além disso, não poderá mais mudar o plano quando tiver iniciado os
lançamentos.

Os selects podem usar a clausula starting/similar para lidar com o
mascaramento.


[]´s e sucesso.


Em qua, 7 de ago de 2019 às 14:48, Gustavo Novaes <gutonovaes19 em gmail.com>
escreveu:

> Boa tarde.
>
> Tenho um modelo de dados , atualmente, com chaves compostas, semelhante à
> um plano de contas e que funciona em um banco paradox. (estou migrando para
> FB).
>
> TABELA NIVEL1 - CODIGO (8), NOME(30) -------(código, aqui é "gerado" pelo
> usuário, ele escolhe. Algumas empresas usam siglas)
> TABELA NIVEL2 - CODNIVEL1(A,8-FK), CODIGO(A,8), NOME(30).
> TABELA NIVEL3 - CODNIVEL1(A,8-FK), CODNIVEL2(A,8-FK), NIVEL3 (A,8),
> NOME(A,30).
>
> Embora soubesse não ser adequado, ou muito inadequado e perigoso, pretendia
> manter esse modelo na migração da aplicação para o FB por razões diversas.
> Porém, eu já vinha recebendo alertas de colegas que poderia resultar em um
> banco mais pesado, ter problemas de performance, etc. Após do FDD 16 e com
> a explicação da seletividade , dentre outras informações, achei melhor
> modificar esse modelo.
> Não tenho certeza se um modelo auto-relacionamento seria mais adequado ou
> se mantenho 3 tabelas relacionadas entre si, referenciando a ancestral
> através de sua ID.
>
> Exemplo:
>
> Auto-relacionamento
>
> TABELA NIVEL - ID(INTEGER, NOME(CHAR,30), CODIGO_DO_USUARIO(CHAR,8 -
> UNIQUE), idAncestral(Integer, permite NULL)
>
>
> Modelo aninhado
>
> TABELA NIVEL1 - ID (integer), NOME (CHAR,30) , CODIGO_DO_USUÁRIO(CHAR,8 -
> UNIQUE);
>
> TABELA NIVEL2 - ID(integer) NOME (CHAR,30), CODIGO_DO_USUARIO9CHAR,8) -
> UNIQUE), idNivel1(integer-FK pra tabela nivel1);
>
> TABELA NIVEL3 - ID(integer) NOME (CHAR,30), CODIGO_DO_USUARIO9CHAR,8) -
> UNIQUE), idNivel2(integer-FK pra tabela nivel2);
>
>
> Essas tabelas são chaves-estrangeiras para outras do banco de dados.
> Atualmente ocupam 48 caracteres (2 bytes por caracter? é isso?)
> Pesquisando da web vi modelos de dados onde, na chave primaria, foi
> utilizado (char,10). Mas, se eu fosse aplicar na minha "necessidade", não
> teria como garantir a exclusividade da PK, certo?
>
> Por fim, vi um artigo que sugere usar uma classe do delphi chamada TGui
> para gerar códigos exclusivos.
>
> Grato pela ajuda. Abraços.
>
>
>
> *Gustavo Novaes *
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas:
> http://www.firebase.com.br/pesquisa_lista.html
>


-- 
A Vidy possui um Sistema de Gestão da Qualidade estruturado e com
Certificação ISO 9001 há mais de 10 anos, mantendo seu foco na Qualidade e
na Melhoria Continua.

Em março de2018 migramos com sucesso para a nova versão da ISO 9001.

Somos a única Empresa Brasileira de Engenharia de Laboratórios com
certificação com o Escopo Completo; desde Projetos, Engenharia, Construção,
Fabricação e Instalação de Laboratórios.