Powered by eniston
  1. Overview
  2. Development
  3. Guidelines for Database Schema/Structure

Guidelines for Database Schema/Structure

Purpose and Scope

This SOP outlines the process for creating and managing database structures in Bubble, FlutterFlow, and Glide for no-code/low-code developers at LowCode Agency. It provides platform-specific guidelines on how to design, implement, and optimize database schemas, ensuring efficiency, scalability, and maintainability of applications.

Definitions

  • Data Types/Entities: Represent core objects in your application (e.g., User, Product).
  • Fields/Attributes: Properties of a data type/entity (e.g., name, price).
  • Relationships: Connections between different data types/entities.
  • Whimsical: Platform used at LCA to map the Database Schema

Responsibilities

  • Developers: Create and modify database structures based on project requirements and best practices.
  • Sales/Discovery Team: Provide initial scope and requirements documentation.
  • Designers: Provide final wireframe as the final source of truth for the database schema generation
  • Project Managers: Oversee the database design process, ensure alignment with project requirements, and manage communications between clients and development teams.

Common Procedure (All Platforms)

1. Initial Documentation Review

  • Carefully review the written scope of work (added in Plutio and Slack by PM/BA)
  • Watch the Discovery Call attached in the scope
  • Review any additional files shared by the client in the scope

2. General Planning

  • Identify core entities in your application (e.g., Users, Products, Orders)
  • Define relationships between entities (One-to-One, One-to-Many, Many-to-Many)
  • Determine fields/attributes for each entity

3. Prerequisites

  • Access to project wireframes and user flow diagrams
  • Access to Whimsical DB structure project which can be shared with others from LCA

Platform-Specific Procedure

Bubble

1. Database Structure

  • Data Types: Create a new data type for each core entity
  • Fields: Add fields to each data type, including simple and complex fields
  • Option Sets: Use for static data that doesn't change frequently

2. Implementation

  • Use CamelCase for naming data types (e.g., UserProfile, ProductCatalog)
  • Use camelCase for field names (e.g., firstName, orderTotal)
  • For relationships:
    • Use 'Reference to another type' for One-to-One relationships
    • Use 'List of' for One-to-Many relationships
    • Create intermediary types for Many-to-Many relationships

3. Performance Optimization

  • Avoid large lists in fields; use searches to retrieve related data
  • Implement pagination for data loading
  • Use custom states for temporary storage to reduce database hits

4. Security

  • Set up privacy rules for each data type
  • Implement field-level security where appropriate

FlutterFlow

1. Database Structure

  • Use Firebase or Supabase as the backend database which should be specified in the scope (unless you suggest or project specifies other wise)
  • Design collections to represent core entities

2. Implementation

  • Analyze Provided Design Documents

    • Review all wireframes and user flow diagrams provided by the design team.
    • Identify key entities (objects) that require data storage.
    • List all data points displayed or collected on each screen.
    • Note relationships between different entities.
    • Identify any possible calculated or derived data fields (this can also be added later, we focus on basic columns at this point).
    • Use document references for One-to-One and One-to-Many relationships
    • Create subcollections or separate collections with cross-references for Many-to-Many relationships

  • Determine and Document Relationships

    1. Review entities and identify relationships between them.
    2. Classify each relationship as One-to-One, One-to-Many, or Many-to-Many.
    3. For each relationship, determine which attributes will connect the entities.
    4. Draw a Database Schema diagram in Whimsical to showcase those relationships, alongside all basic columns and any computed columns you want (please link a sample Whimsical database schema here).

3. Performance Optimization

  • Design queries to be efficient with Firestore's query limitations
  • Use indexing for frequently queried fields

4. Security

  • Implement Firebase Security Rules to control read/write access

Glide

1. Database Structure

  • Use Google Sheets or Glide Tables as the primary data source (unless you suggest or project specifies otherwise)
  • Create separate sheets for each core entity

2. Implementation

  • Name each sheet after its corresponding entity (e.g., "Users", "Products")
  • Add column headers for all attributes in each sheet
  • Use the "Grouped columns" naming convention for clarity
  • For relationships:
    • Use simple references (e.g., foreign key columns) for One-to-One and One-to-Many relationships
    • Create lookup tables for Many-to-Many relationships

3. Data Generation and Import

  • Use Mockaroo to generate sample data
  • Export data as CSV and import into Google Sheets

4. Glide-specific Setup

  • In Glide, import the Google Sheets
  • Adjust column types if necessary in Glide's table settings
  • Use Glide's relation columns to establish relationships between tables

Testing and Iteration (All Platforms)

  • Test the database structure with sample data
  • Simulate load to ensure performance under various conditions
  • Iterate on the design based on test results and user feedback

Documentation and Maintenance (All Platforms)

  • Create a data dictionary documenting all data types/entities and fields
  • Regularly review and clean up unused data
  • Plan for future growth by designing a flexible schema

Examples

References

 

Last updated October 29, 2024
Was this article helpful?
© 2025 LowCode Internal Docs