Modelagem prevê CRIAR CAMPOS em tempo de execução?
25/09/2003
0
Existe alguma modelagem de dados que prevê a criação de CAMPOS em tempo de execução? Estou desenvolvendo um sistema GED (Gerenciamento Eletrônico de Documentos) onde estou sendo ´forçado´ a permitir ao usuário do software a CRIAÇÃO DE CAMPOS.
Como o software é Cliente/Servidor fico preocupado a respeito disso, pois a tabela principal do programa pode estar sendo usada por várias pessoas durante a alteração de sua estrutura e não sei como o INTERBASE poderia reagir. Evidentemente também não posso obrigar o usuário a alertar para toda a rede que a estrutura do programa está sendo alterada (ele nem sequer pode tomar conhecimento disso).
Muitos ´analistas de plantão´ me disseram para simplesmente criar duas tabelas (uma para armazenar o nome do CAMPOS e outra para armazenar o CONTEUDO de cada campo - o tipo do campo assim como o seu tamanho é sempre o mesmo).
Mas quando entrei no mérito de como apresentar isso para o usuário (como ele vai navegar, inserir, excluir ou alterar os dados da tabela CONTEUDO uma vez que cada registro exibe o conteudo de um CAMPO DIFERENTE) os analistas pularam fora... O que achei super natural pois eu teria que entrar no mérito do funcionamento do sistema para que pudessem entender melhor e assim opinar mais corretamente.
Então esse e-mail é dedicado para quem já fez ou vai desenvolver um sistema GED. Acredito que dessa forma haja um interesse maior na troca de idéias e sugestões (porém sem tomar muito tempo, pois isso é o que nós profissionais de informática menos temos).
Se alguém tiver interesse, estou a disposição.
Valeu pessoal, um abraço.
Ismael
Como o software é Cliente/Servidor fico preocupado a respeito disso, pois a tabela principal do programa pode estar sendo usada por várias pessoas durante a alteração de sua estrutura e não sei como o INTERBASE poderia reagir. Evidentemente também não posso obrigar o usuário a alertar para toda a rede que a estrutura do programa está sendo alterada (ele nem sequer pode tomar conhecimento disso).
Muitos ´analistas de plantão´ me disseram para simplesmente criar duas tabelas (uma para armazenar o nome do CAMPOS e outra para armazenar o CONTEUDO de cada campo - o tipo do campo assim como o seu tamanho é sempre o mesmo).
Mas quando entrei no mérito de como apresentar isso para o usuário (como ele vai navegar, inserir, excluir ou alterar os dados da tabela CONTEUDO uma vez que cada registro exibe o conteudo de um CAMPO DIFERENTE) os analistas pularam fora... O que achei super natural pois eu teria que entrar no mérito do funcionamento do sistema para que pudessem entender melhor e assim opinar mais corretamente.
Então esse e-mail é dedicado para quem já fez ou vai desenvolver um sistema GED. Acredito que dessa forma haja um interesse maior na troca de idéias e sugestões (porém sem tomar muito tempo, pois isso é o que nós profissionais de informática menos temos).
Se alguém tiver interesse, estou a disposição.
Valeu pessoal, um abraço.
Ismael
Ismael
Curtir tópico
+ 0
Responder
Posts
08/03/2004
Khundalini
Caro colega,
O que os analistas lhe responderam diz respeito à criação de um dicionário de dados ativo. O que quer dizer isso? Todo banco de dados que se preze possui um dicionário de dados, descrevendo todos os seus objetos pertencentes (tabelas, campos, regras de integridade, triggers, stored procedures, etc.). Um dicionário de dados ativo seria um dicionário especial, sendo usado como um adendo ao dicionário do próprio banco de dados. Ele tem essa designação de ativo pq ele pode ser a qualquer momento ser alterado para que o front end possa reconhecer novos objetos no banco de dados sem que a aplicação seja recompilada (NOTA: Para isso, a aplicação precisa ser projetada para esse propósito).
Muitos desenvolvedores da época do Clipper (como eu), ttinham essa prática de descrever os dados utilizados pelos (até então) arquivos de dados (.DBF) em arquivos .INI ou mesmo em arquivos .DBF. Em geral, a descrição básica de dicionário de dados ativo seria:
.NOME DA TABELA;
.NOME DO CAMPO;
.TIPO DO CAMPO;
.TAMANHO DO CAMPO;
.CASAS DECIMAIS (SE APLICÁVEL);
.MÁSCARA DE FORMATAÇÃO;
.RÓTULO PARA TELA;
.RÓTULO PARA RELATÓRIO
A implementação de um dicionário de dados ativo requer um planejamento prévio de implementação, principalmente se a aplicação for utilizada com mais de uma plataforma de banco de dados.
Espero ter elucidado (pelo menos, um pouco) sua questão. Qualquer coisa, mande-me um e-mail ou contacte-me via ICQ ou MSN.
[]s
Rubem Rocha
Manaus, AM
O que os analistas lhe responderam diz respeito à criação de um dicionário de dados ativo. O que quer dizer isso? Todo banco de dados que se preze possui um dicionário de dados, descrevendo todos os seus objetos pertencentes (tabelas, campos, regras de integridade, triggers, stored procedures, etc.). Um dicionário de dados ativo seria um dicionário especial, sendo usado como um adendo ao dicionário do próprio banco de dados. Ele tem essa designação de ativo pq ele pode ser a qualquer momento ser alterado para que o front end possa reconhecer novos objetos no banco de dados sem que a aplicação seja recompilada (NOTA: Para isso, a aplicação precisa ser projetada para esse propósito).
Muitos desenvolvedores da época do Clipper (como eu), ttinham essa prática de descrever os dados utilizados pelos (até então) arquivos de dados (.DBF) em arquivos .INI ou mesmo em arquivos .DBF. Em geral, a descrição básica de dicionário de dados ativo seria:
.NOME DA TABELA;
.NOME DO CAMPO;
.TIPO DO CAMPO;
.TAMANHO DO CAMPO;
.CASAS DECIMAIS (SE APLICÁVEL);
.MÁSCARA DE FORMATAÇÃO;
.RÓTULO PARA TELA;
.RÓTULO PARA RELATÓRIO
A implementação de um dicionário de dados ativo requer um planejamento prévio de implementação, principalmente se a aplicação for utilizada com mais de uma plataforma de banco de dados.
Espero ter elucidado (pelo menos, um pouco) sua questão. Qualquer coisa, mande-me um e-mail ou contacte-me via ICQ ou MSN.
[]s
Rubem Rocha
Manaus, AM
Responder
Clique aqui para fazer login e interagir na Comunidade :)