ความสัมพันธ์ MongoDB: ฝังหรืออ้างอิง?

ฉันใหม่กับ MongoDB - มาจากพื้นหลังฐานข้อมูลเชิงสัมพันธ์ ฉันต้องการออกแบบโครงสร้างคำถามด้วยความคิดเห็น แต่ไม่ทราบว่าความสัมพันธ์ใดที่จะใช้สำหรับความคิดเห็น: embedหรือreference?

คำถามที่มีความคิดเห็นเช่นstackoverflowจะมีโครงสร้างดังนี้:

Question
    title = 'aaa'
    content = bbb'
    comments = ???

ตอนแรกฉันต้องการใช้ความคิดเห็นที่ฝัง (ฉันคิดว่าembedแนะนำใน MongoDB) เช่นนี้:

Question
    title = 'aaa'
    content = 'bbb'
    comments = [ { content = 'xxx', createdAt = 'yyy'}, 
                 { content = 'xxx', createdAt = 'yyy'}, 
                 { content = 'xxx', createdAt = 'yyy'} ]

ชัดเจน แต่ฉันกังวลเกี่ยวกับกรณีนี้: หากฉันต้องการแก้ไขความคิดเห็นที่ระบุฉันจะได้รับเนื้อหาและคำถามได้อย่างไร ไม่มีที่_idจะให้ฉันค้นหาหรือquestion_refให้ฉันพบคำถาม (ผมมือใหม่ที่ผมไม่ทราบว่ามีวิธีการทำเช่นนี้โดยไม่ต้องใด ๆ_idและquestion_ref.)

ฉันต้องใช้งานหรือrefไม่embed? ถ้าอย่างนั้นฉันต้องสร้างคอลเลคชั่นใหม่สำหรับแสดงความคิดเห็น?

นี่เป็นศิลปะมากกว่าวิทยาศาสตร์ เอกสาร Mongo บน Schemasคือการอ้างอิงที่ดี แต่ที่นี่มีบางสิ่งบางอย่างที่จะต้องพิจารณา:

• ใส่ให้มากที่สุด

  ความสุขของฐานข้อมูลเอกสารคือการกำจัดการเข้าร่วมจำนวนมาก สัญชาตญาณแรกของคุณควรวางไว้ในเอกสารเดียวให้มากที่สุด เนื่องจากเอกสาร MongoDB มีโครงสร้างและเนื่องจากคุณสามารถสืบค้นภายในโครงสร้างนั้นได้อย่างมีประสิทธิภาพ (ซึ่งหมายความว่าคุณสามารถเป็นส่วนหนึ่งของเอกสารที่คุณต้องการได้ดังนั้นขนาดของเอกสารไม่ต้องกังวลมากนัก) ไม่จำเป็นต้องทำให้ข้อมูลเป็นมาตรฐานเหมือนเดิม คุณต้องการใน SQL โดยเฉพาะข้อมูลใด ๆ ที่ไม่เป็นประโยชน์นอกเหนือจากเอกสารหลักควรเป็นส่วนหนึ่งของเอกสารเดียวกัน

• แยกข้อมูลที่สามารถอ้างอิงได้จากหลาย ๆ ที่มาไว้ในคอลเลกชันของตัวเอง

  นี่ไม่ใช่ปัญหา "พื้นที่เก็บข้อมูล" มากนักเนื่องจากเป็นปัญหา "ความสอดคล้องของข้อมูล" หากมีหลายระเบียนที่อ้างถึงข้อมูลเดียวกันมันจะมีประสิทธิภาพมากขึ้นและมีข้อผิดพลาดน้อยลงที่จะอัปเดตระเบียนเดียวและเก็บการอ้างอิงไว้ในที่อื่น ๆ

• ข้อควรพิจารณาเกี่ยวกับขนาดเอกสาร

  MongoDB กำหนดขนาด จำกัด 4MB (16MB พร้อม 1.8) ในเอกสารเดียว ในโลกของข้อมูล GB ฟังดูเล็ก แต่มันก็เป็น 30,000 ทวีตหรือ 250 คำตอบของ Stack Overflow หรือรูปถ่ายวูบวาบ 20 ภาพ ในทางตรงกันข้ามนี่เป็นข้อมูลที่มากกว่าหนึ่งอาจต้องการที่จะนำเสนอในครั้งเดียวบนหน้าเว็บทั่วไป ก่อนอื่นให้พิจารณาสิ่งที่จะทำให้การค้นหาของคุณง่ายขึ้น ในหลายกรณีความกังวลเกี่ยวกับขนาดเอกสารจะเป็นการปรับให้เหมาะสมก่อนเวลาอันควร

