> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Fontes de dados > Como PostgreSQL, MySQL, Oracle, SQL Server e MongoDB diferem dentro do Fetcher — namespaces de esquema, correspondência de nomes, inferência de tipos, pools e tempos limite. O Fetcher lê de cinco motores de banco de dados. A requisição do job é a mesma para todos eles. O que muda é como cada motor nomeia suas tabelas, como o Fetcher descobre um esquema e como os valores voltam. Esta página cobre essas diferenças. Escolha o seu motor e leia a seção dele. ## O que todo motor compartilha *** Defina o motor pelo `type` da conexão, em maiúsculas: `POSTGRESQL`, `MYSQL`, `ORACLE`, `SQL_SERVER`, `MONGODB`. A validação da requisição compara exatamente essas cinco cadeias, então qualquer outra capitalização falha com `400`. Estes limites são os mesmos em todos os motores: | Limite | Valor | | ------------------------------------- | ------------ | | Tempo limite de conexão | 5 segundos | | Tempo limite de descoberta de esquema | 30 segundos | | Tempo limite de consulta, sem filtros | 60 segundos | | Tempo limite de consulta, com filtros | 120 segundos | Os quatro motores relacionais compartilham um mesmo perfil de pool de conexões: 25 conexões abertas, 10 conexões ociosas, tempo de vida de conexão de 5 minutos e tempo limite de ociosidade de 1 minuto. O MongoDB usa um pool de no máximo 100 e no mínimo 10, com o mesmo tempo limite de ociosidade de 1 minuto. A projeção de campos também funciona da mesma forma. Uma lista de nomes de campos seleciona esses campos. A entrada única `["*"]` seleciona todos eles. ## PostgreSQL *** **Esquemas.** O PostgreSQL é o motor multiesquema mais completo no Fetcher. A descoberta lê o `information_schema` para os esquemas que o seu job nomeia, e recorre a `public` quando o job não nomeia nenhum. **Nomes de tabelas.** Uma tabela fora de `public` volta qualificada pelo esquema, como `accounting.invoices`. Uma tabela dentro de `public` volta sem qualificação, como `users`. Escreva o nome da mesma forma em `mappedFields`. **Chaves de filtro.** Uma chave de filtro resolve em três formas: o nome exato, o nome sem o prefixo de esquema e o nome com `public` acrescentado. `transactions` e `public.transactions` portanto chegam à mesma tabela. **Colunas JSON.** O driver retorna colunas `JSON` e `JSONB` como bytes brutos. O Fetcher tenta ler cada valor como objeto JSON, depois como array JSON, depois como string JSON. O valor convertido entra no resultado. Um valor que não casa com nenhum dos três permanece bruto, e o Fetcher registra um aviso em log. ## MySQL *** **Sem lista de esquemas.** O MySQL é o único motor relacional sem dimensão de esquema no Fetcher. O banco de dados conectado é o namespace. A descoberta lê o `information_schema` em busca de tabelas, colunas e chaves primárias desse banco. **Nomes de tabelas.** Escreva os nomes de tabelas sem qualificação. Um prefixo de esquema não tem contra o que resolver. **Chaves de filtro.** Uma chave de filtro precisa casar com o nome da tabela exatamente como você o escreveu em `mappedFields`. **Colunas JSON.** O Fetcher aplica aos valores em bytes a mesma leitura JSON em três passos que aplica no PostgreSQL: objeto, depois array, depois string. ## Oracle *** **Owners, não esquemas.** O Oracle chama o namespace de owner, e o Fetcher trata o owner como o esquema. Quando o seu job nomeia owners, a descoberta lê `all_tables`, `all_tab_columns` e `all_cons_columns` restritos a esses owners. Quando não nomeia nenhum, a descoberta recorre a `user_tables` e `user_cons_columns`, que cobrem apenas o usuário conectado. **O owner padrão** é o usuário com que a conexão se autentica. **Nomes de tabelas.** Uma tabela cujo owner é o usuário conectado volta sem qualificação. Qualquer outra tabela volta qualificada pelo owner, como `OWNER.TABLE`. O Fetcher compara nomes de owner sem diferenciar maiúsculas e minúsculas, e converte o owner para maiúsculas antes de consultar o catálogo do Oracle. O Fetcher também converte para maiúsculas os nomes de tabelas e de colunas no esquema que ele reporta de volta, e as linhas extraídas usam esses nomes de colunas em maiúsculas como chaves. Você pode escrever um job em maiúsculas ou em minúsculas, porque o Fetcher converte os nomes da sua requisição da mesma forma. Leia os resultados pela chave em maiúsculas. **Chaves de filtro.** O Oracle faz a correspondência exata da chave de filtro. Não há fallback de prefixo. **Colunas JSON.** Valores em bytes passam pela mesma leitura JSON em três passos. ## SQL Server *** **Esquemas.** O SQL Server é multiesquema, com `dbo` como padrão. A descoberta lê o `information_schema.tables` para os esquemas que o seu job nomeia, e se restringe a `dbo` quando o job não nomeia nenhum. **Nomes de tabelas.** Uma tabela fora de `dbo` volta qualificada pelo esquema, como `accounting.invoices`. Uma tabela dentro de `dbo` volta sem qualificação. É a mesma regra que o PostgreSQL aplica a `public`. **Chaves de filtro.** O SQL Server resolve uma chave de filtro nas mesmas três formas do PostgreSQL, com `dbo` como prefixo padrão. **Colunas JSON.** Valores em bytes passam pela mesma leitura JSON em três passos. ## MongoDB *** **Coleções, não tabelas.** O MongoDB não tem namespace de esquema. Escreva os nomes de coleção sem qualificação. Uma chave de filtro precisa casar exatamente com o nome da coleção. **Esquema inferido.** Documentos não carregam esquema declarado, então o Fetcher monta um em duas passagens sobre cada coleção: 1. Um pipeline de agregação reúne o conjunto completo de nomes de campos. 2. Uma amostra de até 50 documentos infere o tipo de cada campo. Um campo que a amostra nunca vê fica com o tipo `unknown`. **Amostragem.** A passagem de nomes de campos se adapta ao tamanho da coleção. Até 10.000 documentos, ela agrega sobre no máximo 1.000 documentos. Acima de 10.000 documentos, ela passa a usar um estágio `$sample`, com um tamanho que mira 95% de confiança e 5% de margem de erro: | Documentos na coleção | Tamanho da amostra | | --------------------- | ------------------ | | Até 1.000 | todos eles | | 1.001 a 10.000 | 1.000 | | 10.001 a 100.000 | 2.000 | | 100.001 a 1.000.000 | 5.000 | | Acima de 1.000.000 | 10.000 | Um esquema inferido é, portanto, uma amostra forte, não uma garantia. Um campo que existe em um punhado de documentos de uma coleção muito grande pode passar despercebido. Se a agregação falhar em uma coleção, o Fetcher registra um aviso em log e recorre à amostragem em vez de falhar a descoberta. **Filtros.** O MongoDB aceita os mesmos dez operadores, traduzidos para operadores de consulta. Um padrão de `like` vira uma expressão regular insensível a maiúsculas e minúsculas. O MongoDB também é o único motor que não executa a verificação de UUID em nomes de campos que parecem identificadores. Veja [Filtros](/pt/fetcher/fetcher-filters). **Opções de conexão.** Uma fonte de dados interna passa opções de driver como `authSource` e `directConnection` por meio de `DATASOURCE_{NAME}_OPTIONS`. ## Próximos passos *** Como um job nomeia fontes de dados, tabelas, esquemas e campos. Os dez operadores de filtro e o formato de valor que cada um aceita.