Meilleures pratiques pour le schéma de base de données avec la génération de requêtes DDL et SQL

L'action de script Exécuter une requête SQL en langage naturel et la fonction GetTableDDL génèrent un DDL (Data Definition Language) qui résume le schéma de base de données des occurrences de table spécifiées. La logique sous-jacente repose sur les paramètres de rubrique et le graphique des relations pour la majeure partie du schéma de la base de données, mais peut également inclure les commentaires de rubrique que vous saisissez dans la boîte de dialogue Gérer la base de données comme informations supplémentaires.

Lorsque le schéma de base de données est envoyé à un modèle d'IA pour générer des requêtes SQL, respecter ces meilleures pratiques permet d'améliorer la capacité du modèle à générer des instructions SQL utiles.

Utiliser des noms de table et de rubrique alphanumériques

Il est préférable que les noms de rubriques soient conformes à la norme SQL-92. En général, utilisez des caractères alphanumériques ; n'utilisez pas de caractères spéciaux, à l'exception du trait de soulignement (_). Essayez d'éviter les espaces, même si ils sont pris en charge (FileMaker peut gérer les noms de tables et de rubriques contenant des espaces tout en communiquant avec un modèle d'IA).

Utiliser les rubriques de clé primaire et de clé étrangère

Les rubriques de clé primaire et de clé étrangère dans une relation doivent être associées au même type de données : numéro, texte ou même date ou horodatage, si nécessaire.

Rubrique Clé primaire

Toute rubrique avec une valeur unique peut être utilisée comme rubrique de clé primaire. Cependant, la meilleure pratique consiste à utiliser les mêmes critères que ceux utilisés par FileMaker pour détecter automatiquement une rubrique de clé primaire.

Pour pouvoir être détectée, une rubrique de clé primaire doit être la rubrique CléPrimaire par défaut (ou une copie de celle-ci) ou répondre à l'un des critères suivant :

• utiliser un numéro de série à saisie automatique, et avoir les options suivantes sélectionnées :

  • pour la saisie automatique, Entrées auto. non modifiables lors de la saisie ;

  • pour la validation, Valeur unique.

• utiliser un calcul saisi automatiquement qui inclut la fonction Obtenir ( UUID ) ou Obtenir ( UUIDnombre ) et avoir l'option de saisie automatique Entrées auto. non modifiables lors de la saisie sélectionnée.

• être une rubrique de calcul stockée qui inclut la fonction Obtenir ( UUID ) ou Obtenir ( UUIDnombre ).

• utiliser un numéro de série à saisie automatique.

Consultez les sections Définition de l'entrée automatique de données, Définition de la validation des rubriques et Définition des options d'indexation des rubriques.

Rubrique Clé étrangère

Une rubrique de clé étrangère peut avoir le même nom que la rubrique de clé primaire correspondant dans une table liée, mais cela n'est pas obligatoire. Par exemple, une rubrique de clé étrangère nommée ce_Contacts dans la table Adresses représente une relation entre la table Contacts et la table Adresses. La meilleure pratique consiste à utiliser un nom qui a du sens pour vous, car ce sera également un nom utile pour le modèle d'IA.

Pour rendre le rôle de la rubrique plus clair et spécifier la relation avec une autre table, vous pouvez décrire la rubrique plus en détail dans les commentaires (voir ci-dessous). Par exemple, ajoutez ce qui suit en tant que commentaire dans la rubrique Addresses::ce_Contacts : "[LLM] Clé étrangère pour une relation un-à-plusieurs avec la table Contacts."

Remarque  Une clé étrangère et sa relation avec une table liée ne sont incluses dans le DDL que si les deux occurrences de table dans la relation sont spécifiées.

Ajouter des commentaires de rubrique

