Prácticas recomendadas para el esquema de base de datos en la generación de consultas DDL y SQL

El paso de guión Ejecuta una consulta SQL mediante lenguaje natural y la función GetTableDDL generan lenguaje de definición de datos (DDL) que resume el esquema de base de datos de las ocurrencias de las tablas especificadas. La lógica subyacente se basa en la configuración de campo y el gráfico de relaciones para la mayor parte del esquema de la base de datos, pero también puede incluir las anotaciones de campo que introduzca en el cuadro de diálogo Administrar base de datos como información adicional.

Cuando el esquema de la base de datos se envía a un modelo de IA para generar consultas SQL, seguir estas prácticas recomendadas ayuda a mejorar la capacidad del modelo para generar secuencias SQL útiles.

Utilizar tablas alfanuméricas y nombres de campo

Lo mejor es que los nombres de los campos cumplan con el estándar SQL-92. En general, use caracteres alfanuméricos; no use caracteres especiales, excepto el guión bajo (_). Trate de evitar el uso de espacios, pero puede hacerlo si es necesario (FileMaker gestiona correctamente los nombres de tablas y campos que contienen espacios mientras se comunica con un modelo de IA).

Utilizar los campos de clave principal y de clave externa

Los campos de clave principal y clave externa en una relación deben tener el mismo tipo de datos: número, texto o incluso fecha o marca de tiempo, si hay una razón para hacerlo.

Campo de clave principal

Cualquier campo con un valor único se puede utilizar como campo de clave principal. Sin embargo, la práctica recomendada es utilizar los mismos criterios que utiliza FileMaker para detectar automáticamente un campo de clave principal.

Para que pueda detectarse, un campo de clave principal debe ser el campo de clave principal predeterminado (o una copia del mismo) o cumplir con uno de los siguientes criterios:

  • utiliza un número de serie de introducción automática y se han seleccionado las siguientes opciones:

    • Para la introducción automática, Prohibir la modificación del valor durante la introducción de datos.

    • Para la validación, Valor único.

  • utiliza un cálculo de introducción automática que incluye la función Get ( UUID ) o Get ( UUIDNumber ), y se ha seleccionado la opción Prohibir la modificación del valor durante la introducción de datos.

  • es un campo de cálculo almacenado que incluye la función Get ( UUID ) o Get ( UUIDNumber ).

  • utiliza un número de serie de introducción automática

Consulte Definir la entrada de datos automática, Definir validaciones de campoy Definir opciones de indexación de campos.

Campo de clave externa

Un campo de clave externa puede tener el mismo nombre que el campo de clave principal correspondiente en una tabla relacionada, pero no es necesario. Por ejemplo, un campo de clave externa llamado fk_Contactos en la tabla Direcciones representa una relación entre la tabla Contactos y la tabla Direcciones. La práctica recomendada es usar un nombre que tenga sentido para usted, porque también será un nombre útil para el modelo de IA.

Para aclarar el propósito del campo y especificar la relación con otra tabla, puede describir el campo con más detalle en una anotación de campo (ver más abajo). Por ejemplo, agregue lo siguiente como anotación en el campo Direcciones::fk_Contactos: "Clave externa para la relación de uno a muchos con la tabla Contactos".

Nota  Una clave externa y su relación con una tabla relacionada se incluyen en el DDL solo si se especifican ambas ocurrencias de la tabla en la relación.

Añadir anotaciones de campo

Las anotaciones de campo que introduzca en el cuadro de diálogo Administrar base de datos se incluyen en el DDL. Para mejorar la capacidad del modelo para generar declaraciones SQL útiles basadas en el DDL, puede usar una anotación para explicar el propósito del campo. Por ejemplo, cuando un campo es una clave externa que identifica un registro en una tabla relacionada, o cuando el nombre del campo puede no ser fácilmente comprensible. Cuando se trata de un campo de clave principal, incluso si FileMaker lo detecta e indica en el DDL que es una clave principal, sigue siendo una buena idea identificarlo como tal en la anotación de campo.

