Esquema de conexão dos terminais INTOOLS: solução eficiente

Este post é uma série. Assim que o trabalho for concluído e publicado, poderá ser compartilhado com todos

O SPI é realmente incrível. Passando pelo EXCEL. . .

Falando de qualquer forma, a ideia é boa, mas a confiabilidade costuma apresentar problemas. Quando comecei, também pensei em inserir dados no Orical por meio de escrita externa, mas percebi que o risco era muito alto e que era fácil surgirem problemas. Como se trata de uma operação feita manualmente e imprevisível, é possível que os dados importados não estejam em conformidade com as regras do banco de dados. Por exemplo, podem haver espaços adicionados antes ou depois dos dados, além de outras operações estranhas que podem ocorrer. Como os dados são importados (geralmente usando o Excel), não há como garantir que eles estejam formatados corretamente. Isso pode causar danos ao banco de dados. Além disso, quando esse tipo de problema acontece, é difícil detectá-lo. Você só perceberá erros ao tentar usar a função de conexão do SPI; porém, não conseguirá identificar exatamente onde está o erro. Portanto, para softwares tão especializados e fechados, não é recomendado usar métodos de escrita externa. Você pode usar os dados existentes no banco de dados, mas não é aconselhável inserir novos dados nele.

Olá, obrigado pela mensagem. Nesta fase, após testes, não há nenhum problema em gravar dados no banco de dados por meio de SQL. O ponto chave é entender a estrutura do banco de dados INTOOLS, identificar as relações entre os diferentes parâmetros e como os dados se interconectam.

O desenvolvimento pode ser dividido em 5 fases: 1. Analisar a estrutura do banco de dados e selecionar as tabelas necessárias. 2. Analisar as tabelas do banco de dados selecionadas, identificar as informações dos vários parâmetros, definir o formato dos parâmetros nas instruções SQL e determinar as informações necessárias para acessar as tabelas do banco de dados. 3. Estabelecer regras para a designação de identificadores, cabos e sistemas de controle central, em conformidade com as normas da indústria. 4. Os regulamentos estabelecidos serão integrados ao programa, e, de acordo com o formato das instruções SQL definidas na segunda fase, serão geradas instruções SQL que podem ser escritas diretamente no banco de dados.

Primeiramente, é necessário explicar o método tradicional de desenho com CAD. Esse método é fácil de aprender, mas exige a criação manual de uma estrutura, além da inserção manual de diversas informações, o que torna a eficiência baixa. Mas, em projetos de grande porte, com milhares de números de identificação, isso costuma exigir muitas horas de trabalho humano, o que não é suficiente para atender às necessidades de produção.

Na primeira fase, realiza-se a análise da estrutura do banco de dados. Após usar frequentemente o INTOOLS, torna-se mais fácil se familiarizar com a estrutura do banco de dados; não há necessidade de maiores explicações sobre isso. Além disso, isso também envolve questões de confidencialidade, esperamos que seja compreendido. Na segunda fase, após definir a estrutura do banco de dados INTOOLS, é necessário estabelecer o formato de cada instrução específica. Por exemplo, para gravar informações sobre um cabo, uma caixa de conexões, um terminal, etc., são necessárias instruções específicas para isso. Após as instruções serem definidas nesta fase, na quarta fase elas serão processadas em lote.

Na terceira fase, o foco é estabelecer, com base nas normas do setor, as diversas regras que devem ser seguidas, incluindo as regras relativas aos cabos, às caixas de conexão, ao sistema de controle central, entre outras. A quarta fase é o processo de integração das segundas e terceiras fases, com a elaboração de procedimentos adequados, conforme necessário.

As condições de entrada do software exigem um total de cinco informações: número da posição, tipo de IO, caixa de conexão inicial, caixa de conexão intermediária e terminal de controle. Após preencher essas informações, é possível gerar, por meio do software, instruções SQL prontas para serem executadas

A imagem anexa contém instruções SQL geradas em lote, salvas no formato EXCEL. Para utilizá-las, basta copiar e colar as instruções SQL no cliente e executá-las. O tempo necessário para executar as instruções SQL de um projeto com 3000 registros é de aproximadamente 5 minutos. O tempo real para que o software gere as instruções SQL é de aproximadamente 30 segundos.

De acordo com sua descrição, deve ser um erro no tipo de dado gravado; os valores correspondentes devem ter uma relação de chamada. Por exemplo, o armazenamento do tipo IO no banco de dados é feito através dos dados da tabela IO_TYPE; na tabela component, basta inserir apenas o ID correspondente. No entanto, se você inserir diretamente o tipo IO no banco de dados, ele gerará um erro. Cada módulo do INTOOLS é igual, e sua chamada é bastante complexa.

Após concluir a gravação, é possível fazer login no INTOOLS para visualizar o que foi gravado; em caso de problemas, é possível fazer ajustes manualmente. Após concluir a gravação do módulo de conexão, o cabo também é gravado, e o registro do cabo pode ser extraído diretamente do INTOOLS.

Em… Você provavelmente não entendeu o que quero dizer. Não sei se o que você escreveu será usado apenas por você ou por toda a equipe. Se você está criando um software que deve ser utilizado por todos, então, quando ele estiver em uso, você vai entender o que quero dizer. Os usuários não têm a menor ideia de como funciona o seu programa. Eles só sabem que, ao inserir dados nele, esses dados serão enviados para o INTOOLS. A correção dos dados não é algo que eles levam em consideração. Por exemplo, se uma coluna no banco de dados deve conter valores numéricos, mas o usuário insere texto nela, haverá erros ao tentar salvar os dados no banco de dados. Isso é algo fácil de identificar. Muitas pessoas usam a função de copiar e colar no Excel; às vezes, elas até colam caracteres invisíveis. Por exemplo, pode parecer que não há nada, mas na verdade há um espaço após os dados. Ou seja, parece ser apenas um espaço, mas na verdade é um símbolo oculto de quem sabe o que é. Esse tipo de problema é muito comum. Não se trata de uma funcionalidade que não funcione, mas sim do fato de que o programa é muito difícil de usar para os usuários. Isso acaba causando instabilidade nos dados do projeto inteiro. É isso que quero dizer.

Entendi então: o nível de competência dentro do departamento é desigual, e realmente existe esse problema. Mas o meu software precisa apenas de informações simples; durante o uso, basta copiar e colar novamente os dados originais, mantendo apenas as informações necessárias. Há apenas um item importante; o restante, com espaços ou não, não é afetado

Admiro muito esse tipo de desenvolvimento secundário em softwares, pois realmente melhora a eficiência no trabalho.

No processo de design real, é recomendável que os engenheiros responsáveis tenham habilidades básicas para escrever consultas SQL, além de terem um certo conhecimento sobre a estrutura do banco de dados.