Firestore多公司应用数据结构设计咨询（共享客户场景）

Hey there! Let's break down your multi-company Firestore structure problem step by step, considering your requirements and Firestore's core behaviors.

First, Let's Clarify Your Core Requirements #

• Multi-company isolation: Products and orders should be tied to specific companies (ABC, PQR, XYZ)
• Shared customers: Customer data is universal, and a single customer should be able to browse products across all companies
• Migration from single-company setup: You want a structure that doesn’t require a complete rewrite if possible

Analyzing Your Proposed Option 1 (Company Attribute on Documents) #

First, let’s unpack two possible interpretations of your Option 1, plus their pros/cons against Firestore’s rules:

Interpretation 1: Top-level collections with company field #

This is the simpler approach—you keep your existing top-level products, orders collections, but add a company field to every document:

// Example product document in top-level `products` collection
{
  id: "product1",
  company: "ABC",
  name: "Wireless Headphones",
  price: 99.99
}

// Example order document in top-level `orders` collection
{
  id: "order1",
  company: "ABC",
  customerId: "customer1",
  items: ["product1"],
  total: 99.99
}

// Shared `customers` top-level collection
{
  id: "customer1",
  name: "John Doe",
  email: "john@example.com"
}

Firestore Fit & Tradeoffs

✅ Pros:

• Minimal migration effort: Just batch-add the company field to existing products/orders
• Flexible queries: Fetch products across multiple companies easily with db.collection("products").where("company", "in", ["ABC", "PQR"]) (note: Firestore's in operator supports up to 10 values; split queries if you need more)
• Simple security rules: Restrict company admins to only write their company’s data, and let customers read all products
• No nesting limits: Avoids hitting Firestore’s 1MB per-document cap, since products/orders are stored as individual documents

❌ Cons:

• Large collections: If you have thousands of companies/products, your top-level collections will grow big—but Firestore handles large collections well as long as you filter queries correctly
• Limited aggregation: Counting all products for a company requires an aggregation query or a counter (Firestore has built-in aggregation functions now, so this is manageable)

Interpretation 2: Company-specific subcollections #

This is what your option1 = { company: { products: ... }} example hints at—using a top-level companies collection, with products and orders as subcollections under each company document:

// Top-level `companies` collection document
{
  id: "ABC",
  name: "ABC Corp",
  industry: "Electronics"
}

// Subcollection: companies/ABC/products
{
  id: "product1",
  name: "Wireless Headphones",
  price: 99.99
}

// Subcollection: companies/ABC/orders
{
  id: "order1",
  customerId: "customer1",
  items: ["product1"],
  total: 99.99
}

// Shared top-level `customers` collection (same as above)

Firestore Fit & Tradeoffs

✅ Pros:

• Natural data isolation: Each company’s data is physically separated, which is ideal for strict multi-tenant security
• Clean scaling: No single large collection—each company’s products/orders live in their own subcollection
• Easy company-level operations: Aggregate stats (like total orders for ABC) are simpler with subcollection queries

❌ Cons:

• Cross-company queries require collection groups: To let customers browse products across all companies, you’ll need to use Firestore’s collection group queries (db.collectionGroup("products")), which require pre-configured collection group indexes
• Higher migration cost: You’ll need to move existing products/orders into the appropriate company subcollections (use batch writes, limit 500 documents per batch)

Recommended Design Based on Your Scenario #

Let’s pick the best structure for your needs:

Scenario 1: Small number of companies (<=10) & moderate data volume #

Go with Interpretation 1 (top-level collections + company field). It’s the lowest-effort migration, and Firestore handles this setup smoothly.

Key Firestore Tips:

• Create a composite index for company + any fields you regularly filter/sort by (e.g., company + price)
• Use security rules to enforce access:

  rules_version = '2';
  service cloud.firestore {
    match /databases/{database}/documents {
      // Customers can read all products; admins can write their company's products
      match /products/{product} {
        allow read: if request.auth != null && exists(/databases/$(database)/documents/customers/$(request.auth.uid));
        allow write: if request.auth != null && 
                      get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == 'admin' &&
                      get(/databases/$(database)/documents/users/$(request.auth.uid)).data.company == resource.data.company;
      }
      // Customers can read their own orders; admins can read/write their company's orders
      match /orders/{order} {
        allow read: if request.auth != null && 
                      (exists(/databases/$(database)/documents/customers/$(request.auth.uid)) && resource.data.customerId == request.auth.uid ||
                       get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == 'admin' && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.company == resource.data.company);
        allow write: if request.auth != null && 
                      get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == 'admin' &&
                      get(/databases/$(database)/documents/users/$(request.auth.uid)).data.company == resource.data.company;
      }
      // Customers manage their own profiles
      match /customers/{customer} {
        allow read, write: if request.auth != null && request.auth.uid == customer;
      }
    }
  }
  

Scenario 2: Large number of companies (>10) & high data volume #

Go with Interpretation 2 (company subcollections + collection group queries). It scales better and keeps data isolated.

Key Firestore Tips:

• Enable collection group queries for products and orders (Firestore will prompt you to create the required index when you run your first query)
• Use security rules tied to the company path:

  rules_version = '2';
  service cloud.firestore {
    match /databases/{database}/documents {
      // Customers can read all products across companies
      match /companies/{companyId}/products/{product} {
        allow read: if request.auth != null && exists(/databases/$(database)/documents/customers/$(request.auth.uid));
        allow write: if request.auth != null && 
                      get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == 'admin' &&
                      get(/databases/$(database)/documents/users/$(request.auth.uid)).data.company == companyId;
      }
      // Order access rules mirror products
      match /companies/{companyId}/orders/{order} {
        allow read: if request.auth != null && 
                      (exists(/databases/$(database)/documents/customers/$(request.auth.uid)) && resource.data.customerId == request.auth.uid ||
                       get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == 'admin' && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.company == companyId);
        allow write: if request.auth != null && 
                      get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == 'admin' &&
                      get(/databases/$(database)/documents/users/$(request.auth.uid)).data.company == companyId;
      }
      match /customers/{customer} {
        allow read, write: if request.auth != null && request.auth.uid == customer;
      }
    }
  }
  

Final Notes #

• Document size limits: Never store lists of products/orders inside a single document—Firestore caps documents at 1MB, so always use collections/subcollections for list data
• Caching: For customer-facing product browsing, enable Firestore’s offline persistence to reduce query latency
• Migration: If moving from a single company, start with a batch job to tag existing data with the default company ID (for Scenario 1) or move it to the appropriate subcollection (for Scenario 2)

内容的提问来源于stack exchange，提问作者amitdigga