Best Practices

Design for Queryability

Structure your tables to make querying easy and predictable:

• Use identifying columns for anything users will pick in dropdowns or reference selectors.

• Prefer flat fields for filterable or sortable data (e.g. status, type, created_at).

• If you’ll be using filters in UI components or automation, keep field names short and consistent (status, owner, is_published).

Use Dropdown or Multiple Choice fields for controlled vocabularies like categories, states, or tags.

---

Normalize for Relationships — But Don’t Overdo It

Ondeva supports table references (like foreign keys), allowing you to link entries across tables. Use them when:

• Data is reused in multiple places (e.g. users, clients, roles)

• You need to enforce consistency across submissions or components

But avoid excessive normalization for operational or analytical data. For example:

• If you're tracking tasks, log entries, or user actions — and frequently need to group, sort, or filter by related values — it’s often better to keep those fields in the same table.

Good rule of thumb: Normalize for reusability and UI clarity. Denormalize for filtering, grouping, and performance.

When to Use Table References

• “One-to-one” or “many-to-one” relationships where a dropdown picker makes UX cleaner

• Data that’s maintained separately (e.g. Teams, Plans, Categories)

When to Flatten into the Same Table

• Metrics, submissions, or logs you’ll run analytics on

• Dynamic data where query speed matters more than data purity

Avoid deep reference chains — they create overhead and slow down performance in large apps.

---

Use ‘One Entry Per User’ for Personal Data

For profile-like data (user preferences, application forms, onboarding data), enable the One Entry Per User setting:

• Prevents duplicate submissions

• Simplifies queries and access control

• Automatically ties data to the logged-in user

Ideal for forms like “My Account”, “Startup Registration”, “Grant Application”, etc.

---

Model State Transitions Explicitly

Use fields like status, phase, or is_active to represent the state of your entries. These fields allow:

• Workflows to branch based on state

• UI to show dynamic labels or badges

• Queries to filter logically (e.g. “only active”, “only pending approval”)

Combine with Workflow steps that update these fields in automation flows.

---

Use Default Values to Streamline Entry Creation

For operational tables (e.g. task tracking, logs, form submissions), set defaults to:

• Reduce user input friction

• Ensure consistency across manual and automated inserts

• Prevent missing or inconsistent data downstream

Example: Set default status = pending, priority = normal, or country = DE.

---

Validate Where It Matters

Field-level validation prevents fragile downstream logic. Use:

• Required fields to avoid nulls

• Regex to ensure structure (e.g. emails, phone numbers)

• Unique per user for IDs, usernames, emails

• Formula validations for business rules (e.g. start_date < end_date)

Don’t over-validate early. Start with must-haves, then layer in business logic over time.

---

Avoid Complex JSON in Text Fields

Ondeva supports complex logic — but don’t overuse Text fields to store structured blobs. Instead:

• Use rich text for formatted content

• Use JSON-compatible structures only when paired with processing logic in workflows

If you need to store complex objects, consider breaking them into related tables or use Create Object + Save Entry via workflows.

---

Tag and Track Metadata When Needed

For audit trails or analytics, add fields like:

• created_at (date)

• created_by (user reference)

• last_updated (date)

• is_deleted (soft delete flag)

These can power:

• Admin interfaces

• Time-based automations

• Conditional access to data

---

Summary

Strong data modeling leads to strong apps. When building with Ondeva:

• Keep schemas clean, normalized, and queryable

• Use built-in settings to simplify access control and validation

• Combine structured tables with workflows to build powerful, self-sustaining systems

Tables aren’t just storage — they’re the living logic of your app.