现已推出具有 MongoDB 兼容性的 Firestore 企业版！
了解详情。
เลือกโครงสร้างข้อมูล
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
โปรดทราบว่าเมื่อจัดโครงสร้างข้อมูลใน Cloud Firestore คุณ
จะมีตัวเลือกต่างๆ ดังนี้
- เอกสาร
- คอลเล็กชันหลายรายการ
- คอลเล็กชันย่อยภายในเอกสาร
พิจารณาข้อดีของแต่ละตัวเลือกที่เกี่ยวข้องกับกรณีการใช้งานของคุณ คำแนะนำนี้จะอธิบายโครงสร้างตัวอย่างบางส่วนสำหรับข้อมูลลำดับชั้น
ข้อมูลที่ซ้อนกันในเอกสาร
คุณซ้อนออบเจ็กต์ที่ซับซ้อน เช่น อาร์เรย์หรือแมป ไว้ในเอกสารได้
- ข้อดี: หากคุณมีรายการข้อมูลแบบคงที่ที่เรียบง่ายซึ่งต้องการเก็บไว้ในเอกสาร การตั้งค่านี้จะทำได้ง่ายและช่วยเพิ่มประสิทธิภาพโครงสร้างข้อมูล
-
ข้อจำกัด:
ตัวเลือกนี้ปรับขนาดได้ไม่ดีเท่าตัวเลือกอื่นๆ
โดยเฉพาะอย่างยิ่งหากข้อมูลของคุณเพิ่มขึ้นเมื่อเวลาผ่านไป เมื่อรายการมีขนาดใหญ่ขึ้นหรือเพิ่มขึ้น เอกสารก็จะใหญ่ขึ้นด้วย ซึ่งอาจทำให้เวลาในการดึงข้อมูลเอกสารช้าลง
- กรณีการใช้งานที่เป็นไปได้มีอะไรบ้าง ตัวอย่างเช่น ในแอปแชท คุณอาจจัดเก็บห้องแชท 3 ห้องที่ผู้ใช้เข้าชมล่าสุดเป็นรายการที่ซ้อนกันในโปรไฟล์ของผู้ใช้
|
- class alovelace
- name :
first : "Ada"
last : "Lovelace"
born : 1815
rooms :
0 : "Software Chat"
1 : "Famous Figures"
2 : "Famous SWEs"
|
คอลเล็กชันย่อย
คุณสร้างคอลเล็กชันภายในเอกสารได้เมื่อมีข้อมูลที่อาจขยาย
ในอนาคต
- ข้อดี: เมื่อรายการเพิ่มขึ้น ขนาดของเอกสารหลักจะไม่เปลี่ยนแปลง นอกจากนี้ คุณยังมีความสามารถในการค้นหาอย่างเต็มรูปแบบในคอลเล็กชันย่อย
และสามารถออก
การค้นหากลุ่มคอลเล็กชันในคอลเล็กชันย่อยได้
-
ข้อจำกัด: คุณลบคอลเล็กชันย่อยได้ยาก
- กรณีการใช้งานที่เป็นไปได้มีอะไรบ้าง ในแอปแชทเดียวกัน เช่น คุณอาจสร้างคอลเล็กชันผู้ใช้หรือข้อความภายในเอกสารห้องแชท
|
- collections_bookmark science
- classซอฟต์แวร์
name : "software chat"
- collections_bookmark
ผู้ใช้
- class
alovelace
first : "Ada"
last : "Lovelace"
- class
sride
first : "Sally"
last : "Ride"`
- class ดาราฟิสิกส์
|
คอลเล็กชันระดับรูท
สร้างคอลเล็กชันที่ระดับรูทของฐานข้อมูลเพื่อจัดระเบียบชุดข้อมูลที่แตกต่างกัน
- ข้อดี: คอลเล็กชันระดับรูทเหมาะสำหรับความสัมพันธ์แบบกลุ่มต่อกลุ่ม
และช่วยให้ค้นหาข้อมูลภายในแต่ละคอลเล็กชันได้อย่างมีประสิทธิภาพ
-
ข้อจำกัด: การรับข้อมูลที่มีลำดับชั้นตามธรรมชาติอาจ
มีความซับซ้อนมากขึ้นเมื่อฐานข้อมูลเติบโตขึ้น
- กรณีการใช้งานที่เป็นไปได้มีอะไรบ้าง ในแอปแชทเดียวกัน
เช่น คุณอาจสร้างคอลเล็กชันหนึ่งสำหรับผู้ใช้ และอีกคอลเล็กชันหนึ่งสำหรับห้องแชทและ
ข้อความ
|
- collections_bookmark
ผู้ใช้
- class alovelace
first : "Ada"
last : "Lovelace"
born : 1815
- class sride
first : "Sally"
last : "Ride"
born : 1951
- collections_bookmark ห้องแชท
- classซอฟต์แวร์
- collections_bookmark
ข้อความ
- class
message1
from : "alovelace"
content : "..."
- class
message2
from : "sride"
content : "..."
|
เนื้อหาของหน้าเว็บนี้ได้รับอนุญาตภายใต้ใบอนุญาตที่ต้องระบุที่มาของครีเอทีฟคอมมอนส์ 4.0 และตัวอย่างโค้ดได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 เว้นแต่จะระบุไว้เป็นอย่างอื่น โปรดดูรายละเอียดที่นโยบายเว็บไซต์ Google Developers Java เป็นเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-08-16 UTC
[null,null,["อัปเดตล่าสุด 2025-08-16 UTC"],[],[],null,["\u003cbr /\u003e\n\nRemember, when you structure your data in Cloud Firestore, you\nhave a few different options:\n\n- Documents\n- Multiple collections\n- Subcollections within documents\n\nConsider the advantages of each option as they\nrelate to your use case. A few example structures for hierarchical data\nare outlined in this guide.\n\n\u003cbr /\u003e\n\nNested data in documents\n\nYou can nest complex objects like arrays or maps within documents.\n\n|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------|\n| - **Advantages:** If you have simple, fixed lists of data that you want to keep within your documents, this is easy to set up and streamlines your data structure. - **Limitations:** This isn't as scalable as other options, especially if your data expands over time. With larger or growing lists, the document also grows, which can lead to slower document retrieval times. - **What's a possible use case?** In a chat app, for example, you might store a user's 3 most recently visited chat rooms as a nested list in their profile. | - class alovelace - name : first : \"Ada\" last : \"Lovelace\" born : 1815 rooms : 0 : \"Software Chat\" 1 : \"Famous Figures\" 2 : \"Famous SWEs\" |\n\nSubcollections\n\nYou can create collections within documents when you have data that might expand\nover time.\n\n|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| - **Advantages:** As your lists grow, the size of the parent document doesn't change. You also get full query capabilities on subcollections, and you can issue [collection group queries](../query-data/queries) across subcollections. - **Limitations:** You can't easily delete subcollections. - **What's a possible use case?** In the same chat app, for example, you might create collections of users or messages within chat room documents. | - collections_bookmark science - class software name : \"software chat\" - collections_bookmark users - class alovelace first : \"Ada\" last : \"Lovelace\" - class sride first : \"Sally\" last : \"Ride\"\\` \u003cbr /\u003e \u003cbr /\u003e - class astrophysics - ... |\n\nRoot-level collections\n\nCreate collections at the root level of your database to organize disparate data\nsets.\n\n|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| - **Advantages:** Root-level collections are good for many-to-many relationships and provide powerful querying within each collection. - **Limitations:** Getting data that is naturally hierarchical might become increasingly complex as your database grows. - **What's a possible use case?** In the same chat app, for example, you might create one collection for users and another for rooms and messages. | - collections_bookmark users - class alovelace first : \"Ada\" last : \"Lovelace\" born : 1815 - class sride first : \"Sally\" last : \"Ride\" born : 1951 - collections_bookmark rooms - class software - collections_bookmark messages - class message1 from : \"alovelace\" content : \"...\" - class message2 from : \"sride\" content : \"...\" |"]]
