Importar SQL
Descrição
Seção intitulada “Descrição”Importa o resultado de uma consulta SQL em um banco de dados externo para uma tabela de projeto do PlaidCloud. A consulta é executada no banco de dados remoto; apenas o conjunto de resultados é trazido para o PlaidCloud.
Difere de Importar tabelas de banco de dados externo porque você mesmo escreve o SQL — útil para junções, filtros ou agregações complexas que você quer que o banco de dados de origem execute antes de os dados chegarem ao PlaidCloud.
Parâmetros de importação
Seção intitulada “Parâmetros de importação”
Origem e destino
Seção intitulada “Origem e destino”Conexão de banco de dados
Seção intitulada “Conexão de banco de dados”Para estabelecer uma Conexão de banco de dados, consulte Conexões de dados do PlaidCloud
Tabela de destino
A seleção de destino para importações é limitada a tabelas, pois as visões não contêm dados subjacentes.
Opção dinâmica
A opção dinâmica permite especificar uma tabela por meio de texto, incluindo variáveis. Isso é útil ao usar fluxos de trabalho orientados por variáveis, nos quais as referências a tabelas e visões são relativas às variáveis especificadas.
Um exemplo que usa a variável current_month para apontar dinamicamente para a tabela de destino:
legal_entity/inputs/{current_month}/ledger_valuesOpção estática
Quando você quiser uma tabela específica como destino da importação, deixe a caixa Dinâmico desmarcada e selecione a tabela de destino.
Se a tabela de destino não existir, selecione o botão Criar novo para criar a tabela no local desejado.
O Explorador de tabelas está sempre disponível em qualquer seleção de tabela. Clique no botão Explorador de tabelas à direita da seleção de tabela e uma janela do Explorador de tabelas será aberta.
Consulta SQL
Seção intitulada “Consulta SQL”Nesta seção, escreva a consulta SQL que retorna os dados necessários.
Detecção do tipo de coluna
Seção intitulada “Detecção do tipo de coluna”As importações de SQL têm a opção de tentar detectar o tipo de dados durante o carregamento ou de definir todas as colunas com o tipo Texto. Definir os tipos de dados dinamicamente pode ser mais rápido se os dados estiverem limpos, mas pode causar problemas em algumas circunstâncias.
Por exemplo, se a maior parte dos dados parece numérica, mas há também algum texto, a detecção pode tentar definir a coluna como numérica, causando problemas de carregamento por incompatibilidade de tipos de dados. Ou pode haver problemas se houver, por exemplo, um código de produto numérico de 16 dígitos. Os zeros à esquerda seriam cortados, resultando em um número em vez de um código de 16 dígitos.
Definir os dados como texto, porém, exige uma etapa Extract posterior para converter para o tipo apropriado, como datas ou valores numéricos, os dados que não deveriam ser texto.
Solução de problemas
Seção intitulada “Solução de problemas”| Sintoma | Causa provável |
|---|---|
| A etapa levou visivelmente mais tempo do que o normal — até cerca de meia hora a mais — sem que nada mais tenha mudado na sua consulta, conexão ou volume de dados | O worker em segundo plano que executava a importação foi interrompido no meio do processo (uma reinicialização ou remoção do lado da plataforma, e não algo no seu fluxo de trabalho), e a plataforma tentou novamente a importação da tabela para você. A nova tentativa só começa quando a interrupção é detectada, o que explica o tempo extra. |
| A etapa ainda terminou com sucesso após esse atraso | A nova tentativa substitui integralmente o conteúdo da tabela, então o resultado é o mesmo de uma única execução limpa — não há nada mais a verificar ou refazer. |
| A etapa falha com “has already been attempted and cannot be safely re-run” | Em uma etapa Importar SQL, essa recusa não acontece mais — uma interrupção no meio da execução é repetida. Você ainda a verá, por design, ao restaurar um arquivo de projeto ou carregar uma dimensão, em que uma nova execução criaria uma duplicata em vez de substituir algo. Abra um chamado de suporte se você a vir em uma própria etapa Importar SQL. |