Data Modeling
Design effective data structures for your Appivo applications
Data Modeling Guide
Learn how to design robust, scalable data models that form the foundation of your Appivo applications.
Understanding Models
A Model represents a type of business object in your application. When you create a model, Appivo automatically:
- Creates the database table
- Generates API endpoints
- Handles data persistence
- Provides query capabilities
Model Structure
Every model consists of:
- Attributes - The fields that store data
- Relationships - Connections to other models
- Validations - Rules that ensure data quality
- System Fields - Automatically managed fields
Attribute Types
| Type | Description | Use Case |
|---|---|---|
| String | Up to 255 characters | Names, titles, codes |
| Text | Extended text | Descriptions, notes, content |
| Integer | Whole numbers | Quantities, counts, IDs |
| Float | Numbers with decimals | Prices, ratings, measurements |
| Boolean | True/false | Flags, toggles, status |
| Date | Date only | Birth dates, due dates |
| Time | Time only | Schedules, durations |
| Date & Time | Date and time | Appointments, timestamps |
| State | Predefined set of values | Status values, categories |
| Coordinate | Geographic location | Map locations, addresses |
Choosing the Right Type
Use this decision guide:
- Will users enter this data? Consider input widgets
- Is it a finite set of values? Use State type
- Could values be very long? Use Text instead of String
- Does it represent a location? Use Coordinate
- Does it require decimals? Use Float instead of Integer
Defining Relationships
Relationships connect models together, enabling you to build complex data structures.
One-to-Many
The most common relationship. One parent record relates to many child records.
Example: Customer Orders
Customer (1) ───────> (*) Order
One customer has many orders
Each order belongs to one customer
Implementation:
- Create both models (Customer, Order)
- Add a reference attribute to Order pointing to Customer
- Appivo automatically creates the foreign key
Many-to-Many
Both sides can have multiple related records.
Example: Products and Categories
Product (*) <──────> (*) Category
Products can belong to multiple categories
Categories can contain multiple products
Implementation:
- Create both models
- Add a many-to-many relationship
- Appivo creates a junction table automatically
One-to-One
Each record relates to exactly one record in another model.
Example: User Profile
User (1) ─────────── (1) Profile
Each user has exactly one profile
Each profile belongs to one user
Relationship Best Practices
- Name relationships clearly - Use descriptive names that indicate the relationship
- Consider cascade behavior - What happens when parent records are deleted?
- Add appropriate indexes - Foreign keys are indexed automatically
- Plan navigation - Consider how users will traverse relationships
Validation Rules
Protect data integrity with validation rules on attributes.
Available Validations
| Validation | Description | Applies To |
|---|---|---|
| Required | Must have a value | All types |
| Unique | No duplicates allowed | All types |
| Min Length | Minimum character count | String, Text |
| Max Length | Maximum character count | String, Text |
| Min Value | Minimum number | Integer, Float |
| Max Value | Maximum number | Integer, Float |
| Pattern | Regex matching | String, Text |
Validation Examples
Email Attribute
Attribute: Email
Type: String
Validations:
- Required: true
- Unique: true
- Pattern: ^[^@\s]+@[^@\s]+\.[^@\s]+$
Quantity Attribute
Attribute: Quantity
Type: Integer
Validations:
- Required: true
- Min Value: 0
- Max Value: 10000
Product Code
Attribute: ProductCode
Type: String
Validations:
- Required: true
- Unique: true
- Pattern: ^[A-Z]{3}-[0-9]{4}$
- Max Length: 8
Indexes
Indexes improve query performance for frequently searched fields.
Automatic Indexes
Appivo automatically creates indexes for:
- Primary keys (id field)
- Foreign keys (relationship fields)
- Unique constraints
Custom Indexes
Add custom indexes for:
- Fields used in filters
- Fields used in sorting
- Fields used in search
Index Best Practices
- Index search fields - Any field users search by frequently
- Don't over-index - Each index adds write overhead
- Consider composite indexes - For queries filtering multiple fields
- Monitor query performance - Add indexes where queries are slow
System Fields
Every model automatically includes these system-managed fields:
| Field | Type | Description |
|---|---|---|
| id | UUID | Unique identifier |
| created_at | Date & Time | When record was created |
| updated_at | Date & Time | Last modification time |
| ver | Integer | Version for optimistic locking |
Optimistic Locking
The ver field prevents conflicts when multiple users edit the same record:
- User A loads record (ver: 1)
- User B loads record (ver: 1)
- User A saves changes (ver becomes 2)
- User B tries to save - conflict detected (expected ver: 1, found ver: 2)
- User B must reload and retry
Common Patterns
Reference Data
Create models for lookup values:
Model: Status
Attributes:
- Name (String, required)
- Code (String, required, unique)
- DisplayOrder (Integer)
- Active (Boolean, default: true)
Audit Trail
Track all changes to important data:
Model: AuditLog
Attributes:
- Action (State: CREATE, UPDATE, DELETE)
- ModelName (String)
- RecordId (String)
- Changes (Text) - JSON of old/new values
- User (Reference to User)
- Timestamp (Date & Time)
Soft Delete
Mark records as deleted without removing them:
Model: Customer
Attributes:
- ... (other fields)
- Deleted (Boolean, default: false)
- DeletedAt (Date & Time, optional)
- DeletedBy (Reference to User, optional)
Hierarchical Data
Model tree structures:
Model: Category
Attributes:
- Name (String, required)
- Parent (Reference to Category, optional)
- Path (String) - for quick ancestry lookup
- Level (Integer) - depth in tree
Best Practices
Naming Conventions
- Use singular nouns for model names (Customer, not Customers)
- Use PascalCase for attribute names (FirstName, not first_name)
- Be descriptive but concise
- Avoid abbreviations unless universally understood
Data Normalization
- Store each piece of information in one place only
- Use references instead of duplicating data
- Create separate models for repeating groups
Planning Your Schema
- List your business objects - What entities does your app manage?
- Identify attributes - What information do you store for each?
- Define relationships - How do entities connect?
- Add validations - What rules ensure data quality?
- Plan for growth - Consider future requirements
Performance Considerations
- Keep models focused - don't create mega-models with dozens of fields
- Index fields used in filters and searches
- Use pagination for large data sets
- Consider denormalization for read-heavy operations
Next Steps
- Rules and Actions - Automate based on data changes
- User Interfaces - Display and edit data
- Validation Guide - Advanced validation patterns