> ## Documentation Index
> Fetch the complete documentation index at: https://docs.serial.okos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Components

> An in-depth look at the structure and purpose of the `components` table in the Serial database

## Introduction to the Components Table

The Components table is designed to store and manage information about various components associated with companies in the Serial system. This table plays a crucial role in organizing and tracking the status, type, and ownership of components within the application.

## Table Structure

The Components table is structured to efficiently store essential information about each component. Here's a detailed breakdown of its columns:

| Column Name            | Data Type | Constraints | Description                                       |
| ---------------------- | --------- | ----------- | ------------------------------------------------- |
| id                     | uuid      | primary key | Unique identifier for each component              |
| company\_id            | uuid      | foreign key | References the company that owns the component    |
| last\_edited\_user\_id | uuid      | foreign key | References the user who last edited the component |
| status                 | text      |             | Current status of the component                   |
| type                   | text      |             | Type or category of the component                 |
| created\_at            | timestamp | not null    | Timestamp of when the component was created       |
| is\_active             | boolean   | not null    | Flag indicating whether the component is active   |

## Usage and Functionality

The Components table is designed to be a central repository for component information within the Serial application. Here are some key points about its usage:

1. **Company Association**: Each component is linked to a specific company through the `company_id` foreign key, allowing for efficient organization and retrieval of company-specific components.

2. **Tracking Changes**: The `last_edited_user_id` column helps maintain an audit trail by recording which user last modified the component's information.

3. **Status and Type Management**: The `status` and `type` columns allow for categorization and tracking of components throughout their lifecycle, enabling efficient filtering and reporting.

4. **Active/Inactive Flagging**: The `is_active` boolean column provides a quick way to determine whether a component is currently in use or has been deprecated, without the need to delete records.

## Notes

* Foreign key relationships with the companies and users tables maintain data integrity and enable complex queries across related data.

* Example usage in TypeScript:

  ```typescript
  const newComponent = {
    id: uuid(),
    company_id: companyId,
    last_edited_user_id: currentUserId,
    status: "active",
    type: "hardware",
    created_at: new Date(),
    is_active: true,
  };
  await supabase.from("components").insert(newComponent);
  ```

* When querying the Components table, it's important to consider the `is_active` flag to ensure only relevant components are retrieved in most operations.

By leveraging the Components table, the Serial application can efficiently manage and track various components across different companies, providing a robust foundation for inventory management, component lifecycle tracking, and related functionalities within the system.