iOS仿Twitter项目Firebase JSON数据库结构设计问询

Hey there! Let's break down your database design problem—this is such a common (and important) question when working with Firebase for social apps, so let's get you sorted.

First: Should You Duplicate User Data? #

Short answer: Avoid full duplication, but embrace targeted redundancy. Here's why:

• Full duplication (like storing entire user objects in your follows node) leads to data inconsistency headaches. If a user updates their profile picture or username, you'd have to hunt down every instance of their duplicated data to update it—easy to miss, hard to maintain.
• But no redundancy at all hurts performance. If you only stored a user's UID on each post, you'd have to make an extra database call for every single post in the timeline to fetch the user's display info (name, profile pic). That adds up to slow load times and unnecessary read costs.

The sweet spot: Store only the minimum necessary user data alongside posts (the info you need to display the post without extra calls) and keep the full user profile in a single, dedicated node.

Recommended Flat, Scalable Structure #

Firebase works best with flattened, non-nested structures. Let's split your data into 4 core nodes:

1. users (Core User Profiles) #

Store all user's permanent, full info here, using Firebase's auto-generated UID as the key. No nested posts or follows—keep it clean.

{
  "users": {
    "1SUbzM6rIRTQexrOgJ8BnDBCDWt2": {
      "email": "Test1@test.com",
      "name": "Test1",
      "surname": "Test1",
      "fullname": "Test1 Test1",
      "username": "@test1",
      "ppurl": "www.ppurl.com/ppppp"
    },
    "4vBvO9vURkPneusviRGxKglJ3n32": {
      "email": "Test2@test.com",
      "fullname": "Test2 Test2",
      "name": "Test2",
      "surname": "Test2",
      "username": "@test2",
      "ppurl": "www.ppurl.com/ppppp"
    }
    // ... other users
  }
}

2. posts (All User Posts, with Targeted Redundancy) #

Each post gets a unique ID (use UUIDs or Firebase's childByAutoId), and includes the publisher's UID plus the display data you need for the timeline. Add a timestamp for easy sorting.

{
  "posts": {
    "34E20A52-8E66-4AF7-8DA4-73BDE9185FCB": {
      "postContent": "Bir post daha\n",
      "publisherUid": "4vBvO9vURkPneusviRGxKglJ3n32",
      "publisherUsername": "@test2",
      "publisherFullname": "Test2 Test2",
      "publisherPpurl": "www.ppurl.com/ppppp",
      "timestamp": 1620000000 // Unix timestamp for sorting
    },
    "59798B81-4510-4E63-8050-3AF04698C7B0": {
      "postContent": "3. Postumuz gör better approach",
      "publisherUid": "4vBvO9vURkPneusviRGxKglJ3n32",
      "publisherUsername": "@test2",
      "publisherFullname": "Test2 Test2",
      "publisherPpurl": "www.ppurl.com/ppppp",
      "timestamp": 1620000100
    }
  }
}

3. userFollows & userFollowers (Bidirectional Follow Indexes) #

Instead of nesting follows under users, create two separate nodes to track follow relationships. This makes it easy to:

• Get who a user follows (from userFollows)
• Get who follows a user (from userFollowers)

Use true as the value—we only need to know the relationship exists, not extra data.

{
  "userFollows": {
    "4vBvO9vURkPneusviRGxKglJ3n32": { // Test2's UID
      "5QaOU5Pd05h2M8wExcUteUg6mlJ2": true, // Follows Test3
      "6y0RLGGCw6Zg5RHgPxghKUId9pJ3": true  // Follows Test4
    }
  },
  "userFollowers": {
    "5QaOU5Pd05h2M8wExcUteUg6mlJ2": { // Test3's UID
      "4vBvO9vURkPneusviRGxKglJ3n32": true // Has Test2 as a follower
    }
  }
}

How to Build the Timeline in Swift #

1. Fetch the current user's followed UIDs from userFollows/{currentUserUid}.
2. Query the posts node to get all posts where publisherUid is in the followed UIDs list.
3. Sort the results by timestamp in descending order (newest first), and use pagination (e.g., queryLimited(toLast: 20)) to avoid loading too much data at once.

Handling Data Updates (Redundancy Maintenance) #

When a user updates their username or profile picture:

1. Update their core profile in the users node.
2. Use Firebase's updateChildValues to bulk-update all their posts in the posts node with the new display data. This ensures consistency without manual, error-prone updates.

Why Your Original Structure Caused Issues #

• Nested posts/follows: Loading a user's profile would pull all their posts and follows along with it, wasting bandwidth and memory even if you didn't need that data.
• Full user duplication: Updating a user's info would require updating every instance of their duplicated data in other users' follows nodes—this is unmanageable at scale.

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