Managing my data

Why Use Relationships?

Instead of duplicating data across multiple entities, relationships allow you to:

• Eliminate data redundancy - Store information once and reference it everywhere

• Maintain data integrity - Update information in one place and see changes everywhere

• Create powerful queries - Search and filter across connected data

• Build complex applications - Model real-world scenarios like customers with orders, posts with comments, or users with roles

Relationship Types Explained

One-to-One (1:1)

Each record in Entity A connects to exactly one record in Entity B, and vice versa.

Example: User ↔ Profile

• Each user has exactly one profile

• Each profile belongs to exactly one user

When to use: When you want to split data into separate entities for organization, security, or performance reasons.

One-to-Many (1:Many)

One record in Entity A can connect to multiple records in Entity B, but each record in Entity B connects to only one record in Entity A.

Example: Customer → Orders

• One customer can have many orders

• Each order belongs to one customer

When to use: The most common relationship type - perfect for hierarchical data like categories with products, authors with books, or companies with employees.

Many-to-One (Many:1)

Multiple records in Entity A connect to one record in Entity B. This is essentially the reverse perspective of One-to-Many.

Example: Orders → Customer

• Many orders can belong to one customer

• Each order has one customer

When to use: When you're viewing a One-to-Many relationship from the "many" side.

Many-to-Many (Many:Many)

Records in Entity A can connect to multiple records in Entity B, and records in Entity B can connect to multiple records in Entity A.

Example: Students ↔ Courses

• One student can enroll in many courses

• One course can have many students

When to use: When both entities can have multiple connections to each other. Common examples include tags, categories, permissions, or any scenario requiring flexible associations.

Dynamic Reference

A flexible relationship that can point to records in any entity type, determined at runtime.

Example: Comments → (Posts, Products, Users, etc.)

• A comment could be attached to a blog post, product review, or user profile

• The target entity type is stored dynamically

When to use: When you need maximum flexibility and don't know in advance which entity types will be connected.

How Relationships Work in Practice

Setting Up Relationships

1. Choose the relationship type based on your data model

1. Define the connection - which entities connect and how

1. Configure display options - how related data appears in your interface

1. Set permissions - who can create, view, or modify relationships

Querying Related Data

Anythink automatically handles the complexity of joining related data:

• Search across relationships - Find customers by their order status

• Filter by related fields - Show products in specific categories

• Aggregate related data - Count orders per customer, average ratings per product

Performance Considerations

• Indexed relationships - Anythink automatically optimizes relationship queries

• Lazy loading - Related data loads only when needed

• Caching - Frequently accessed relationships are cached for speed

Best Practices

Planning Your Relationships

1. Start with your core entities - Identify the main "things" in your system

1. Map real-world connections - How do these things relate in reality?

1. Consider data flow - How will users navigate between related information?

1. Think about permissions - Who should see which relationships?

Common Patterns

• User Management: Users → Roles → Permissions (Many-to-Many)

• E-commerce: Categories → Products → Orders → Customers (Mixed relationships)

• Content Management: Authors → Posts → Tags → Comments (Mixed relationships)

• CRM: Companies → Contacts → Deals → Activities (Hierarchical relationships)

Avoiding Common Pitfalls

• Don't over-normalize - Not every piece of data needs its own entity

• Consider query patterns - Design relationships around how you'll actually use the data

• Plan for scale - Some relationship patterns perform better at large scale than others

• Keep it intuitive - Your data model should make sense to users who will work with it

Relationships transform simple data storage into powerful, interconnected systems that mirror the complexity of real-world scenarios while maintaining simplicity for end users.

Entities

An entity is a table in your database. Create as many entities as your application needs.

Go to Settings → Data Model and click + New Entity. Give it a name in snake_case (e.g. blog_posts, customers, orders).

Every entity automatically gets:

• An id field (auto-incrementing integer, primary key)
• created_at and updated_at timestamps (managed automatically)
• A full REST API (list, get, create, update, delete)

