Blog – FAQ 2

Blog - FAQ 2Olá, leitores! Desde o FAQ 1, continuo recebendo mais algumas dúvidas por e-mail e novamente vou compartilhar as principais aqui no blog. Aproveito para agradecer a todos os leitores que acompanham o blog, divulgam os artigos e fornecem feedbacks com críticas e sugestões. Gostaria também de fazer um agradecimento especial ao meu amigo Sidney Santos, que vem acompanhando o blog há bastante tempo!
Bom, sem mais delongas, segue o FAQ 2!

 

Na empresa em que trabalho, há um software que permite a entrada de um mesmo número de documento fiscal em registro diferentes. Isso é correto? Gostaria do seu ponto de vista.
Já trabalhei com um sistema que emite documentos fiscais e em momento algum os números se repetiam. O número do documento fiscal era a chave primária da tabela, portanto, mesmo se houvesse alguma inconsistência no software o número não seria duplicado, já que o próprio banco de dados evitava a operação.
Ao ler a sua mensagem, achei estranho o fato de o sistema permitir que dois documentos tenham o mesmo número. Eu não tenho conhecimento da regra de negócio mas, como se trata de um documento fiscal, acredito que isso não possa ocorrer, ao menos que realmente haja uma lógica para essa situação.
De qualquer forma, eu entraria em contato com o suporte para reportar o problema e solicitar uma orientação (ou correção).

 

Li o seu artigo sobre Tabelas Temporárias e fiquei com uma dúvida: o registro mestre também é mantido na memória e gravado junto com os detalhes? Qual a forma mais correta de programar o relacionamento Master/Detail?
Em relacionamentos mestre/detalhe eu sempre recomendo a utilização de tabelas temporárias (ou tabelas virtuais, como muitos desenvoledores denominam).
Para exemplificar essa minha preferência, vou citar um cenário parecido com o seu caso: suponha que o usuário iniciou o cadastro de uma venda e, ao incluir os itens, os mesmos já são imediatamente gravados no banco de dados.
Porém, imagine que a energia do escritório acabe durante o cadastro de uma venda. Após a energia voltar, o usuário reabre a aplicação e começa a digitar a mesma venda. No entanto, o registro mestre (venda) e alguns itens da venda (detalhes) já foram gravados no banco de dados antes da energia cair. Resultado: estes registros ficarão “perdidos” no banco de dados, afetando o desempenho e provavelmente causando algum tipo de inconsistência, já que o usuário não saberá que a mesma venda já existe no banco de dados, mesmo que incompleta.
Este é o problema que a tabela temporária visa solucionar!
Uma tabela temporária é um DataSet que permanece na memória do computador por um tempo determinado. Logo, neste caso, criaríamos uma tabela temporária para os itens da venda, e este seria o procedimento:

1) Os itens são gravados na tabela temporária durante o cadastro da venda, ao invés de serem gravados no banco de dados;
2) Quando o usuário clicar em “Gravar”, a venda e os itens serão, de fato, gravados no banco de dados de uma vez só, em um único método.

Portanto, a resposta para a sua pergunta é: sim, o registro mestre é gravado junto com os detalhes.
Isso irá reduzir os erros na sua aplicação e aumentar a confiabilidade.

 

Estou iniciando um projeto de software para uma empresa que possui várias filiais. Neste caso, como ficaria o banco de dados? Um para cada cliente ou um banco único para todos os clientes?
Depende de como estes bancos de dados serão trabalhados.
Por exemplo, se você precisa integrar dados entre as filiais, como vendas, estoque, clientes ou outras informações, recomendo que utilize um único banco de dados para todo o sistema.
Por outro lado, se as filiais trabalharem independentemente, ou seja, cada uma manter seus próprios dados, é mais apropriado criar bancos de dados distintos, inclusive por contribuir com o desempenho da aplicação.
Há ainda outra modalidade conhecida como replicação. Esse recurso permite que os clientes utilizem bancos de dados diferentes e, periodicamente (uma vez por dia, por exemplo), estes dados são sincronizados em um único banco de dados chamado Base Mestre. Caso seja necessário consultar dados ou gerar relatórios gerenciais com estatísticas de diferentes filiais, basta consultar essa base.
Apesar de funcional, a implementação da replicação é relativamente complexa.

 

Qual a melhor opção para consultar e exibir dados para o usuário: Views ou Stored Procedures?
Eu geralmente analiso o tipo de conteúdo que será exibido, ou seja, se for um conjunto de dados oriundo de duas ou mais tabelas (joins) e o intuito é só exibí-los para o usuário de forma estática, recomendo utilizar Views. Por outro lado, se você precisa realizar algum processamento nos dados antes de exibí-los (como concatenações, formatações e cálculos), então eu sugiro que utilize Stored Procedures!

 

Há alguma forma de criptografar o conteúdo de um arquivo INI?
Infelizmente não há uma forma consistente de criptografar arquivos INI, ainda mais que, caso fosse possível, você teria alguns problemas para ler as seções e as chaves do arquivo pelo Delphi. Uma alternativa é usar uma função de criptografia para gravar os valores criptografados no arquivo INI, como, por exemplo, em vez de gravar “Delphi”, a função gravaria “5&R0@”. Ao ler a chave, basta aplicar a engenharia reversa da criptografia, resultando no valor original.

 

É possível enviar um e-mail pelo Outlook através do Delphi?
Sim, e é bem simples!
Primeiro declare a unit ComObj na uses do seu formulário:

uses
  ComObj;

 E no botão para enviar o e-mail, use este código:

