1: Getting Started
      Back to home
      1. Home
      2. 1: Getting Started

      Managing Data with Rayven.io Tables

      A Comprehensive Guide to Primary & Secondary Tables for Efficient Data Flows

      Overview

      Rayven.io uses tables as a fundamental building block for data storage and organization. Tables can be categorized into Primary and Secondary tables. These serve as the central data store for your application, working seamlessly with workflows and UI widgets to create a fully interactive data-driven solution.

      1. Primary Tables

      1.1 Description

      A primary table is the main data structure in Rayven.io for storing your most important records or entities. Each row represents a single primary entity, such as a device, user, product, or asset.

      1.2 Key Features

      • Core Entity Data: Stores essential attributes (e.g., names, IDs, statuses).
      • Unique Identifiers: Typically includes an auto-generated ID or a custom primary key.
      • Reference Points: Other tables and workflows often use the primary table’s ID fields to create relationships or lookup data.

      1.3 Use Cases

      • Device Management: Storing details about IoT devices (name, location, status).
      • User Accounts: Tracking user profiles, settings, roles, or access levels.
      • Product Catalog: Keeping product listings with essential attributes (SKU, price, category).

      2. Secondary Tables

      2.1 Description

      A secondary table expands on the data stored in a primary table, typically representing additional information, historical data, or one-to-many relationships.

      2.2 Key Features

      • Linked to a Primary Table: Contains a reference (foreign key) pointing to the associated record in the primary table.
      • Extended or Historical Data: Ideal for storing logs, readings, events, or transactions that accumulate over time.
      • Keeps Primary Table Clean: Separates fast-growing or detailed data to maintain performance and organization.

      2.3 Use Cases

      • Device Readings: Logging sensor outputs or operational metrics (timestamp, reading value, device ID).
      • Activity Logs: Recording user activity (user ID, action taken, timestamp).
      • Maintenance Schedules: Storing records of upcoming or past maintenance tasks linked to an asset in the primary table.

      3. Relationships Between Primary and Secondary Tables

      3.1 One-to-Many Relationships

      • Primary → Secondary: One record in the primary table can link to many secondary records (e.g., one device with many sensor readings).
      • Foreign Key: The secondary table typically has a column referencing the primary table's ID.

      3.2 Data Integrity

      • Referential Consistency: When deleting or updating a primary record, ensure that associated secondary records are handled appropriately (e.g., archived or deleted).

      4. Workflows and Tables

      4.1 How Workflows Interact with Tables

      1. Reading Data: A workflow step can query or select records from a table to use them as inputs for further processing.
      2. Writing Data: Workflows can insert, update, or delete records in tables based on logic or external data inputs.
      3. Scheduled Operations: Automated tasks (e.g., nightly or hourly) can process data from tables and write aggregate results back to the same or different tables.

      4.2 Typical Workflow Scenarios

      • Data Ingestion: An external system sends device readings to a workflow. The workflow validates and stores the data in a secondary table for historical tracking.
      • Bulk Updates: A scheduled workflow queries a primary table (e.g., “Devices”) and updates status fields based on external conditions (e.g., last communication time).
      • Aggregations: A workflow reads daily logs from a secondary table, calculates sums or averages, and writes the results to a dedicated “aggregated data” secondary table.

      5. UI Widgets and Tables

      5.1 Displaying Data

      • Data Binding: Widgets (tables, charts, forms) can be bound to Rayven.io tables to display real-time or near-real-time data.
      • Filtering & Searching: Widgets can offer user-friendly options to filter table records by different criteria (e.g., device status).

      5.2 User Input & Updates

      • Forms: Users can enter data (e.g., new device details or update an existing record), which is then pushed to the corresponding primary or secondary table.
      • Buttons & Actions: Tied to workflows or direct table operations, allowing for updates, deletes, or batch actions.

      5.3 Two-Way Interactions

      • Real-Time Refresh: After a successful insert/update in a table, the UI can auto-refresh to reflect the latest data.
      • Conditional Views: UI elements can change based on data from the tables (e.g., highlight a device in red if its status is “offline”).

      6. Best Practices

      1. Identify Entities Clearly

        • Use primary tables for core entities (e.g., Devices, Users, Products).
        • Use secondary tables for detail or historical data (e.g., sensor readings, logs, transactions).

      2. Keep Primary Tables Lean

        • Store only essential attributes in primary tables.
        • Offload large or fast-growing data sets (e.g., time-series data) to secondary tables.

      3. Use Naming Conventions

        • Clearly name primary and secondary tables (e.g., Devices vs. DeviceReadings).
        • Makes it easier to trace relationships in workflows and UI bindings.

      4. Manage Relationships Thoughtfully

        • Ensure referential integrity: if a primary record is required for a secondary record, handle deletions with care.
        • Use consistent ID types (e.g., UUIDs) when linking tables.

      5. Leverage Workflows

        • Automate routine tasks (data validation, aggregation, notifications) through workflows.
        • Keep business logic in workflows rather than scattering it across UI elements.

      6. Optimize for Performance

        • When dealing with large data sets, use selective queries and filters in workflows and UI widgets.
        • Archive or purge outdated data in secondary tables when appropriate.

      7. Troubleshooting & FAQs

      7.1 Why is my table not updating in real-time?

      • Check Workflows: Ensure your workflow is triggered properly (event-based or scheduled).
      • UI Binding: Verify that the UI widget is bound to the correct table and set to auto-refresh or manual refresh logic.

      7.2 How do I handle large volumes of time-series data?

      • Store time-series data (e.g., sensor readings) in a secondary table.
      • Consider creating scheduled workflows to archive older data into an “archived readings” table or external cold storage.

      7.3 Can I connect external databases to Rayven.io tables?

      • You can often import or synchronize external data using workflows.
      • Rayven.io tables may also push data to external systems (depending on connector availability).

      8. Summary

      Rayven.io’s primary tables offer a central hub for your core entities, while secondary tables extend or store related and historical data. Both interact seamlessly with workflows to enable automated processing, and with UI widgets to let users view and manipulate data in real time. By carefully designing your schema and leveraging Rayven.io’s workflow engine, you can build scalable, maintainable, and user-friendly data-driven applications.