> For the complete documentation index, see [llms.txt](https://docs.amltd.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.amltd.com/dc-works/databases-and-tables.md).

# Databases and Tables

Databases and tables provide the structure used to store and organize information in DC Works. Applets use this structure to retrieve, display, add, and update data as users complete a workflow.

Planning this structure before building Applets helps ensure that information is stored consistently, workflows remain manageable, and the collected data can support future reporting and analysis.

<figure><img src="/files/4xZOWzVX1ojG463oCN43" alt=""><figcaption></figcaption></figure>

*A database groups the related tables used by a solution or business process.*

### How DC Works organizes data

DC Works organizes stored information using databases, tables, fields, and records.

| Component     | Purpose                                                                        |
| ------------- | ------------------------------------------------------------------------------ |
| Database      | Groups related tables within a solution or business process                    |
| Table         | Stores a particular type or category of information                            |
| Field         | Defines an individual item of information stored in a table                    |
| Record        | Contains the field values for one stored entry                                 |
| Primary field | Serves as the principal reference field when identifying or retrieving records |

For example, a repair-management solution might use one database containing:

* A table with the current information for each device.
* A table containing valid repair statuses.
* A table containing operator names.
* A table recording the history of each repair.

The Applets used for check-in, repair, and quality control can interact with these shared tables while presenting different screens and functions to different users.

### Plan before creating Applets

The database structure should normally be planned before Applet development begins.

Before creating tables and fields, determine:

* What process the solution must support.
* What information must be stored.
* What one record in each table will represent.
* Which values are known in advance.
* Which information will change during the workflow.
* Whether important changes must be preserved historically.
* What reports or measurements may be required later.

A clear data structure makes it easier to configure Applet records, bind fields, create actions, and manage workflow logic.

{% hint style="info" %}
Start with the essential workflow and expand it as requirements become clearer. Creating unnecessary tables, fields, and integrations at the beginning can make a solution more difficult to build and maintain.
{% endhint %}

### Current information and historical activity

Some workflows need to show both the current state of an item and the steps it has previously completed.

In these cases, the solution may use:

* A main table containing the item’s current information.
* A history table containing a separate record for each significant workflow event.

### Example used in this chapter

This chapter uses an actual  RMA process as a practical example.

The RMA solution includes:

* A main device-information table.
* Reference tables for operators and device statuses.
* A repair-history table.
* Separate Applets for administration, repair processing, and reporting.
* Separate Suites providing users with the appropriate Applets.

The example demonstrates how a business process can be divided into manageable workflows while sharing a common data structure.

A complete explanation is provided in **Example: RMA Data Structure**.

### In this chapter

This chapter explains how to:

* Plan a data-driven workflow.
* Complete a data and workflow planning worksheet.
* Design an appropriate data structure.
* Create and manage databases.
* Create and manage tables.
* Define table fields.
* Add and manage table records.
* Use reference tables.
* Track current information and historical activity.
* Apply database and table best practices.
* Review a completed workflow and data-structure example.

{% hint style="info" %}
If you only want to create a basic database and table, refer to the database and table walkthrough in **Getting Started**. This chapter provides more detailed planning, configuration, and design guidance.
{% endhint %}

### Next

Continue to **Plan Your Data and Workflow** to identify the process, users, information, and history requirements before creating a database structure.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.amltd.com/dc-works/databases-and-tables.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.