4D Architecture Design: A Complete Guide

4D architectural design is the process of structuring a 4D database (its tables, fields, relationships, indexes, and access levels) so that the application remains fast, maintainable, and secure as it grows. A well-planned 4D schema typically involves five core decisions: table granularity, relationship strategy, primary key type, index location, and separation of data from interface logic. Getting this right from the beginning will help you avoid costly migrations in the future.

Key Takeaways

• 4D architecture design separates three concerns: the data model (tables, fields, relations), the business logic layer (methods, classes, triggers) and the presentation layer (forms, list boxes, dialogs).
• Relation type matters more than table count: a many-to-many link needs a junction table, while a one-to-many link uses a foreign key field plus a relation.
• Indexes speed reads but slow writes — index foreign keys and any field used in a query’s WHERE clause, not every field.
• 4D’s ORDA (Object Relational Data Access) layer changes how you think about schema: well-named tables and fields become readable dataclass and attribute names in code.
• Client-server versus single-user deployment is an architectural decision, not a deployment afterthought — it affects locking, caching and how you write queries.
• Naming conventions applied consistently from day one save more refactoring time than any other single habit.

What “4D Architecture” Means in a Database Context

4D architecture design refers to the structural design of an application built on the 4D platform (4th Dimension), the relational database and low-code development environment originally released by Laurent Ribardière’s team in 1984 and now maintained by 4D SAS. Unlike a pure SQL database, 4D bundles the data engine, a programming language, a form designer and a web/REST server into one product — so “architecture” here spans both the schema and the application layers sitting on top of it.

The term is sometimes confused with architectural visualisation (4D BIM, time as the fourth dimension in building design). This guide covers the software sense: how to lay out a 4D database and its application layers. If you arrived looking for building design, the concepts below won’t apply.

The Three Layers of a 4D Application

4D architecture design projects benefit from an explicit layered model. Splitting responsibilities keeps a growing app from turning into a tangle of form scripts.

Layer 1 — The Data Model

The data model is the set of tables, fields, relations and indexes stored in the 4D structure file. This layer should contain no user-interface code and no business rules that could live elsewhere. Field types (text, integer, real, date, time, Boolean, blob, object, picture) and field lengths are fixed here, and changing them later on a live database requires care.

Layer 2 — Business Logic

Business logic lives in project methods, classes and table triggers. In modern 4D, classes (introduced with 4D v18 R3 and expanded since) let you write reusable, testable code rather than scattering logic across form methods. A trigger on a table fires on create, save and delete — useful for audit trails, but a trigger that calls the user interface will break in headless server contexts.

Related: Airtable — A spreadsheet-simple interface sitting on top of a real relational database, with automations, views, and shareable interfaces..

Layer 3 — Presentation

Presentation covers forms, list boxes, input dialogs and any web or REST output. 4D forms bind directly to fields and variables, which is convenient but encourages putting logic in the form. Keeping form methods thin — calling a class method and displaying the result — is the single biggest maintainability win in most 4D projects.

Designing the Data Model: Tables, Relations and Keys

Data modelling decisions in 4D architecture design follow relational principles, with 4D-specific mechanics layered on.

Choosing Table Granularity

A table should represent one entity type. Splitting a “customer” table into “customer” and “customer_address” makes sense when a customer can have several addresses; merging them makes sense when there is exactly one address per customer and no reuse. Over-normalising into many small tables increases the number of relations and joins, which costs performance in list views.

If you are shopping: Zoho Creator — A low-code app builder that plugs into the wider Zoho suite and prices per user rather than per app..

Relation Types

4D supports automatic relations defined in the structure editor and manual relations created in code. The common patterns:

Relation	4D implementation	Typical use
One-to-many	Foreign key field on the “many” side plus a relation	Invoice → Invoice lines
Many-to-many	Junction table with two foreign keys	Products ↔ Suppliers
One-to-one	Shared primary key or a unique foreign key	User → User profile
Self-referencing	Foreign key pointing back to the same table	Employee → Manager

Primary Key Strategy

4D offers auto-incrementing longint primary keys and UUID (text) primary keys. Longint keys are compact and fast to index; UUIDs are globally unique, which matters when merging data from multiple sites or syncing with external systems. A common compromise is a longint internal key plus a separate unique “external reference” text field.

Indexing and Query Performance

Indexes are the highest-leverage performance lever in 4D architecture design, and also the easiest to over-apply.

What to Index

Index any field used as a relation’s foreign key, any field frequently used in a query’s search criteria, and any field used for sorting in large list boxes. 4D supports standard B-tree indexes, keyword indexes for word-based text search, and composite indexes covering multiple fields.

What Not to Index

Every index adds write cost and storage. Indexing a Boolean field with two possible values rarely helps. Indexing a field that is only ever read as part of a full-record display adds overhead for no gain. Review indexes after the application has real usage patterns rather than guessing up front.

Query Strategy

ORDA queries (ds.Invoice.query("Status = :1"; "Open")) are generally preferable to classic QUERY commands for new code because they return entity selections that can be sorted, filtered and passed between methods without re-querying. For very large tables, restricting the query with indexed criteria before applying non-indexed filters keeps response times predictable.

Related: Knack — A no-code database builder aimed at portals, directories, and internal tools — with flat-rate pricing instead of per-user fees..

ORDA and Modern 4D Architecture

