History[07][08]

4D was originally developed under the name "Silver Surfer" in the 1980s as a DBMS for the Macintosh platform. Apple canceled the project after receiving pressure from 3rd party software developers who feared the product would have an unfair competitive advantage if Apple released it. The project lead, Laurent Ribardière, left Apple and continued to develop the DBMS, ultimately releasing it under the name 4th Dimension. The product gained popularity for its user-friendly interface and ability to handle large amounts of data. 4D later added features like SQL support and a web server to keep up with newer systems. The product is still under active development and used by many companies.

Checkpoints[09][10][11]

Every modification to the data file since the last backup is recorded in the associated log file. If the database file is corrupted, 4D will restore the most recent backup and replay the changes in the log. When a new backup is created, the log file is cleared. Backups can be triggered manually or on a schedule. The database cannot be edited while a backup is running.

Compression[12][13]

4D Web Server supports using gzip compression when communicating with clients. Gzip compression can also be used to shrink BLOB objects stored in the database. The 4D documentation does not mention support for any other types of compression.

Concurrency Control[14][15][16]

4D requires users to explicitly lock/unlock records and avoid deadlocks. For every user/process, each table in the database is given a read-only or read/write status. If a table is in the read-only state for a given user, all existing records loaded from the table are considered locked and cannot be modified. Any user can append new records to a table, even if it is read-only. If a table is in the read/write state, records will load as unlocked for the first user to load them. To modify a record that is already locked, a user can repeatedly load the record until it unlocks. A user unloads a record to make it available again to other users/processes.

A user can change a table from read-only to read/write or back at any time, but this only affects future load requests made by that user. If a read/write command is executed on a locked record, the command will either be ignored, display an error, or skip the record (if the command targets multiple records). Skipped records are added to the LockedSet of the requesting process to alert it of the error.

Queries can be grouped into transactions to ensure that changes occur atomically, but there is no deadlock prevention/detection. While a transaction is running, changes are saved into a temporary buffer and any modified records are locked.

Data Model[17]

4D uses a standard relational database structure with tables, fields, and relations.

Foreign Keys[18]

4D supports one-to-one, many-to-one, and many-to-many relations between tables. Relations are classified as either automatic or non-automatic. Automatic relations cause foreign records to be loaded with records that reference them, while non-automatic relations do not. Automatic relations should avoid cyclic table references.

Hardware Acceleration[19]

The 4D documentation makes no mention of hardware acceleration.

Indexes[20]

Indices can use a B+Tree or clustered B+Tree. 4D supports composite indices (indices on pairs of values). It also supports keyword indices (indices mapping individual words to records containing them).

Isolation Levels[21][16]

Transactions lock records they modify or create, preventing other transactions from interfering with them. Unrepeatable reads may occur since transactions do not lock records they read. Table entries can be added while a transaction is running, creating invalid aggregation results (phantom problem). Transactions store all modifications in a temporary buffer, so uncommitted data can't affect other transactions.

Isolations levels for 4D transactions are not mentioned in the product documentation, but the behavior is consistent with the Read Committed isolation level.

Joins[22][23][24][25][26]

Queries involving joins are invoked with the "query" and "query by formula" commands in the 4D language. If an index is available, 4D will perform an index nested loop join or an ordinary nested loop join, depending on which is faster given the table sizes. If no index is present, the documentation states that 4D uses the join algorithm used by its SQL engine (presumably Hash Join). The "relate one" and "relate many" commands are also similar to a join on a primary key. They fetch records directly using the primary key, if possible.

Logging[27][28]

When a new data file is created, 4D automatically generates a log file for it with the ".journal" extension. The log file contains a record of all modifications since the last database backup. Entries describe the change that was performed as well as the user and time of the modification. The log also records when a user opens/closes the database.

Parallel Execution[29]

4D does not automatically utilize parallelism, but users can manually exploit parallelism by running multiple processes. Concurrency control and record locking for multiple 4D processes is handled similarly to multi-user scenarios.

Query Compilation[30]

The 4D language can be either interpreted or compiled. By default, an interpreter is used. A built-in compiler can convert the database application into machine code to increase performance.

Query Execution[31][32][33]

The 4D query command outputs a selection (subset) of records from a single table. The selection is the set of records that satisfy the query parameters. If the table has any automatic relations, fields from related tables can be referenced in the filtering criteria. The selection can be stored as a named set or combined with other sets using union/intersection commands. Since each set is fully generated before further processing, this is best classified as a materialized model.

Query Interface[24][34][35]

4D provides a graphical interface for managing data in a 4D database. Developers can customize the interface using the proprietary 4D programming language to provide additional buttons/forms for data manipulation. The language has syntax for control flow, variable creation, and database queries.

4D includes a SQL engine and the language supports inline SQL queries, though any SQL functionality can be replicated using the 4D language.

Storage Architecture[09]

4D database files are stored on disk. An in-memory cache is used to improve performance, but transactions are immediately written to the on-disk log file when they are committed.

Storage Model[36]

A 4D database primarily consists of a structure file (for storing the schema), a data file (records stored in a row store format), and a log file for crash recovery. The database also has preferences folder and a resources folder with images/assets used for custom UI. Indices are stored in an index file.

Stored Procedures[37]

4D supports saving 4D language scripts to a 4D server as stored procedures. Scripts stored on a server can be invoked by a remote client. Stored procedures run on the server, making them more efficient than running the query locally and making many remote calls.

System Architecture[38]

4D is designed to be run on a single server machine, though it can be accessed by multiple remote clients.

Views[39][40]

4D supports virtual views as part of its SQL engine. It also has dynamic forms which can display dynamically generated information next to a list of records. This information is regenerated every time the form is loaded.