• โครงสร้างข้อมูลที่ซับซ้อน:

  MongoDB สามารถจัดเก็บโครงสร้างข้อมูลที่ซ้อนกันโดยพลการ แต่ไม่สามารถค้นหาได้อย่างมีประสิทธิภาพ หากข้อมูลของคุณอยู่ในรูปแบบทรีฟอเรสต์หรือกราฟคุณจำเป็นต้องจัดเก็บแต่ละโหนดและขอบของมันในเอกสารแยกต่างหาก (โปรดทราบว่ามีแหล่งเก็บข้อมูลที่ออกแบบมาโดยเฉพาะสำหรับข้อมูลประเภทนี้ที่ควรพิจารณาด้วย)

  มันยังชี้ให้เห็นว่ามันเป็นไปไม่ได้ที่จะคืนองค์ประกอบย่อยในเอกสาร หากคุณต้องการเลือกและหยิบเอกสารสองสามบิตมันจะง่ายกว่าถ้าจะแยกพวกมันออก

• ความสอดคล้องของข้อมูล

  MongoDB ทำให้การแลกเปลี่ยนระหว่างประสิทธิภาพและความสอดคล้อง กฎคือการเปลี่ยนแปลงในเอกสารเดียวเป็นอะตอมเสมอในขณะที่การปรับปรุงเอกสารหลายรายการไม่ควรถือว่าเป็นอะตอมมิก นอกจากนี้ยังไม่มีวิธี "ล็อค" บันทึกบนเซิร์ฟเวอร์ (คุณสามารถสร้างสิ่งนี้ลงในตรรกะของลูกค้าโดยใช้ตัวอย่างเช่น "ล็อค" ฟิลด์) เมื่อคุณออกแบบสคีมาของคุณให้พิจารณาว่าคุณจะรักษาข้อมูลของคุณให้สอดคล้องกันอย่างไร โดยทั่วไปยิ่งคุณเก็บเอกสารไว้มากเท่าไหร่ก็ยิ่งดีเท่านั้น

สำหรับสิ่งที่คุณกำลังอธิบายฉันจะฝังความคิดเห็นและให้แต่ละ ID ความคิดเห็นด้วย ObjectID ObjectID มีการประทับเวลาที่ฝังอยู่ภายในเพื่อให้คุณสามารถใช้มันแทนที่จะสร้างที่หากคุณต้องการ

โดยทั่วไปการฝังจะดีถ้าคุณมีความสัมพันธ์แบบหนึ่งต่อหนึ่งหรือหนึ่งต่อหลายกลุ่มและการอ้างอิงนั้นดีถ้าคุณมีความสัมพันธ์แบบกลุ่มต่อกลุ่ม

หากฉันต้องการแก้ไขความคิดเห็นที่ระบุวิธีรับเนื้อหาและคำถาม

db.question.find({'comments.content' : 'xxx'})คุณสามารถสอบถามโดยการย่อยเอกสาร:

สิ่งนี้จะส่งคืนเอกสารคำถามทั้งหมด หากต้องการแก้ไขความคิดเห็นที่ระบุคุณต้องค้นหาความคิดเห็นที่ลูกค้าทำการแก้ไขและบันทึกกลับไปที่ฐานข้อมูล

โดยทั่วไปหากเอกสารของคุณมีอาร์เรย์วัตถุคุณจะพบว่าวัตถุย่อยเหล่านั้นจะต้องได้รับการแก้ไขด้านไคลเอนต์

ฉันมาสายนิดหน่อย แต่ก็ยังอยากจะแบ่งปันวิธีการสร้างสคีมาของฉัน

ฉันมี schemas สำหรับทุกสิ่งที่สามารถอธิบายได้ด้วยคำเช่นคุณจะทำมันใน OOP คลาสสิก

เช่น

• คิดเห็น
• บัญชีผู้ใช้
• ผู้ใช้งาน
• โพสต์บล็อก
• ...

ทุกสคีมาสามารถบันทึกเป็นเอกสารหรือเอกสารย่อยดังนั้นฉันจึงประกาศสิ่งนี้สำหรับสคีมาแต่ละรายการ

เอกสาร:

• สามารถใช้เป็นข้อมูลอ้างอิง (เช่นผู้ใช้แสดงความคิดเห็น -> ความคิดเห็นมีการอ้างอิง "โดย" กับผู้ใช้)
• เป็น "รูท" ในแอปพลิเคชันของคุณ (เช่น blogpost -> มีหน้าเกี่ยวกับ blogpost)

เอกสารย่อย:

• สามารถใช้ได้เพียงครั้งเดียว / ไม่เคยมีการอ้างอิง (เช่นความคิดเห็นถูกบันทึกไว้ใน blogpost)
• ไม่มี "รูท" ในแอปพลิเคชันของคุณ (ความคิดเห็นเพิ่งปรากฏในหน้าบล็อกโพสต์ แต่หน้านั้นยังคงเป็นเรื่องของโพสต์บล็อก)

