GARANTIR DESCONTO

Fórum Dúvida Firebird #58902

25/09/2007

0

Estou [b:1bd17344ab]implementando um novo projeto[/b:1bd17344ab] onde quero adotar o uso de [b:1bd17344ab]´Surrogate Key´[/b:1bd17344ab], que nada mais eh do que ter um [b:1bd17344ab]campo ´ID´[/b:1bd17344ab] que identifica uma ´tupla´ ou ´registro´ (como queiram chamar a dita cuja!!!), então começei a montar o meu projeto e me deparei com um problema que tentarei demonstrar com um exemplo:

Digamos que temos no nosso sistema a [b:1bd17344ab]estrutura da nossa base[/b:1bd17344ab] de dados desta forma:

(Tabela: [b:1bd17344ab]UNIDADES_FEDERACAO[/b:1bd17344ab])
============================
ID ([b:1bd17344ab]PK_UNIDADES_FEDERACAO[/b:1bd17344ab]),
DESCRICAO ([b:1bd17344ab]UK_UNIDADES_FEDERACAO[/b:1bd17344ab]),
SIGLA ([b:1bd17344ab]UK_UNIDADES_FEDERACAO[/b:1bd17344ab])

(Tabela: [b:1bd17344ab]CIDADES[/b:1bd17344ab])
=================
ID ([b:1bd17344ab]PK_CIDADES[/b:1bd17344ab]),
DESCRICAO ([b:1bd17344ab]UK_CIDADES[/b:1bd17344ab]),
ID_UNIDADE_FEDERACAO ([b:1bd17344ab]UK_CIDADES[/b:1bd17344ab] e [b:1bd17344ab]´FK_UNIDADES_FEDERACAO´[/b:1bd17344ab])

Tentando resumir a minha explicação a [b:1bd17344ab]base está montada corretamente com triggers, generators e foreign keys[/b:1bd17344ab]...

No [b:1bd17344ab]firebird[/b:1bd17344ab] blza funciona mas...o meu grande problema eh como implementar essa idéia no [b:1bd17344ab]DELPHI[/b:1bd17344ab], sendo que, não gostaria de utilizar o conceito de campos [b:1bd17344ab]lookup[/b:1bd17344ab] pois isso iria debilitar a performance da minha aplicação, visto que iria utilizar isso tanto para pequenas tabelas, não só como neste caso, mas como para grandes tabelas como:
PEDIDOS <--> PRODUTOS,
PEDIDOS <--> CLIENTES...e assim por diante.

E principalmente pensando no produto final, digamos que naum usaremos [b:1bd17344ab]combobox em nenhum caso. Somente seria utilizado DBEdits[/b:1bd17344ab], o usuário iria abrir o cadastro de cidades clicar no botão novo e digitar a descrição do produto (´CAXIAS DO SUL´) passando para o próximo campo e [b:1bd17344ab]´DIGITAR A SIGLA´[/b:1bd17344ab] (´RS´) da unidade de federação assim iria aparecer no label ao lado do campo ´RIO GRANDE DO SUL´. Mas ae vem a grande dúvida:

COMO FAÇO PARA RELACIONAR ESSA INFORMAÇÃO AO ´ID´ da tabela a sigla?

SIGLA <--> ID_UNIDADES_FEDERACAO

Alguém poderia me dar uma dica!!! Quero ver umas idéias do pessoal depois retorno com mais explicações e dúvidas....

Estou mto confuso com isso e gostaria de uma ajuda do pessoal do fórum para criar essa ´ótima idéia´ na minha ´base de dados´ ou ´base de conhecimento´ (falando bonito hein??? hahaha...).

obrigado pessoal.


Edvilson.chaves

Edvilson.chaves

Responder

Posts

25/09/2007

Gandalf.nho

Uma sugestão, que é a que uso em meus projetos, é usar views como origem das suas telas de manutenção, assim trará os dados relacionados sem problemas. Para tornar a view atualizável, basta criar triggers para cada um dos eventos Before dela. Funciona perfeitamente


Responder

Gostei + 0

25/09/2007

Edvilson.chaves

Perae...se entendi bem você quer dizer que eu teria que utilizar views para que ele mostre as infomações corretas. CERTO até ae concordo que funcionaria perfeitamente mas, o que quero realmente eh que se o usuário naum selecione a pesquisa e sim informe manualmente a sigla do estado no campo, e o sistema irá gravar o ID correspondente da sigla da unidade de federação na tabela de cidades. tela mais ou menos assim:

