MANUTENCAO DE DADOS
Como vocês estruturam os dados DB para a seguinte situação:
Tabela funcionários
Campos: ID - Matricula - Nome - etc...
Nota: ID - Chave Primaria
Tabela Vendas
Campos: ID - Vendedor - Data - etc...
Nota: ID - Chave Primaria e número do pedido
O campo vendedor seria um dos funcionários da empresa. Bem nesse campo vocês guardariam o ID ou o Nome do Funcionário?
Pergunto isso pois no meu sistema não existe exclusão de registros em nenhuma tabela, pois o histórico de tudo é guardado. Então criei em cada tabela um campo INATIVO (0 ou 1)
Quando um funcionário ou qualquer item do banco (Departamentos, Cargos, etc..) não for mais usado, ele é alterado para INATIVO.
Ai surgiu um problema. Na tela (cadastro-Consulta-Edição) dos módulos eu populo as Combos (DBCombo sem uso de Datas, tudo via código) com a relação de itens (funcionário, Departamentos, Cargos, etc...) respectivamente, somente com os itens ATIVOS. Então se eu fizer uma consulta a itens antigos do módulo, onde hajam funcionário ou departamentos, etc já INATIVOS, ao jogas os dados do registro nos campos, a combo não exibirá esse dado, pois não existe um funcionário carregado (lista ATIVOS).
Como os colegas tratam essa situação.
Nota: Nas tabelas dos módulos eu gravo somente o Ãndice das demais tabelas, assim evitando redudà ¢ncia de informações no banco e agilizando as pesquisas pelos respectivos Ãndices e não por nomes.
Tabela funcionários
Campos: ID - Matricula - Nome - etc...
Nota: ID - Chave Primaria
Tabela Vendas
Campos: ID - Vendedor - Data - etc...
Nota: ID - Chave Primaria e número do pedido
O campo vendedor seria um dos funcionários da empresa. Bem nesse campo vocês guardariam o ID ou o Nome do Funcionário?
Pergunto isso pois no meu sistema não existe exclusão de registros em nenhuma tabela, pois o histórico de tudo é guardado. Então criei em cada tabela um campo INATIVO (0 ou 1)
Quando um funcionário ou qualquer item do banco (Departamentos, Cargos, etc..) não for mais usado, ele é alterado para INATIVO.
Ai surgiu um problema. Na tela (cadastro-Consulta-Edição) dos módulos eu populo as Combos (DBCombo sem uso de Datas, tudo via código) com a relação de itens (funcionário, Departamentos, Cargos, etc...) respectivamente, somente com os itens ATIVOS. Então se eu fizer uma consulta a itens antigos do módulo, onde hajam funcionário ou departamentos, etc já INATIVOS, ao jogas os dados do registro nos campos, a combo não exibirá esse dado, pois não existe um funcionário carregado (lista ATIVOS).
Como os colegas tratam essa situação.
Nota: Nas tabelas dos módulos eu gravo somente o Ãndice das demais tabelas, assim evitando redudà ¢ncia de informações no banco e agilizando as pesquisas pelos respectivos Ãndices e não por nomes.
cara eh o seguinte... qto ao campo vendedor.. tem dois lados... se vc usar ID para gravar vendas... estaria sujeito a ter IDÂÂÂ's excluidas..e provalvelmente um erro a ser tratado depois... se usar nome... estará sujeito a pessoas com nomes iguais e/ou a alterações de nomes...
o ideal... mescle os dois dados.. tipo 001-Alisson
-----------------------------------------------------------
essa é uma idéia.. q precisa ser mais trabalhado pelo pessoal ae... hehehe
o ideal... mescle os dois dados.. tipo 001-Alisson
-----------------------------------------------------------
essa é uma idéia.. q precisa ser mais trabalhado pelo pessoal ae... hehehe
Mas se gravar no Nome na tabela de lançamentos estarei duplicando informações sempre e assim para que o relacionamento entre tabelas?
Isso seria o mesmo que para Endereços, se eu gravo o ID da tab Endereços evito duplicar informações, mas se gravar em cada registro o Endereço do cliente, por exemplo, teria centenas, milhares de registros com a mesma informação Endereço.
Pelo que aprendi, o propósito de bancos relacionais era exatamente evitar a redundà ¢ncia de informações e é sobre isso que estou com dúvidas, não propriamente sobre a utilização de chaves duplas para identificação de um registro, pois nesse caso do exemplo o melhor seria combinar ID e Matricula e não o Nome do funcionário.
Mas minha pergunta é sobre manutenção dos dados, Se tenho a tab Funcionário, que poderia ser Departamentos ou Cargos ou qualquer outra onde a informação seja repetida em vários registros, se não se usa a exclusão de registros para evitar perda de informações anterior, então uso um campo INATIVO para desativar o registro não mais usado. Então como uso o ID desse dado para pesquisa, como exibiria o mesmo se ele foi colocado como inativo? Veja mais detalhes na pergunta inicial.
Isso seria o mesmo que para Endereços, se eu gravo o ID da tab Endereços evito duplicar informações, mas se gravar em cada registro o Endereço do cliente, por exemplo, teria centenas, milhares de registros com a mesma informação Endereço.
Pelo que aprendi, o propósito de bancos relacionais era exatamente evitar a redundà ¢ncia de informações e é sobre isso que estou com dúvidas, não propriamente sobre a utilização de chaves duplas para identificação de um registro, pois nesse caso do exemplo o melhor seria combinar ID e Matricula e não o Nome do funcionário.
Mas minha pergunta é sobre manutenção dos dados, Se tenho a tab Funcionário, que poderia ser Departamentos ou Cargos ou qualquer outra onde a informação seja repetida em vários registros, se não se usa a exclusão de registros para evitar perda de informações anterior, então uso um campo INATIVO para desativar o registro não mais usado. Então como uso o ID desse dado para pesquisa, como exibiria o mesmo se ele foi colocado como inativo? Veja mais detalhes na pergunta inicial.
bem...
vamos pensar de forma diferente... com uma exclusão, daria um erro caso vc tivesse um vendedor linkado... agora... com inativo, isso não acontece - o que deixaria seu bd inconsistente, concorda?
vamos pensar de forma diferente... com uma exclusão, daria um erro caso vc tivesse um vendedor linkado... agora... com inativo, isso não acontece - o que deixaria seu bd inconsistente, concorda?
Jean acho que não, pois o fato de estar inativo apesar impede do nome ou da lista de itens que usar o recurso, exibir os registros INATIVOS, no caso minha DBCombo. Assim ao cadastrar um novo lançamento não seria exibido para isso.
Agora ao fazer uma consulta, como tenho o ID no lançamento eu carrego o dado mesmo que esteja inativo e assim não há inconsistência.
Porém o problema nesse caso é se por algum motivo quiser Editar esse mesmo lançamento, então eu teria um problema já que ao jogar os dados nos campos do formulário (pegos e exibidos em um MSFlexGrid) o ID do Vendedor geraria um erro dentro de DBCombo que não teria esse registro lá, pois como disse o DBCombo só tem os registros Ativos.
Uma solução que pensei foi ter 2 DBCombos carregados em cada form, um com os Registros ATIVOS e outro com Todos os Registros. Assim se estiver consultando exibiria o completo e se for Incluir ou Editar exibiria o com registros ATIVOS.
O problema disso é que teria de fazer 2 consultas a base para cada combo no form e manter 1 recordset desconectados para cada combo também, o que aumentaria o consumo de memória e acesso ao banco, além de tráfego na rede, apesar de teoricamente a maior parte dessas tabelas não ter mais que algumas desenas de registro, salvo funcionários.
Assim estou querendo saber como os colegas tratam essa situação, para ver se há outra saÃda.
Agora ao fazer uma consulta, como tenho o ID no lançamento eu carrego o dado mesmo que esteja inativo e assim não há inconsistência.
Porém o problema nesse caso é se por algum motivo quiser Editar esse mesmo lançamento, então eu teria um problema já que ao jogar os dados nos campos do formulário (pegos e exibidos em um MSFlexGrid) o ID do Vendedor geraria um erro dentro de DBCombo que não teria esse registro lá, pois como disse o DBCombo só tem os registros Ativos.
Uma solução que pensei foi ter 2 DBCombos carregados em cada form, um com os Registros ATIVOS e outro com Todos os Registros. Assim se estiver consultando exibiria o completo e se for Incluir ou Editar exibiria o com registros ATIVOS.
O problema disso é que teria de fazer 2 consultas a base para cada combo no form e manter 1 recordset desconectados para cada combo também, o que aumentaria o consumo de memória e acesso ao banco, além de tráfego na rede, apesar de teoricamente a maior parte dessas tabelas não ter mais que algumas desenas de registro, salvo funcionários.
Assim estou querendo saber como os colegas tratam essa situação, para ver se há outra saÃda.
Bom eu particularmente faria o seguinte
1-carregaria o id, pois mesmo vc alterando os dados o id estaria amarrado a venda, portanto se vc quiser depois mostrar o nome do fulano é so montar uma SQL JOIN.
2-qnto ao cadastro estar inativo vc pode fazer um procedimetno da seguinte forma ao carregar ou consultar o recordset é carregado SELEC * FROM Usuarios e qndo vc for incluir ou alterar carregue o recordset dessa forma
SELECT * FROM Usuarios WHERE (((Albuns.Titulo)='ATIVO')) ou se o campo for tipo boelan pode definir yes/no e vc pode usar os dois recordset desconectados.
outra coisa andei fazendo alguns testes aqui tanto com dao, ado usando bases access e firebird e posso dizer o seguinte a primeira conexao com o banco é um pouco mais demorado as demais se tornam mais rapidas e mesmo assim acredito q mesmo q a sua rede esteja trabalhando emcima de um cabo categoria 3 de 10MBS ou um Wirelles de 30K eu acho q não ira passar de alguns milesimos de segundo
1-carregaria o id, pois mesmo vc alterando os dados o id estaria amarrado a venda, portanto se vc quiser depois mostrar o nome do fulano é so montar uma SQL JOIN.
2-qnto ao cadastro estar inativo vc pode fazer um procedimetno da seguinte forma ao carregar ou consultar o recordset é carregado SELEC * FROM Usuarios e qndo vc for incluir ou alterar carregue o recordset dessa forma
SELECT * FROM Usuarios WHERE (((Albuns.Titulo)='ATIVO')) ou se o campo for tipo boelan pode definir yes/no e vc pode usar os dois recordset desconectados.
outra coisa andei fazendo alguns testes aqui tanto com dao, ado usando bases access e firebird e posso dizer o seguinte a primeira conexao com o banco é um pouco mais demorado as demais se tornam mais rapidas e mesmo assim acredito q mesmo q a sua rede esteja trabalhando emcima de um cabo categoria 3 de 10MBS ou um Wirelles de 30K eu acho q não ira passar de alguns milesimos de segundo
Ok Weber, acho que terei mesmo de usar 2 DBCombo, um para ATIVOS e outro para Todos os Registros.
Isso porque não há como fazer uma nova consulta, já que todos os dados estão disponÃveis no form assim:
Form:
Campos dom todos os itens do lançamento e DBCombos com os registros ATIVOS respectivos
FlexGrid
Os lançamentos selecionados, onde ao clicar na linha do grid os campos acima são preenchidos, mas o DBCombo recebe o ID do registro (funcionario, cargo ou outro qualquer) pela propriedade .TextBound e assim atualiza o .Text com o valor correto, se ele estiver carregado. Assim teria mesmo de usar, se não há outra técnica, um dBcombo completo que receberia o ID do registro, ao selecinar Edição eu passaria o ID para o segundo DBCombo que se não exibisse o registro, então exibiria uma mensagem ao usuário informando o ocorrorido, assim perguntaria se deseja manter o ID original ou alterar para outro.
Isso porque não há como fazer uma nova consulta, já que todos os dados estão disponÃveis no form assim:
Form:
Campos dom todos os itens do lançamento e DBCombos com os registros ATIVOS respectivos
FlexGrid
Os lançamentos selecionados, onde ao clicar na linha do grid os campos acima são preenchidos, mas o DBCombo recebe o ID do registro (funcionario, cargo ou outro qualquer) pela propriedade .TextBound e assim atualiza o .Text com o valor correto, se ele estiver carregado. Assim teria mesmo de usar, se não há outra técnica, um dBcombo completo que receberia o ID do registro, ao selecinar Edição eu passaria o ID para o segundo DBCombo que se não exibisse o registro, então exibiria uma mensagem ao usuário informando o ocorrorido, assim perguntaria se deseja manter o ID original ou alterar para outro.
Tópico encerrado , respostas não são mais permitidas