Melhores práticas para esquema de banco de dados na geração de consultas DDL e SQL
A Etapa de script Executar Consulta SQL por Linguagem Naturale a função Função GetTableDDLgeram linguagem de definição de dados (DDL) que resume o esquema de banco de dados das ocorrências de tabela especificadas. A lógica subjacente depende das configurações de campo e do gráfico de relações para a maior parte do esquema de banco de dados, mas também pode incluir as anotações de campo que você insere na caixa de diálogo Gerenciar banco de dados como informações adicionais.
Quando o esquema de banco de dados é enviado para um modelo de IA para gerar consultas SQL, seguir essas melhores práticas ajuda a melhorar a capacidade do modelo de gerar instruções SQL úteis.
Usar tabelas alfanuméricas e nomes de campos
É melhor que os nomes dos campos estejam em conformidade com o padrão SQL-92. Em geral, use caracteres alfanuméricos; não use caracteres especiais, exceto sublinhado (_). Tente evitar o uso de espaços, mas você pode usá-los, se necessário (o FileMaker lida corretamente com nomes de tabelas e campos contendo espaços enquanto se comunica com um modelo de IA).
Usar campos de chave primária e de chave estrangeira
Os campos de chave primária e de chave estrangeira em um relacionamento precisam ter o mesmo tipo de dados (número, texto ou até mesmo data ou carimbo de data/hora), se houver um motivo para fazê-lo.
Campo de chave primária
Qualquer campo com um valor exclusivo pode ser usado como um campo de chave primária. No entanto, a melhor prática é usar os mesmos critérios que o FileMaker usa para detectar automaticamente um campo de chave primária.
Para ser detectado, um campo de chave primária deve ser o campo PrimaryKey padrão (ou uma cópia dele) ou atender a um dos seguintes critérios:
-
usar um número de série de entrada automática com as seguintes opções selecionadas:
-
para entrada automática, Proibir modificação de valor durante a entrada de dados
-
para validação, Valor exclusivo
-
-
o campo usa um cálculo de entrada automática que inclui a função Get(UUID) ou Get(UUIDNumber), e a opção de entrada automática Proibir modificação de valor durante a entrada de dados está selecionada
-
o campo é um campo de cálculo armazenado que inclui a função Get(UUID) ou Get(UUIDNumber)
-
usar um número de série de inserção automática
Consulte Definição da entrada de dados automática, Definição de validação do campo e Definição das opções de indexação de campo.
Campo de chave estrangeira
Um campo de chave estrangeira pode ter o mesmo nome que o campo de chave primária correspondente em uma tabela relacionada, mas isso não é obrigatório. Por exemplo, um campo de chave estrangeira chamado fk_Contacts na tabela Endereços representa um relacionamento da tabela Contatos com a tabela Endereços. A melhor prática é usar um nome que faça sentido para você, porque também será um nome útil para um modelo de IA.
Para tornar o propósito do campo mais claro e especificar o relacionamento com outra tabela, você pode descrever o campo mais adiante nos comentários do campo (veja abaixo). Por exemplo, adicione o seguinte como uma anotação no campo Addresses::fk_Contacts: "Chave estrangeira para relação um-para-muitos com a tabela Contatos."
Nota Uma chave estrangeira e seu relacionamento com uma tabela relacionada são incluídos na DDL somente se ambas as ocorrências de tabela no relacionamento forem especificadas.
Adicionar anotações de campo
As anotações de campo inseridas na caixa de diálogo Gerenciar banco de dados estão incluídas na DDL. Para melhorar a capacidade do modelo de gerar instruções SQL úteis com base na DDL, você pode usar uma anotação para explicar o propósito do campo — por exemplo, quando um campo é uma chave estrangeira que identifica um registro em uma tabela relacionada ou quando o nome do campo pode não ser comumente compreendido. Para um campo de chave primária, mesmo que o FileMaker a detecte e indique na DDL que se trata de uma chave primária, ainda é uma boa ideia identificá-la como tal na anotação do campo.
Para obter mais informações sobre como adicionar anotações de campo, consulte Definição de opções avançadas de campo.
Especifique anotações de campo para limitar os campos incluídos
Em vez de incluir todos os campos de uma tabela na DDL, você pode especificar apenas os campos que importam, reduzindo as informações desnecessárias enviadas ao modelo que podem prejudicar a qualidade da resposta. Para fazer isso, adicione anotações aos campos que você deseja incluir. Depois de adicionar pelo menos uma anotação de campo em uma tabela, apenas os campos com anotações são incluídos na DDL; os campos sem anotações são excluídos.
Por exemplo, se a tabela Produtos incluir esses campos, mas o campo Status não tiver uma anotação:
| Nome do campo | Anotação |
|---|---|
|
ProductID |
Chave primária que identifica exclusivamente um produto |
|
ProductName |
Nome descritivo do produto |
|
Preço |
Preço do produto em USD |
|
Status |
(sem anotação) |
Então, a DDL para esta tabela será:
CRIAR TABELA "Produtos" (
"ProductID" int, /*Chave primária que identifica exclusivamente um produto*/
"ProductName" varchar(255), /*Nome descritivo do produto*/
"Preço" int, /*Preço do produto em USD*/
CHAVE PRIMÁRIA (ProductID)
);
Observe que apenas os três campos com anotações estão incluídos.
Diferenciar campos com o mesmo nome em várias tabelas
Às vezes, um banco de dados pode ter campos com o mesmo nome em várias tabelas. Por exemplo, um campo Foto na tabela Contatos armazena a imagem dos clientes, enquanto outro campo Foto na tabela Pedidos armazena a imagem dos recibos de pedidos. Para ajudar a garantir que um modelo de IA possa diferenciar os diferentes propósitos desses campos, adicione anotações de campo para esclarecer. Por exemplo, adicione "Foto do cliente" como anotação para o campo Contatos::Foto e "Foto dos recibos de pedidos" como a anotação para o campo Pedidos::Foto.
Especificar quando o caso é importante
As consultas SQL diferenciam maiúsculas e minúsculas; portanto, os resultados podem diferir dependendo se o texto está escrito em maiúsculas ou minúsculas. Por exemplo, um campo Tags na tabela Produtos armazena as tags de cada produto, todas em capitalização de título. Nesse caso, para evitar resultados inesperados de consulta, adicione "Tags do produto, em capitalização de título" como anotação para o campo Produtos::Tags.
Fornecer valores de campo válidos
Para campos que usam listas de valores personalizadas para especificar valores de campo válidos, uma prática recomendada é fornecer os valores válidos em uma anotação de campo para que o modelo de IA possa gerar a melhor consulta SQL. Por exemplo, adicione "Cargo, os valores válidos são Cirurgião, Médico, Dentista, Enfermeiro e Farmacêutico" como anotação de campo para o campo Contacts::Title.
Não consultar campos de resumo
O valor de um campo de resumo em um banco de dados do FileMaker depende dos registros no conjunto encontrado atual; portanto, uma consulta SQL pode retornar um resultado incorreto em alguns casos. Em vez disso, omita as anotações para campos de resumo para que eles sejam excluídos da DDL. O SQL é sofisticado o suficiente para executar as tarefas dos campos de resumo sem incluí-las na DDL.
Notas
Para manter a compatibilidade com apps personalizados que usam comentários de campo em vez de anotações de campo:
-
Se nenhuma anotação de campo for especificada em uma tabela, todos os campos nessa tabela serão incluídos na DDL. Comentários de campo, se presentes, são incluídos como descrições na DDL.
-
Se uma anotação de campo estiver em branco e o comentário de campo começar com a tag especial
[LLM], o texto do comentário (sem a tag[LLM]) será usado na DDL como se fosse uma anotação.