แนวทางปฏิบัติที่ดีที่สุดของ DyanmoDB ทำให้ชัดเจนว่า:
คุณควรดูแลตารางให้น้อยที่สุดเท่าที่จะทำได้ในแอปพลิเคชั่น DynamoDB แอปพลิเคชันที่ออกแบบมาอย่างดีส่วนใหญ่ต้องการเพียงตารางเดียว
ฉันพบว่ามันน่าขบขันที่ทุกบทช่วยสอนที่ฉันเห็นเกี่ยวกับ DyanmoDB นั้นมีการออกแบบหลายตาราง
แต่สิ่งนี้หมายความว่าในทางปฏิบัติ?
ลองพิจารณาแอปพลิเคชันอย่างง่ายที่มีเอนทิตีหลักสามประการ: ผู้ใช้โครงการและเอกสาร ผู้ใช้เป็นเจ้าของหลายโครงการและโครงการสามารถมีเอกสารหลายฉบับ โดยทั่วไปเราจะต้องค้นหาโครงการสำหรับผู้ใช้และเอกสารสำหรับโครงการ อ่านมากกว่าจำนวนที่เขียนโดยระยะขอบที่สำคัญ
การออกแบบตารางการสอนที่ไร้เดียงสาจะใช้สามตาราง:
Users
Hash key
user-id
Projects
Hash key Global Index
project-id user-id
Documents
Hash key Global Index
document-id project-id
เราสามารถยุบได้ง่ายProjectและDocumentอยู่ในDocumentsตารางเดียว:
Documents
Hash key Sort key Global Index
project-id document-id user-id
แต่ทำไมหยุดอยู่ตรงนั้นล่ะ? ทำไมไม่โต๊ะเดียวที่จะปกครองพวกเขาทั้งหมด? เนื่องจากUserเป็นรากของทุกสิ่ง ...
Users
Hash key Sort key
user-id aspect
--------- ---------
foo user email: foo@bar.com ...
foo project:1 title: "The Foo Project"
foo project:1:document:2 document-id: 2 ...
จากนั้นเราก็จะมีดัชนีทั่วโลกในการพูด, emailเขตข้อมูลสำหรับการค้นหาบันทึกผู้ใช้และอื่น ๆ ในdocument-idเขตข้อมูลสำหรับการค้นหาเอกสารโดยตรง
นั่นเป็นวิธีการทำงานหรือไม่? การโยนข้อมูลประเภทที่แตกต่างกันอย่างรุนแรงนี้ลงในตารางเดียวกันหรือไม่ หรือการออกแบบสองตารางสองเป็นวิธีที่ดีกว่า
การเพิ่มตารางที่สองจะถูกต้อง ณ จุดใด