Les commentaires que vous saisissez dans la boîte de dialogue Gérer la base de données sont inclus dans le DDL. Pour améliorer la capacité du modèle à générer des instructions SQL utiles basées sur le DDL, vous pouvez utiliser le commentaire pour expliquer le rôle de la rubrique. Par exemple, lorsqu'une rubrique est une clé étrangère qui identifie un enregistrement dans une table liée, ou lorsque le nom de la rubrique n'est pas aisément compréhensible. Pour une rubrique de clé primaire, même si FileMaker la détecte et indique dans le DDL qu'il s'agit d'une clé primaire, il est toujours judicieux de l'identifier comme tel dans le commentaire.

Consultez la section Définition et modification de rubriques.

Ajouter la balise [LLM] pour limiter les rubriques incluses

Plutôt que d'inclure toutes les rubriques d'une table dans le DDL, vous pouvez spécifier uniquement celles qui sont importantes, ce qui réduit les informations superflues envoyées au modèle, susceptibles de dégrader la qualité de la réponse. Pour ce faire, ajoutez la balise spéciale [LLM] au début du commentaire, puis rédigez un commentaire descriptif si nécessaire. Toutes les autres rubriques de la table dont le commentaire ne commence pas par la balise [LLM] sont exclues du DDL.

Par exemple, si la table Produits inclut ces rubriques, mais que le commentaire dans la rubrique Etat ne commence pas par la balise [LLM] :

Le DDL pour cette table est alors :

CREATE TABLE "Produits" (
"IDProduit" int, /*Clé primaire qui identifie un produit de manière unique*/
"NomProduit" varchar(255), /*Nom descriptif du produit*/
"Prix" int, /*Prix du produit en USD*/
PRIMARY KEY (IDProduit)
);

Notez que seules les trois rubriques avec la balise [LLM] sont incluses, et la balise [LLM] elle-même est omise.

Distinguer les rubriques avec le même nom dans plusieurs tables

Parfois, une base de données peut avoir des rubriques portant le même nom dans plusieurs tables. Par exemple, une rubrique Photo de la table Contacts stocke l'image des clients, tandis qu'une autre rubrique Photo de la table Commandes stocke l'image des reçus de commande. Pour vous assurer qu'un modèle d'IA peut distinguer les rôles de ces rubriques, ajoutez des commentaires descriptifs. Par exemple, ajoutez « [LLM] Photo du client » au commentaire de la rubrique Contacts::Photo et « [LLM] Photo des reçus de commande » au commentaire de la rubrique Commandes::Photo.

Déterminer quand la casse est importante

Les requêtes SQL sont sensibles à la casse, de sorte que les résultats peuvent différer selon que le texte est en majuscules ou en minuscules. Par exemple, une rubrique Balises dans la table Produits stocke les balises de chaque produit, selon leur nom propre. Dans ce cas, pour éviter des résultats de requête inattendus, ajoutez « [LLM] Balises du produit, en nom propre » comme commentaire pour la rubrique Products::Balises.

Fournir les valeurs de rubrique valides

Pour les rubriques qui utilisent des listes de valeurs personnalisées pour spécifier des valeurs valides, une bonne pratique consiste à fournir les valeurs valides dans un commentaire, afin que le modèle d'IA puisse générer la meilleure requête SQL. Par exemple, ajoutez « [LLM] Titre du poste, les valeurs valides sont Chirurgien, Médecin, Dentiste, Infirmière et Pharmacien » comme commentaire pour la rubrique Contacts::Titre.

Ne pas interroger les rubriques Statistique

La valeur d'une rubrique Statistique dans une base de données FileMaker dépend des enregistrements du jeu trouvé actuel, de sorte qu'une requête SQL peut renvoyer un résultat incorrect dans certains cas. Utilisez plutôt la balise [LLM] dans les commentaires de rubrique, afin que les rubriques Statistique soient exclues. SQL est suffisamment sophistiqué pour effectuer les tâches des rubriques Statistique sans les inclure dans le DDL.

Rubriques connexes 

• Action de script Exécuter une requête SQL en langage naturel

• Fonction GetTableDDL

• Définition et modification de rubriques