แนะนำ Firestore เบื้องต้น (ตอน 2 Structuring data)

ขอบคุณแหล่งข้อมูล: cloud.google.com

จำไว้ว่าเมื่อคุณออกแบบโครงสร้างข้อมูลใน Firestore คุณมีตัวเลือกแค่ :

• Documents
• Multiple Collections
• Subcollections ใน documents

พิจารณาข้อดีของแต่ละอย่างดูว่ามันเหมาะสมหรือเข้ากันกับโปรเจคของคุณหรือไม่ ลองมาดูตัวอย่างสัก 2-3 ตัวอย่างกัน

Nested data ใน documents

คุณสามารถ nest complex objects เหมือน array หรือ maps ใน documents ได้

ข้อดี: ถ้าข้อมูลคุณเรียบง่าย (ไม่ซับซ้อน) คงที่ คุณควรเก็บไว้ใน documents เพราะมันง่ายในการ set up และมีโครงสร้างที่คล่องตัว

ข้อจำกัด: มันไม่สามารถปรับขนาดได้ (scalable) เหมือน options อื่นๆ ยิ่งข้อมูลคุณมีการขยายออกไปมันจะยิ่งทำให้ document โตขึ้น และทำให้เกิดความช้าในการคืนข้อมูล

กรณีการใช้งานที่เป็นไปได้: ใช้ใน app แชท ยกตัวอย่างเช่น คุณอาจะเก็บ users 3 คนล่าสุดที่เข้ามาในห้องแชทเป็น nested list ใน profile

Subcollections

คุณสามารถสร้าง collections ใน documents ได้ เมื่อคุณมีข้อมูลที่อาจโตขึ้นเมื่อเวลาผ่านไป

ข้อดี: เมื่อข้อมูลคุณโตขึ้น ขนาดของ parent document จะไม่เปลี่ยนแปลง คุณยังสามารถ query subcollections ได้เต็มความสามารถ และคุณสามารถ queries ข้าม collection group อื่นได้

ข้อจำกัด: ลบ subcollections มันไม่ง่ายเท่าไหร่

กรณีการใช้งานที่เป็นไปได้: ยกตัวอย่างในแอปแชท คุณอาจจะสร้าง collections ของ users หรือ messages ใน document ห้องแชท

Root-level collections

การสร้าง collections ในระดับ root ของ database เพื่อจัดระเบียบ data sets ที่แตกต่างกัน

ข้อดี: Root-level collections นั้นดีสำหรับ many to many relationships และการ query ที่มีประสิทธิภาพในแต่ละ collection

ข้อจำกัด: ถ้ามีการ get data ในรูปแบบ hierarchical อาจกลายเป็นการเพิ่มความซับซ้อน เมื่อฐานข้อมูลคุณโตขึ้น

กรณีการใช้งานที่เป็นไปได้: ยกตัวอย่างในแอปแชท คุณอาจจะสร้าง 1 collection สำหรับ users และสำหรับ rooms และ messages