Field types

When adding a field, choose a storage type that determines how the data is stored in the database.

varchar — multi-select options

A varchar field can be configured as a multi-select with a fixed set of allowed values. Define the options when creating the field. Values are stored as a varchar[] array.

Display types

When adding a field, you also choose how it renders in the dashboard UI. The display type is separate from the storage type and does not affect the API.

Field options

When creating or editing a field, you can set:

Relationships (foreign keys)

Link entities together by adding a Foreign key field. Choose:

• Entity — which entity this field points to (e.g. categories)
• Display — which field from the related entity to show in the dashboard

When creating a record via the API, pass the ID of the related record:

POST /entities/products/items
{
  "name": "Wireless Headphones",
  "price": 79.99,
  "category": 3
}

The category field stores the integer ID of the related category record.

Filtering by relationship

GET /entities/products/items?filter[category]=3

Row-level security (RLS)

When creating an entity, you can enable Row-Level Security. This locks each record to the user who created it — other users cannot read or modify records they do not own, regardless of role permissions.

Enable RLS on the entity settings page, or when creating via the CLI:

anythink entities create orders --rls

Modifying entities

You can add new fields to existing entities at any time. The new field is added to the database immediately and all existing records get a null value for it.

Deleting a field permanently removes it and all its data. There is no undo.

The live API

After saving any change to your data model, the API updates immediately. Open the API Documentation link in your dashboard to see the current endpoints and try them live.

Switching views

The view toolbar appears at the top-left of every entity overview page. Click an icon to switch:

Your view preference is saved per entity, so switching tabs or logging out will keep your preferred layout.

Grid view

The default view. Displays your data as a sortable, filterable table.

Key features:

• Column picker — choose which fields to show/hide via the column selector
• Sort — click any column header to sort ascending or descending
• Filter — type in the filter bar to search across indexed fields
• Pagination — navigate pages and choose how many rows to show (10, 25, 50, 100)
• Row click — click any row to open the full record drawer
• Multi-select — tick the checkbox on multiple rows, then delete in bulk

Instant Edit mode

Toggle the "Instant Edit" switch in the toolbar to enable inline cell editing. Click any cell to edit its value directly without opening the drawer. Changes are saved immediately on blur.

Kanban view

Groups records into columns based on a varchar (select) field. Drag cards between columns to update that field.

How it works:

• Anythink automatically uses your entity's first select-type field as the grouping dimension
• Each unique value in that field becomes a column
• Cards show the record's name field and key metadata
• Drag a card to a new column to update the field value instantly

Kanban is ideal for workflows with named stages — e.g. Todo / In Progress / Done or Lead / Prospect / Customer.

Calendar view

Plots records on a calendar using a date or timestamp field.

How it works:

• Records appear on the date matching their date field
• Click a date to see all records that day
• Click a record to open its full detail drawer
• Navigate months using the arrow controls

Calendar view is ideal for bookings, content schedules, events, or any entity with a meaningful date.

Map view

Renders records as pins on an interactive map using a geo field.

Requirements:

• The entity must have at least one field of type geo
• Your organisation must have a Google Maps API key configured in Settings → Organisation

How it works:

• Each record with a populated geo field appears as a pin on the map
• Click a pin to see the record's name and key fields in a popup
• Click the popup to open the full record drawer

Map view is ideal for property listings, delivery locations, store finders, or any geo-tagged data.

Charts view

Generates bar charts and line charts from numeric fields in your entity.

How it works:

• Anythink automatically identifies integer and float fields in your entity
• Charts are rendered for each numeric field, showing value distribution across records
• Aggregate totals and averages appear alongside the charts
• Charts are read-only — use Grid view for editing

Charts view is ideal for quick analytics without building a separate reporting layer.

View preferences

View preferences are stored per entity in your browser (using local storage). They persist across page navigations and browser refreshes but are scoped to the current device.

To reset to Grid view, click the grid icon in the view toolbar at any time.