This is the third article in my series on the importance of developer standards when building no-code or low-code applications. If you missed the first one, you can check it out here, and for the second part, you can review it here. 

In my previous article, I outlined our developer's standard approach to using a Relational Database (SQL), primarily leveraging Supabase as our Database Provider.

In this article, I'll explore developer standards for NoSQL Databases, specifically focusing on our use of Firebase as a NoSQL Database provider. Primary because this is one of the native integrations provided for FlutterFlow.

If you'd like a deeper dive into the differences between Firebase and Supabase, check out our article, "Supabase vs Firebase: Which is Best for Your Project?"

Database Diagram

As previously discussed, a fundamental principle for database design is to always create a Database Diagram. This visul representation acts as a blueprint, ensuring that the database structure aligns with the application's needs. By following this step, we can prevent potential data inconsistencies and inefficiencies in the future.

Common Standards for Naming Conventions

Consistency in naming conventions for tables and columns is key to creating a clear and understandable database schema. Here are some best practices to follow:

• Use clear, descriptive names: Table and column names should indicate the data they store. Avoid using shortened or vague names.
• Avoid abbreviations and acronyms: These can confuse. If you must use them, make sure to document their meaning in your schema documentation.

Documents Databases (NoSQL)

Let's begin with the standards. As mentioned earlier, we're using Firebase as our primary NoSQL database service.

Unlike SQL databases, where Database Normalization and specific Normalization Forms are applied to avoid data redundancy, Document Databases take a different approach. In Document Databases, data can be repeated within a single document, making it more flexible for certain use cases.

Collections

 In Firebase we have Firestore Collections to persist our data using the JSON format. We can follow the following guidelines: 

• The name should clearly indicate the data that it storing and should not use shortened names.
• The name should be in Snake Case in the plural. For example, use  “vehicles”, “users_settings”, and “orders”.
• The names of the fields have to be in Snake Case format (snake_case).
• If it is necessary to store private or sensitive data, such as tokens or API keys, it should be added to a subcollection or a separate collection.
• If a relation needs to be represented, it must be done using "DataTypes". For example, the “User” data type is used to relate a “User” that creates an “Order”.
• If it is needed a field that represents a relation always use the “DataType” name of the field or a name that clearly indicates the information that represents it. For example, use “vehicle” instead of “vehicle_ref” or “created_by” instead of “create_user_ref” or “createUserRef”.

DataTypes

When we need to save complex data into a single field we need to use a DataType to group all related info, a Data Type is JSON:

• The name should clearly indicate the data that is it storing and should not use shortened names.
• The name should be in Camel Case (CamelCase) in singular. For example, use  “Vehicle” instead of “vehicles”.
• The name of the fields that the DataType group must be in Snake Case and can be singular or plural depending on the case. For example, use “history_payments” instead of “HistoryPayment”.
• If the Data Type represents a relationship between two collections its has to contain a minimum of information that can be used in the Visual Layer. For example, use a User Data Type that contains “email”, “name”, “avatar” and the “ref” field that holds the relationship (DocumentReference).
• The field that contains or represents a relation (DocumentReference)  always has to be called "ref", not "user_ref", "vehicle_ref" for example.

A crucial aspect of data type selection is its ability to group related data from different collections. By using appropriate data types, you can avoid making unnecessary queries to retrieve related information, streamlining your data retrieval process and improving UI performance.

However, it's important to note that in some cases, relationships between collections can require additional updates. When modifying the original collection, you may need to update related data types to ensure data consistency and freshness.

Document Database Diagram Example:

You can create your diagrams using tools like:

• draw.io

This guide provides a flexible framework for developing Database Development Standards, rather than a rigid set of rules. Use it as a starting point to define and customize your own standards to meet the unique requirements of your project or organization.