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 os comentários 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 um comentário no campo Addresses::fk_Contacts: "[LLM] Chave estrangeira para relacionamento de um para muitos com a tabela Contatos."

Nota Uma chave estrangeira e seu relacionamento com uma tabela relacionada são incluídos no DDL somente se ambas as ocorrências de tabela no relacionamento forem especificadas.

Adicionar comentários de campo

Os comentários de campo inseridos na caixa de diálogo Gerenciar banco de dados estão incluídos no DDL. Para melhorar a capacidade do modelo de gerar instruções SQL úteis com base no DDL, você pode usar o comentário para explicar o propósito do campo. Por exemplo, quando um campo é uma chave estrangeira que identifica um registro na 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 o detecte e indique no DDL que se trata de uma chave primária, ainda é uma boa ideia identificá-la como tal no comentário do campo.

Consulte Definição e alteração de campos.

Adicionar a tag [LLM] para limitar os campos incluídos

Em vez de incluir todos os campos de uma tabela no 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 a tag especial [LLM] ao início do comentário do campo e, em seguida, siga com um comentário descritivo, conforme necessário. Quaisquer outros campos na tabela cujo comentário não comece com a tag [LLM] serão excluídos do DDL.

Por exemplo, se a tabela Produtos incluir esses campos, mas o comentário no campo Status não começar com a tag [LLM]:

Nome do campo	Comentário
ProductID	[LLM] Chave primária que identifica exclusivamente um produto
ProductName	[LLM] Nome descritivo do produto
Preço	[LLM] Preço do produto em USD
Status	Status do produto em estoque. Os valores são Em estoque, Sob encomenda

Então, o DDL para esta tabela será:

Copiar

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 a tag [LLM] serão incluídos e que a própria tag [LLM] será omitida.

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 comentários de campo para esclarecer. Por exemplo, adicione "[LLM] Foto do cliente" ao comentário do campo "Contacts::Photo" e "[LLM] Foto dos recibos de pedidos" ao comentário do campo Orders::Photo.

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 "[LLM] Tags do produto, em capitalização de título" como comentário para o campo Products::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 um comentário de campo para que o modelo de IA possa gerar a melhor consulta SQL. Por exemplo, adicione "[LLM] Cargo, os valores válidos são Cirurgião, Médico, Dentista, Enfermeiro e Farmacêutico" como comentário 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, use a tag [LLM] nos comentários do campo para que os campos de resumo sejam excluídos. O SQL é sofisticado o suficiente para executar as tarefas dos campos de resumo sem incluí-las no DDL.