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
Basic Types
| Type | Description | Use Case |
|---|---|---|
| Text | Up to 255 characters | Names, titles, codes |
| Long Text | Extended text | Descriptions, notes, content |
| Integer | Whole numbers | Quantities, counts, IDs |
| Decimal | Numbers with decimals | Prices, ratings, measurements |
| Boolean | True/false | Flags, toggles, status |
| Date | Date only | Birth dates, due dates |
| DateTime | Date and time | Appointments, timestamps |
| Time | Time only | Schedules, durations |
Specialized Types
| Type | Description | Validation |
|---|---|---|
| Email addresses | Format validation | |
| Phone | Phone numbers | Format with country codes |
| URL | Web addresses | Valid URL format |
| Currency | Monetary values | Decimal with currency symbol |
| Password | Encrypted storage | Never returned in queries |
| File | File attachments | File type and size limits |
| Image | Image uploads | Image type validation, preview |
| Selection | Predefined options | List of allowed values |
Choosing the Right Type
Use this decision guide:
- Will users enter this data? Consider input widgets
- Does it need validation? Use specialized types (Email, Phone, URL)
- Is it a list of options? Use Selection type
- Could values be very long? Use Long Text instead of Text
- Does it store files? Use File or Image types
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 | Text, Long Text |
| Max Length | Maximum character count | Text, Long Text |
| Min Value | Minimum number | Integer, Decimal |
| Max Value | Maximum number | Integer, Decimal |
| Pattern | Regex matching | Text, Email, Phone |
Validation Examples
Email Attribute
Attribute: email
Type: Email
Validations:
- Required: true
- Unique: true
Quantity Attribute
Attribute: quantity
Type: Integer
Validations:
- Required: true
- Min Value: 0
- Max Value: 10000
Product Code
Attribute: product_code
Type: Text
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 | DateTime | When record was created |
| updated_at | DateTime | 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 (Text, required)
- code (Text, required, unique)
- display_order (Integer)
- active (Boolean, default: true)
Audit Trail
Track all changes to important data:
Model: AuditLog
Attributes:
- action (Selection: CREATE, UPDATE, DELETE)
- model_name (Text)
- record_id (Text)
- changes (Long Text) - JSON of old/new values
- user_id (Reference to User)
- timestamp (DateTime)
Soft Delete
Mark records as deleted without removing them:
Model: Customer
Attributes:
- ... (other fields)
- deleted (Boolean, default: false)
- deleted_at (DateTime, optional)
- deleted_by (Reference to User, optional)
Hierarchical Data
Model tree structures:
Model: Category
Attributes:
- name (Text, required)
- parent (Reference to Category, optional)
- path (Text) - for quick ancestry lookup
- level (Integer) - depth in tree
Best Practices
Naming Conventions
- Use singular nouns for model names (Customer, not Customers)
- Use snake_case for attribute names (first_name, not firstName)
- 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