ORDA (Object Relational Data Access) is 4D’s object-oriented data access layer, introduced in 4D v17. It exposes tables as dataclasses and records as entities, so a table named Invoice becomes ds.Invoice and a field named TotalNet becomes $invoice.TotalNet.

This has an architectural consequence for 4d architecture design: table and field names are now part of your public API. Renaming a field breaks code in a way that is visible at compile time, but inconsistent naming makes ORDA code hard to read. Adopting a convention — singular table names, PascalCase fields, no abbreviations — pays off immediately.

ORDA also supports client-side entity selections that are only partially loaded, which changes the performance profile of list screens. A list box bound to an entity selection can display thousands of rows without loading every record, assuming the query behind it is indexed.

Our pick: Claris FileMaker Pro — The long-running relational database platform for teams that need custom apps on desktop, web, and mobile from a single file..

Client-Server, Single-User and Web Deployment

The deployment topology shapes the 4d architecture design more than many developers expect.

Single-user applications run the data engine and interface in one process. Locking is trivial; performance tuning is mostly about local disk speed.

Client-server splits the 4D Server (data engine) from 4D Client (interface). Records are locked on the server, and the network round-trip cost of each query becomes significant. Architectures that issue many small queries per screen perform badly here; batching queries and using entity selections reduces round trips.

Web and REST deployment exposes the same data model through 4D’s REST server or through compiled web methods. Security moves to the forefront: table and field access must be restricted through roles and privileges, and any business rule enforced only in a form method is effectively unenforced for web clients.

Naming Conventions and Documentation

Consistent naming is unglamorous but decisive for 4d architecture design. A workable convention for 4D:

• Tables: Singular nouns, PascalCase (“Customer”, “InvoiceLine”).
• Fields: PascalCase, without type prefixes (“InvoiceDate”, not “dInvDate”).
• Relationships: named according to the destination table (“Customer_Invoices”).
• Methods: verb first (“CreateInvoice”, “RecalculateTotals”).
• Classes: Noun first (“InvoiceService”, “TaxCalculator”).

Documenting the schema — even as a single Markdown file listing each table, its purpose and its key relations — makes onboarding and future migrations far easier. 4D’s structure editor shows relations graphically, but it does not explain why a table exists.

Common 4D Architecture Design Mistakes

Putting business logic in form methods. Form methods cannot be called from web contexts or scheduled tasks, so logic trapped there must be duplicated.

Using selection-based classic commands throughout new code. Classic selections are process-bound and do not travel well between processes; ORDA entity selections are more flexible.

Skipping the junction table. Storing multiple values in a single text field (comma-separated IDs) defeats indexing and makes reporting painful.

Indexing everything. Write performance degrades and the benefit is rarely realised.

Ignoring privileges until deployment. Retrofitting a security model onto a finished application is significantly harder than designing it alongside the schema.

How to Decide: A Practical Checklist

Before building your 4d architecture design, work through these questions:

1. How many concurrent users, and will they connect over a LAN, WAN or the web?
2. Which entities have a natural one-to-many relationship, and which need junction tables?
3. Which fields will appear in search criteria or sort orders on large tables?
4. Which business rules must hold regardless of entry point (form, web, import)?
5. Will data ever be merged with another system, requiring UUID keys?
6. Who maintains this in two years, and will the naming make sense to them?

Answers to these six questions determine most of the structural decisions in a 4D project.

Further Reading

The official 4D documentation at developer.4d.com covers ORDA, classes, privileges and deployment in detail. For relational modelling fundamentals that apply regardless of platform, see the Wikipedia article on database normalization. For the broader context of low-code and rapid application development platforms, the Wikipedia entry on low-code development platforms is a reasonable starting point. 4D SAS also publishes release notes and migration guides that describe when ORDA, classes and other 4d architecture design features were introduced.

Frequently Asked Questions

What is 4D architecture design?

4D architecture design is the process of planning the structure of a 4D (4th Dimension) application: its tables, fields, relations, indexes, business logic layer and presentation layer. It determines how the application performs, how easily it can be changed, and how securely it can be deployed to desktop, client-server or web clients.

Is 4D architecture the same as 4D BIM?

No. 4D BIM adds time as a fourth dimension to building information modelling for construction scheduling. 4D architecture in the software sense refers to designing applications on the 4D database platform. The two fields share an abbreviation but nothing else.

Should I use ORDA or classic 4D commands?

ORDA is the best option for new developments. It returns entity selections that can be passed between methods, sorted, and filtered without needing to be queried again, and exposes tables and fields as properties of readable objects. Classic selection-based commands are still useful in legacy code and in some special cases.

How many indexes should a 4D table have?

There is no fixed number. Index foreign keys, fields used in common search criteria, and fields used to sort large lists. Avoid indexing fields with low cardinality, such as boolean values ​​or status fields with two or three values, as the write cost usually outweighs the read benefit.

What primary key type should I choose in 4D?

Auto-incrementing longint keys are compact and fast, and suit single-site applications. UUID text keys are larger but globally unique, which matters when merging data from multiple sites or integrating with external systems. Many projects use a longint key internally plus a unique external reference field.

Can I change the 4D data model after deployment?

Yes, but with care. Adding tables, fields and indexes is generally straightforward. Changing field types, renaming fields used by ORDA code, or restructuring relations on a live database requires a planned migration, ideally tested on a copy of production data first.

P.S. A few readers have asked which relational database platform we actually reach for — it's Claris FileMaker Pro; take a look here if you want the current details.