ฉันเจองานนำเสนอเล็ก ๆ นี้ในขณะที่ค้นคว้าคำถามนี้ด้วยตัวเอง ฉันประหลาดใจมากที่มีการจัดวางที่ดีทั้งข้อมูลและการนำเสนอของมัน

http://openmymind.net/Multiple-Collections-Versus-Embedded-Documents

มันสรุป:

ตามกฎทั่วไปหากคุณมี [เอกสารย่อย] จำนวนมากหรือถ้าเอกสารมีขนาดใหญ่ชุดสะสมแยกต่างหากอาจดีที่สุด

เอกสารที่มีขนาดเล็กและ / หรือน้อยกว่านั้นมักจะเหมาะสำหรับการฝัง

ฉันรู้ว่ามันค่อนข้างเก่า แต่ถ้าคุณกำลังมองหาคำตอบสำหรับคำถามของ OP เกี่ยวกับวิธีส่งกลับเฉพาะความคิดเห็นที่ระบุคุณสามารถใช้ตัวดำเนินการ$ (แบบสอบถาม)ดังนี้:

db.question.update({'comments.content': 'xxx'}, {'comments.$': true})

ใช่เราสามารถใช้การอ้างอิงในเอกสารหากต้องการเติมเอกสารอื่นเช่น sql i joins ใน mongo db พวกเขาไม่ได้เข้าร่วมในการแมปเอกสารความสัมพันธ์แบบหนึ่งถึงหลายอันแทนเราสามารถใช้ประชากรเพื่อเติมเต็มสถานการณ์ของเรา ..

var mongoose = require('mongoose')
  , Schema = mongoose.Schema

var personSchema = Schema({
  _id     : Number,
  name    : String,
  age     : Number,
  stories : [{ type: Schema.Types.ObjectId, ref: 'Story' }]
});

var storySchema = Schema({
  _creator : { type: Number, ref: 'Person' },
  title    : String,
  fans     : [{ type: Number, ref: 'Person' }]
});

ประชากรคือกระบวนการแทนที่พา ธ ที่ระบุในเอกสารโดยอัตโนมัติด้วยเอกสารจากคอลเล็กชันอื่น เราอาจเติมเอกสารเดี่ยวเอกสารหลายฉบับวัตถุธรรมดาหลายวัตถุล้วนหรือวัตถุทั้งหมดที่ส่งคืนจากแบบสอบถาม ลองดูตัวอย่าง

ดีกว่าคุณจะได้รับข้อมูลเพิ่มเติมกรุณาเยี่ยมชม: http://mongoosejs.com/docs/populate.html

จริงๆแล้วฉันค่อนข้างสงสัยว่าทำไมไม่มีใครพูดถึงข้อกำหนด UML กฎง่ายๆคือถ้าคุณมีการรวมแล้วคุณควรใช้การอ้างอิง แต่ถ้าเป็นองค์ประกอบแล้วข้อต่อก็จะแข็งและคุณควรใช้เอกสารที่ฝังไว้

และคุณจะเข้าใจได้อย่างรวดเร็วว่าทำไมมันถึงมีเหตุผล หากวัตถุสามารถมีอยู่เป็นอิสระจากผู้ปกครองแล้วคุณจะต้องการเข้าถึงแม้ว่าผู้ปกครองไม่ได้อยู่ เนื่องจากคุณไม่สามารถฝังไว้ในพาเรนต์ที่ไม่มีอยู่ได้คุณต้องทำให้มันอยู่ในโครงสร้างข้อมูลของตัวเอง และหากผู้ปกครองมีอยู่เพียงแค่เชื่อมโยงพวกเขาเข้าด้วยกันโดยการเพิ่มการอ้างอิงของวัตถุในผู้ปกครอง

ไม่รู้จริง ๆ ว่าความแตกต่างระหว่างสองความสัมพันธ์คืออะไร นี่คือลิงค์อธิบายพวกเขา: การ รวมตัวกับองค์ประกอบใน UML

ฉันสร้างคำถามนี้ขึ้นเพื่ออ้างอิงว่าคุณควรใช้อย่างใดอย่างหนึ่ง

http://indie-rok.github.io/embedded-vs-reference-mongo-db

หากฉันต้องการแก้ไขความคิดเห็นที่ระบุฉันจะได้รับเนื้อหาและคำถามได้อย่างไร

หากคุณติดตามจำนวนความคิดเห็นและดัชนีของความคิดเห็นที่คุณต้องการแก้ไขคุณสามารถใช้ตัวดำเนินการ dot ( ตัวอย่างเช่น )

คุณสามารถทำ f.ex

db.questions.update(
    {
        "title": "aaa"       
    }, 
    { 
        "comments.0.contents": "new text"
    }
)

(เป็นอีกวิธีในการแก้ไขความคิดเห็นภายในคำถาม)