---------------------------------------------------------------------------
Cadastro de Cidades
---------------------------------------------------------------------------
Descricao: [b:e60d1b5cfa][CAXIAS DO SUL ][/b:e60d1b5cfa]
Unidade de Federação: [b:e60d1b5cfa][RS][/b:e60d1b5cfa] [color=blue:e60d1b5cfa]RIO GRANDE DO SUL[/color:e60d1b5cfa]
---------------------------------------------------------------------------

qdo infomado a sigla RS no campo (ID_UNIDADE_FEDERACAO), ele iria buscar qual o ID correspondente. Mas como fazê-lo se o Field do campo se refere a ID_UNIDADE_FEDERACAO e naum ao campo SIGLA da tabela UNIDADE_FEDERACAO.

Ainda busco informações pela melhor prática de implementação.

obrigado pela ajuda pessoal.


Responder

Gostei + 0

25/09/2007

Raserafim

gandalf, gostaria de entender melhor como e por quais motivos vc utiliza as view.
usar views como origem das suas telas de manutenção



Responder

Gostei + 0

25/09/2007

Edvilson.chaves

Olá a todos, pensei em desenvolver um frame. Este frame teria as seguintes propriedades:
- [b:f1912e4bba]Field[/b:f1912e4bba] --> Que seria o campo a ser populado. No nosso caso o campo ID_UNIDADE_FEDERACAO.
- [b:f1912e4bba]FieldIn[/b:f1912e4bba] --> Que seria o campo a ser informado. No nosso caso o campo SIGLA. Podendo esse quem sabe daqui a algum tempo ser varios campos. Ex: Cadastro de Produto tem Codigo;Cod_Barra;Referencia. Ele faria a busca até encontrar a informação.
- [b:f1912e4bba]FieldOut[/b:f1912e4bba] --> Que seria o campo a ser apresentado no label ao lado do botão de pesquisa.
- [b:f1912e4bba]DataSourcePesquisa[/b:f1912e4bba] --> Que seria o ponteiro para onde a pesquisa será realizada e aonde os campos de FieldIn e FieldOut será referenciado e deverão existir.

+---------------------------------------------------------------------+
| Caption do Campo: [XXXXXX] [PPP] X-----------------------X |
+---------------------------------------------------------------------+

Com isso acho que inúmeras implementações seriam desnecessárias, encapsulando algumas ações...E essa seria mais ou menos a cara do nosso frame. Que acham da idéia? Quero uma ajuda....


Responder

Gostei + 0

25/09/2007

Edvilson.chaves

Aliás....pensando bem, todos os campos poderiam ser frames, encapsulando todas as entradas e saídas de informação da aplicação. Isso iria fazer com que qualquer conversão ou mudança de plataforma ou opções fossem fácilmente implementadas. Por exemplo um combox com opções entre outros estariam encapsulados permitindo a mundança com uma alteração simples em um componente...

luz vem surgindo...


Responder

Gostei + 0

25/09/2007

Gandalf.nho

No meu caso, para evitar o uso de lookupcombo, eu criei uma função que é chamada pelo evento OnKeyDown dos DBEdit cuja origem é proveniente de outra tabela que não a principal da view.
Essa função recebe alguns parâmetros como o campo a ser atualizado na tabela principal, uma lista de campos secundários que são os dependentes (aqueles cujos valores são obtidos da outra tabela) e uma consulta SELECT simples com pelo menos todos os campos envolvidos na operação (cuja origem é a outra tabela). Essa função chama um formulário padrão com um LookupList que é alimentado pela query. Daí o usuário seleciona o valor desejado que é retornado para o formulário de manutenção. Os valores obtidos são usados para atualizar os campos.
Essa técnica me permite simular um lookupcombo sem precisar tê-lo aberto o tempo todo (eu só oabro quando preciso mexer no valor do campo).

Mas também é possível fazer como você disse (digitar direto no campo). Nesse caso você tem que pegar o valor recebido e usá-lo como parâmetro de pesquisa na tabela desejada para retornar o campo código e usá-lo para atualizar o campo desejado na tabela principal.


Responder

Gostei + 0

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar