Diseño de arquitectura 4D: una guía completa

El diseño arquitectónico 4D es el proceso de estructurar una base de datos 4D (sus tablas, campos, relaciones, índices y niveles de acceso) para que la aplicación se mantenga rápida, mantenible y segura a medida que crece. Un esquema 4D bien planificado normalmente implica cinco decisiones fundamentales: granularidad de las tablas, estrategia de relaciones, tipo de clave primaria, ubicación de los índices y separación de los datos respecto de la lógica de interfaz. Hacerlo bien desde el principio te ayudará a evitar migraciones costosas en el futuro.

Puntos clave

• El diseño arquitectónico 4D separa tres concerns: el modelo de datos (tablas, campos, relaciones), la capa de lógica de negocio (métodos, clases, triggers) y la capa de presentación (formularios, list boxes, diálogos).
• El tipo de relación importa más que la cantidad de tablas: un vínculo de muchos a muchos necesita una tabla de unión, mientras que un vínculo de uno a muchos usa un campo de clave externa más una relación.
• Los índices aceleran las lecturas pero ralentizan las escrituras: indexa las claves externas y cualquier campo usado en la cláusula WHERE de una consulta, no todos los campos.
• La capa ORDA (Object Relational Data Access) de 4D cambia la forma de pensar el esquema: tablas y campos bien nombrados se convierten en nombres legibles de dataclasses y atributos en el código.
• El despliegue cliente-servidor frente al monousuario es una decisión arquitectónica, no una ocurrencia de última hora del despliegue: afecta el bloqueo, la caché y cómo escribes las consultas.
• Las convenciones de nomenclatura aplicadas de forma consistente desde el primer día ahorran más tiempo de refactorización que cualquier otro hábito.

Qué significa “arquitectura 4D” en un contexto de base de datos

El diseño arquitectónico 4D se refiere al diseño estructural de una aplicación construida sobre la plataforma 4D (4th Dimension), el entorno de base de datos relacional y desarrollo low-code publicado originalmente por el equipo de Laurent Ribardière en 1984 y mantenido actualmente por 4D SAS. A diferencia de una base de datos SQL pura, 4D integra el motor de datos, un lenguaje de programación, un diseñador de formularios y un servidor web/REST en un solo producto, por lo que “arquitectura” aquí abarca tanto el esquema como las capas de aplicación que se asientan sobre él.

El término a veces se confunde con la visualización arquitectónica (BIM 4D, el tiempo como cuarta dimensión en el diseño de edificios). Esta guía cubre el sentido informático: cómo disponer una base de datos 4D y sus capas de aplicación. Si llegaste buscando diseño de edificios, los conceptos siguientes no se aplican.

Las tres capas de una aplicación 4D

Los proyectos de diseño arquitectónico 4D se benefician de un modelo explícito por capas. Dividir responsabilidades evita que una aplicación en crecimiento se convierta en un enredo de scripts de formulario.

Capa 1 — El modelo de datos

El modelo de datos es el conjunto de tablas, campos, relaciones e índices almacenados en el archivo de estructura 4D. Esta capa no debería contener código de interfaz de usuario ni reglas de negocio que podrían residir en otro lugar. Los tipos de campo (texto, entero, real, fecha, hora, booleano, blob, objeto, imagen) y las longitudes de campo se fijan aquí, y cambiarlos más adelante en una base de datos en producción requiere cuidado.

Capa 2 — Lógica de negocio

La lógica de negocio reside en métodos de proyecto, clases y triggers de tabla. En el 4D moderno, las clases (introducidas con 4D v18 R3 y ampliadas desde entonces) te permiten escribir código reutilizable y testeable en lugar de dispersar la lógica por los métodos de formulario. Un trigger en una tabla se dispara al crear, guardar y eliminar: útil para pistas de auditoría, pero un trigger que llama a la interfaz de usuario fallará en contextos de servidor sin interfaz.

Relacionado: Airtable — Una interfaz simple de hoja de cálculo ubicada sobre una base de datos relacional real, con automatizaciones, vistas e interfaces para compartir..

Capa 3 — Presentación

La presentación abarca formularios, list boxes, diálogos de entrada y cualquier salida web o REST. Los formularios 4D se vinculan directamente a campos y variables, lo cual es cómodo pero fomenta poner lógica en el formulario. Mantener los métodos de formulario delgados —llamar a un método de clase y mostrar el resultado— es la mayor ganancia de mantenibilidad en la mayoría de los proyectos 4D.

Diseñar el modelo de datos: tablas, relaciones y claves

Las decisiones de modelado de datos en el diseño arquitectónico 4D siguen principios relacionales, con mecánicas específicas de 4D superpuestas.

Elegir la granularidad de las tablas

Una tabla debe representar un tipo de entidad. Dividir una tabla “cliente” en “cliente” y “direccion_cliente” tiene sentido cuando un cliente puede tener varias direcciones; fusionarlas tiene sentido cuando hay exactamente una dirección por cliente y no hay reutilización. Normalizar en exceso hacia muchas tablas pequeñas aumenta el número de relaciones y joins, lo que cuesta rendimiento en las vistas de lista.

Si estás de compras: Zoho Creator — Un creador de aplicaciones de bajo código que se conecta a la suite más amplia de Zoho y ofrece precios por usuario en lugar de por aplicación..

Tipos de relación

4D admite relaciones automáticas definidas en el editor de estructura y relaciones manuales creadas en código. Los patrones habituales:

Relación	Implementación en 4D	Uso típico
Uno a muchos	Campo de clave externa en el lado “muchos” más una relación	Factura → Líneas de factura
Muchos a muchos	Tabla de unión con dos claves externas	Productos ↔ Proveedores
Uno a uno	Clave primaria compartida o una clave externa única	Usuario → Perfil de usuario
Autorreferenciada	Clave externa que apunta a la misma tabla	Empleado → Manager

Estrategia de clave primaria

4D ofrece claves primarias longint autoincrementales y claves primarias UUID (texto). Las claves longint son compactas y rápidas de indexar; los UUID son globalmente únicos, lo cual importa al fusionar datos de varios sitios o sincronizar con sistemas externos. Un compromiso habitual es una clave interna longint más un campo de texto único separado de “referencia externa”.

Indexación y rendimiento de consultas

Los índices son la palanca de rendimiento de mayor impacto en el diseño arquitectónico 4D, y también la más fácil de aplicar en exceso.

Qué indexar

Indexa cualquier campo usado como clave externa de una relación, cualquier campo usado con frecuencia en los criterios de búsqueda de una consulta y cualquier campo usado para ordenar en list boxes grandes. 4D admite índices B-tree estándar, índices de palabras clave para búsqueda de texto por palabras e índices compuestos que cubren varios campos.

Qué no indexar

Cada índice añade coste de escritura y almacenamiento. Indexar un campo booleano con dos valores posibles rara vez ayuda. Indexar un campo que solo se lee como parte de la visualización de un registro completo añade sobrecarga sin ganancia. Revisa los índices después de que la aplicación tenga patrones de uso reales en lugar de adivinarlos de antemano.

Estrategia de consultas

Las consultas ORDA (ds.Invoice.query("Status = :1"; "Open")) son generalmente preferibles a los comandos QUERY clásicos para código nuevo porque devuelven selecciones de entidades que se pueden ordenar, filtrar y pasar entre métodos sin volver a consultar. Para tablas muy grandes, restringir la consulta con criterios indexados antes de aplicar filtros no indexados mantiene los tiempos de respuesta predecibles.

Relacionado: Knack — Un creador de bases de datos sin código dirigido a portales, directorios y herramientas internas, con precios fijos en lugar de tarifas por usuario..

ORDA y la arquitectura 4D moderna

ORDA (Object Relational Data Access) es la capa de acceso a datos orientada a objetos de 4D, introducida en 4D v17. Expone las tablas como dataclasses y los registros como entidades, de modo que una tabla llamada Invoice se convierte en ds.Invoice y un campo llamado TotalNet se convierte en $invoice.TotalNet.

Esto tiene una consecuencia arquitectónica para el diseño arquitectónico 4D: los nombres de tablas y campos ahora forman parte de tu API pública. Renombrar un campo rompe el código de una forma visible en tiempo de compilación, pero una nomenclatura inconsistente hace que el código ORDA sea difícil de leer. Adoptar una convención —nombres de tabla en singular, campos en PascalCase, sin abreviaturas— da sus frutos de inmediato.

ORDA también admite selecciones de entidades en el lado del cliente que solo se cargan parcialmente, lo que cambia el perfil de rendimiento de las pantallas de lista. Un list box vinculado a una selección de entidades puede mostrar miles de filas sin cargar todos los registros, suponiendo que la consulta que hay detrás esté indexada.

Nuestra elección: Claris FileMaker Pro — La plataforma de base de datos relacional de larga duración para equipos que necesitan aplicaciones personalizadas en escritorio, web y dispositivos móviles desde un solo archivo..

Despliegue cliente-servidor, monousuario y web

La topología de despliegue da forma al diseño arquitectónico 4D más de lo que muchos desarrolladores esperan.

Las aplicaciones monousuario ejecutan el motor de datos y la interfaz en un solo proceso. El bloqueo es trivial; el ajuste de rendimiento se centra sobre todo en la velocidad del disco local.

Cliente-servidor separa 4D Server (motor de datos) de 4D Client (interfaz). Los registros se bloquean en el servidor, y el coste del ida y vuelta por red de cada consulta se vuelve significativo. Las arquitecturas que lanzan muchas consultas pequeñas por pantalla rinden mal aquí; agrupar consultas y usar selecciones de entidades reduce los viajes de ida y vuelta.

El despliegue web y REST expone el mismo modelo de datos a través del servidor REST de 4D o mediante métodos web compilados. La seguridad pasa a primer plano: el acceso a tablas y campos debe restringirse mediante roles y privilegios, y cualquier regla de negocio aplicada solo en un método de formulario queda efectivamente sin aplicar para los clientes web.

Convenciones de nomenclatura y documentación

Una nomenclatura consistente es poco glamurosa pero decisiva para el diseño arquitectónico 4D. Una convención viable para 4D:

• Tablas: sustantivos en singular, PascalCase (“Customer”, “InvoiceLine”).
• Campos: PascalCase, sin prefijos de tipo (“InvoiceDate”, no “dInvDate”).
• Relaciones: nombradas según la tabla de destino (“Customer_Invoices”).
• Métodos: verbo primero (“CreateInvoice”, “RecalculateTotals”).
• Clases: sustantivo primero (“InvoiceService”, “TaxCalculator”).

Documentar el esquema —aunque sea como un único archivo Markdown que liste cada tabla, su propósito y sus relaciones clave— facilita enormemente la incorporación de nuevo personal y las futuras migraciones. El editor de estructura de 4D muestra las relaciones gráficamente, pero no explica por qué existe una tabla.

Errores comunes en el diseño arquitectónico 4D

Poner la lógica de negocio en los métodos de formulario. Los métodos de formulario no se pueden llamar desde contextos web ni desde tareas programadas, por lo que la lógica atrapada ahí debe duplicarse.

Usar comandos clásicos basados en selecciones en todo el código nuevo. Las selecciones clásicas están ligadas al proceso y no viajan bien entre procesos; las selecciones de entidades ORDA son más flexibles.

Saltarse la tabla de unión. Almacenar varios valores en un único campo de texto (IDs separados por comas) anula la indexación y hace que los informes sean un suplicio.

Indexarlo todo. El rendimiento de escritura se degrada y el beneficio rara vez se materializa.

Ignorar los privilegios hasta el despliegue. Adaptar un modelo de seguridad a una aplicación terminada es significativamente más difícil que diseñarlo junto con el esquema.

Cómo decidir: una lista de comprobación práctica

Antes de construir tu diseño arquitectónico 4D, repasa estas preguntas:

1. ¿Cuántos usuarios concurrentes habrá, y se conectarán por LAN, WAN o web?
2. ¿Qué entidades tienen una relación natural de uno a muchos, y cuáles necesitan tablas de unión?
3. ¿Qué campos aparecerán en criterios de búsqueda u órdenes de clasificación en tablas grandes?
4. ¿Qué reglas de negocio deben cumplirse independientemente del punto de entrada (formulario, web, importación)?
5. ¿Se fusionarán alguna vez los datos con otro sistema, lo que requeriría claves UUID?
6. ¿Quién mantendrá esto dentro de dos años, y tendrá sentido para esa persona la nomenclatura?

Las respuestas a estas seis preguntas determinan la mayoría de las decisiones estructurales en un proyecto 4D.

Lecturas adicionales

La documentación oficial de 4D en developer.4d.com cubre ORDA, clases, privilegios y despliegue en detalle. Para los fundamentos del modelado relacional que se aplican independientemente de la plataforma, consulta el artículo de Wikipedia sobre normalización de bases de datos. Para el contexto más amplio de las plataformas low-code y de desarrollo rápido de aplicaciones, la entrada de Wikipedia sobre plataformas de desarrollo low-code es un punto de partida razonable. 4D SAS también publica notas de versión y guías de migración que describen cuándo se introdujeron ORDA, las clases y otras características del diseño arquitectónico 4D.

Preguntas frecuentes

¿Qué es el diseño arquitectónico 4D?

El diseño arquitectónico 4D es el proceso de planificar la estructura de una aplicación 4D (4th Dimension): sus tablas, campos, relaciones, índices, capa de lógica de negocio y capa de presentación. Determina cómo rinde la aplicación, con qué facilidad se puede modificar y con qué seguridad se puede desplegar en clientes de escritorio, cliente-servidor o web.

¿Es lo mismo la arquitectura 4D que el BIM 4D?

No. El BIM 4D añade el tiempo como cuarta dimensión al modelado de información de construcción para la planificación de obras. La arquitectura 4D en el sentido informático se refiere al diseño de aplicaciones sobre la plataforma de base de datos 4D. Los dos campos comparten una abreviatura, pero nada más.

¿Debería usar ORDA o los comandos clásicos de 4D?

ORDA es la mejor opción para desarrollos nuevos. Devuelve selecciones de entidades que se pueden pasar entre métodos, ordenar y filtrar sin necesidad de volver a consultarlas, y expone tablas y campos como propiedades de objetos legibles. Los comandos clásicos basados en selecciones siguen siendo útiles en código heredado y en algunos casos especiales.

¿Cuántos índices debería tener una tabla 4D?

No hay un número fijo. Indexa las claves externas, los campos usados en criterios de búsqueda habituales y los campos usados para ordenar listas grandes. Evita indexar campos de baja cardinalidad, como valores booleanos o campos de estado con dos o tres valores, ya que el coste de escritura suele superar el beneficio de lectura.

¿Qué tipo de clave primaria debería elegir en 4D?

Las claves longint autoincrementales son compactas y rápidas, y van bien para aplicaciones de un solo sitio. Las claves de texto UUID son más grandes pero globalmente únicas, lo cual importa al fusionar datos de varios sitios o integrarse con sistemas externos. Muchos proyectos usan una clave longint interna más un campo único de referencia externa.

¿Puedo cambiar el modelo de datos 4D después del despliegue?

Sí, pero con cuidado. Agregar tablas, campos e índices generalmente es sencillo. Cambiar los tipos de campos, cambiar el nombre de los campos utilizados por el código ORDA o reestructurar las relaciones en una base de datos activa requiere una migración planificada, idealmente probada primero en una copia de los datos de producción.