var
  Outlook: OleVariant;
  vMailItem: variant;
const
  olMailItem = 0;
begin
  try
    Outlook := GetActiveOleObject('Outlook.Application');
  except
    Outlook := CreateOleObject('Outlook.Application');
  end;
  vMailItem := Outlook.CreateItem(olMailItem);
  vMailItem.Subject := 'Assunto do e-mail';
  vMailItem.Body := 'Corpo do e-mail';
  vMailItem.Attachments.Add('C:\Anexo.jpg');
  vMailItem.GetInspector.Activate;
  vMailItem.Display(True);
  VarClear(Outlook);
end;

 

Por hoje é só, leitores!
Até a próxima semana!


Confira também os outros FAQs:

FAQ 01 | FAQ 02 | FAQ 03 | FAQ 04 | FAQ 05 | FAQ 06 | FAQ 07 | FAQ 08 | FAQ 09


 

Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

8 comentários

  1. Oi André,
    Cara, hoje parei para ler suas publicações. Você está de parabéns maninho, não estou surpreso quanto sua desenvoltura, sempre soube de sua capacidade!

    Fica com Deus irmãozinho,
    Abraços!

    Ah.. Quando estiver por aqui da um sinal de vida maninho

    1. Fala, Ariel!
      Rapaz, é um prazer receber um elogio de uma pessoa que fiz uma grande amizade no trabalho.
      Obrigado pelo comentário e pela motivação, Ariel!

      Grande abraço!

  2. André, uma pergunta quase pessoal.
    Atualmente, como programador Delphi, voce usa Orientação Objetos para programar? Mas antes da OO, a escrita do codigo, era basicamente procedural. Qual a desvantagem de se programar proceduralmente no Delphi sem a OO?

    1. Olá, Benedito. Eu vou dar uma resposta bem particular. Na minha opinião, trabalhar com Orientação a Objetos fortalece a reutilização de código e garante um maior controle dos objetos e mensagens na aplicação. Em outras palavras, conceitos como abstração, classes, encapsulamento, herança, polimorfimos, interfaces, padrões de arquitetura e Design Patterns vão de encontro com o potencial da Engenharia de Software. Porém, não tiro o mérito da programação procedural no Delphi. Já encontrei vários softwares de ótima qualidade que foram desenvolvidos de forma procedural.

  3. Ola, André.

    Na pergunta sobre a duplicação do nº de documento fiscal, em algumas vezes pode acontecer, vou tentar explicar.
    quando o cliente emite notas modelo1(‘Mod1’) e passa para NF-e, a numeração é reiniciada, então acontece a repetição mas deve ter um identificador do tipo ‘Mod1’ , ‘NF-e’ ou ‘Cupom Fiscal’.
    Outro caso são as notas de entrada, a numeração repetida acontece mesmo, vários fornecedores com o mesmo nº e o mesmo fornecedor com nº duplicado, é necessário identificar o fornecedor e o tipo.
    Mas em nenhum caso pode duplicar mesmo nº e tipo, fornecedor no caso de entrada.
    Tenho um cliente que administra duas empresas com a mesma base de dados e clientes, começou com ‘Mod1’ para as duas, a numeração duplicou, então separadas pela origem em ‘A’ e ‘B’, agora NF-e quadruplicou a numeração, estas em ‘C’ e ‘D’, mas nunca mesmo nº e origem.
    Espero ter ajudado, encontramos situações que parecem impossíveis, mas temos que dar solução.

    1. Boa noite, Gerson!
      Não tinha conhecimento dessa situação. Obrigado por compartilhar!
      Neste caso, a modelagem do banco de dados deve ser bem estruturada para evitar inconsistências e, claro, reduzir a complexidade da regra de negócio para facilitar a manutenção. Mesmo assim, quando você mencionou que o número de origem não se repetia, a solução já ficou evidente: definir o número de origem como chave primária da tabela.

      Abraço!

  4. Bom dia, André.

    Complementando, usar como chame primária o nº da NF de venda é possível se o cliente só emite um tipo de nota. Por exemplo, clientes novos só vão emitir NF-e sem problemas, mas se ele emitia a ‘Mod1’ e agora a ‘NF-e’, dá pra usar se for em tabelas diferentes ou, não sei se é possível, criar uma chave primaria composta, tipo (num_nf+modelo). Nunca tentei, facilitaria a validação, pois o uso de tabelas separadas causa dificuldades, sendo necessário dois cadastros (telas, relatórios, estatísticas,…). Seria obrigatório fazer duas consultas para ter um relatório completo, tipo vendas de um determinado item, produtos que um cliente comprou.
    No caso das notas de entrada só se é possível chave primaria composta. Recortei uma imagem de uma consulta em uma base real, venda e compra. Vou mandar.
    Mas tem um detalhe (usando as funções e estruturas que eu conheço), regras de negócio, modelagem de dados e outras eu posso até estar usando, mas estudei isso ainda, já vi que você postou sobre isso chego lá.
    Gostaria de um artigo sobre Views, acho que eu poderia usar isso.

    Abraço.

    1. Boa noite, Gerson!
      Tem razão. Clientes antigos, que emitiam notas do tipo “Mod1”, e agora emitem Notas Fiscais Eletrônicas, exigem um tratamento especial no armazenamento de dados. Também acredito que duas tabelas nunca será a melhor alternativa, pois, como você disse, dificultaria não só a manutenção, como também a praticabilidade do software.
      Assim que possível, colocarei um tópico de Views na pauta do blog! Abraço!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.