Para obtener más información sobre cómo añadir anotaciones de campo, consulte Definir opciones de campo avanzadas.

Especifique las anotaciones de campo para limitar los campos incluidos

En lugar de incluir todos los campos de una tabla en el DDL, puede especificar solo los campos que importan para reducir la información innecesaria enviada al modelo que puede degradar la calidad de la respuesta. Para hacerlo, añada anotaciones de campo a los campos que quiera incluir. Después de añadir al menos una anotación de campo en una tabla, solo se incluyen en el DDL los campos con anotaciones; los campos sin anotaciones se excluyen.

Por ejemplo, si la tabla Productos incluye estos campos, pero el campo Estado no tiene una anotación:

Nombre de campo Anotación

ProductID

Clave principal que identifica de forma única un producto

ProductName

Nombre descriptivo del producto

Precio

Precio del producto en USD

S.M.A.R.T.

(sin anotación)

Entonces el DDL para esta tabla es:

Copiar 
CREATE TABLE "Productos" (
"ProductID" int, /*Clave principal que identifica de forma única un producto*/
"ProductName" varchar(255), /*Nombre descriptivo del producto*/
"Price" int, /*Nombre descriptivo del producto en USD*/
PRIMARY KEY (ProductID)
);

Observe que solo se incluyen los tres campos con anotaciones.

Distinguir campos con el mismo nombre en varias tablas

A veces, una base de datos puede tener campos con el mismo nombre en varias tablas. Por ejemplo, un campo Foto de la tabla Contactos almacena la imagen de los clientes, mientras que otro campo Foto de la tabla Pedidos almacena la imagen de los recibos de pedido. Para ayudar a garantizar que un modelo de IA pueda distinguir los diferentes propósitos de estos campos, añada anotaciones de campo para aclararlo. Por ejemplo, añada "Foto del cliente" como anotación para el campo Contactos::Foto y "Foto de los recibos de los pedidos" como anotación para el campo Pedidos::Foto.

Especificar cuándo es importante el caso

Las consultas SQL distinguen entre mayúsculas y minúsculas, por lo que los resultados pueden diferir dependiendo de si el texto está en mayúsculas o minúsculas. Por ejemplo, un campo Etiquetas en la tabla Productos almacena las etiquetas de cada producto, todas en formato de título. En este caso, para evitar resultados de consulta inesperados, agregue "Etiquetas de producto, en formato de título" como anotación para el campo Productos::Etiquetas.

Proporcionar los valores de campo válidos

En los campos que utilizan listas de valores personalizadas para especificar valores de campo válidos, una práctica recomendada es proporcionar los valores válidos en una anotación de campo para que el modelo de IA pueda generar la mejor consulta SQL. Por ejemplo, agregue "Puesto, los valores válidos son Cirujano, Médico, Dentista, Enfermero y Farmacéutico" como anotación para el campo Contactos::Puesto.

No consultar campos de sumario

El valor de un campo de sumario en una base de datos de FileMaker depende de los registros del conjunto encontrado actual, por lo que una consulta SQL puede devolver un resultado incorrecto en algunos casos. En su lugar, omita las anotaciones de campo para los campos de resumen, de modo que se excluyan del DDL. SQL es lo suficientemente sofisticado como para realizar las tareas de los campos de sumario sin incluirlos en el DDL.

Notas 

Para mantener la compatibilidad con apps personalizadas que utilizan comentarios de campo en lugar de anotaciones de campo:

  • Si no se especifican anotaciones de campo en una tabla, todos los campos de esa tabla se incluyen en el DDL. Los comentarios de campo, si los hay, se incluyen como descripciones en el DDL.

  • Si una anotación de campo está en blanco y el comentario del campo comienza con la etiqueta especial [LLM], el texto del comentario (sin la etiqueta [LLM]) se utiliza en el DDL como si fuera una anotación.

Temas relacionados