Objectid mongodb springboot

Một câu hỏi thường gặp của lập trình viên có kinh nghiệm với SQL mới chuyển sang Mongo là làm thế nào để có thể mô hình được quan hệ 1. nhiều. Có rất nhiều cách để có thể làm được điều này. Trong phần đầu của loạt bài này , chúng ta sẽ cùng nhau tìm hiểu 3 cách cơ bản để có thể làm mô hình quan hệ 1. nhiều

Với rất nhiều người mới học MongoDB, giải pháp duy nhất họ nghĩ đến khi gặp sự cố "One to N" là nhúng 1 mảng tài liệu con vào trong tài liệu gốc của anh ta. Tuy nhiên điều này không đúng sự thật. Bạn có thể nhúng tài liệu trong MongoDB nhưng đây là 1 mẫu xấu. Bạn không nên làm theo

Khi thiết kế lược đồ MongoDB, điều đầu tiên cần quan tâm là định lượng được mối quan hệ. Nghe có vẻ cục bộ so với việc thiết kế lược đồ với SQL. Trong MongoDB, tùy thuộc vào thuộc tính của mối quan hệ "one to many" mà ta có phân ra làm 3 loại khác nhau. "một đến ít", "một đến nhiều", "một đến squillions (rất nhiều)". Với từng loại ta có cách thiết kế lược đồ khác nhau

một đến vài

Một ví dụ của "One to few" là việc bạn mô tả địa chỉ của một người. Trong trường hợp này, bạn hoàn toàn có thể sử dụng công việc nhúng dữ liệu. Ở đây ta sẽ để các địa chỉ dưới dạng mảng nằm trong đối tượng Person

> db.person.findOne()
{
  name: 'Kate Monster',
  ssn: '123-456-7890',
  addresses : [
     { street: '123 Sesame St', city: 'Anytown', cc: 'USA' },
     { street: '123 Avenue Q', city: 'New York', cc: 'USA' }
  ]
}

Ưu điểm của việc nhúng dữ liệu là bạn chỉ cần 1 câu lệnh truy vấn để có thể lấy đầy đủ thông tin chi tiết bên trong tuy nhiên dữ liệu của bạn phụ thuộc vào người đó nên bạn không thể xử lý nó như 1 thực thể độc lập

Ví dụ. Nếu bạn cần lập mô hình một hệ thống quản lý tác vụ. Mỗi người nhận một số lượng nhiệm vụ nhất định. Với cách làm trên khi bạn gặp sự cố truy vấn như. Vui lòng cho biết số lượng nhiệm vụ cần hoàn thành vào ngày mai ?. Giải pháp của bạn sẽ là vào từng người trong hệ thống , kiểm tra từng nhiệm vụ của họ xem có cái nào cần hoàn thành vào ngày mai không , gom hết trả lại. Phức tạp truy vấn phải không. Nào ta cần đến loại thứ 2 rồi

một đến nhiều

Ví dụ. Bạn có 1 sản phẩm như Smartphone thật là có hạn. Nó bao gồm rất nhiều điều kiện linh hoạt bên trong và các liên kết kiên cố này có thể thay thế được. Số linh kiên ở đây bị giới hạn số lượng vài trăm thôi nhé ( vài lần là thành loại khác rồi). Giải pháp cho vấn đề này là đặt một mảng ObjectID của từng liên kết điều kiện trong dữ liệu của sản phẩm. (Trong ví dụ này, tôi sử dụng ObjectID 2 byte vì nó dễ đọc, trong ứng dụng thực tế bạn hoàn toàn có thể sử dụng ObjectID 12 byte)

With each linh kiện đều có một bản dữ liệu riêng

> db.parts.findOne()
{
    _id : ObjectID('AAAA'),
    partno : '123-aff-456',
    name : '#4 grommet',
    qty: 94,
    cost: 0.94,
    price: 3.99
}

Với mỗi sản phẩm sẽ có một mảng ObjectID để tham chiếu đến các linh kiện tạo nên sản phẩm

> db.products.findOne()
{
    name : 'left-handed smoke shifter',
    manufacturer : 'Acme Corp',
    catalog_number: 1234,
    parts : [     // array of references to Part documents
        ObjectID('AAAA'),    
        ObjectID('F17C'),   
        ObjectID('D2AA'),
        // etc
    ]

Để có thể truy vấn dữ liệu từng linh kiện trong một sản phẩm xác định bạn có thể sử dụng cú pháp sau

// lấy thông tin sản phẩm qua catalog_number
> product = db.products.findOne({catalog_number: 1234});
   // Lấy toàn bộ linh kiện trong sản phẩm
> product_parts = db.parts.find({_id: { $in : product.parts } } ).toArray() ;

Để tối ưu hóa truy vấn, bạn cần đặt chỉ mục cho sản phẩm. danh mục_số". At in the system has been index for the "parts". _id", nên không cần phải tối ưu thằng đó nữa

Với loại thứ 2 này, bạn có 2 đối tượng riêng rẽ dễ dàng truy vấn tuy nhiên điều này làm cho việc bạn lấy dữ liệu của anh linh kiện trong một anh sản phẩm chậm hơn một chút. Tất nhiên chẳng bao giờ có giải pháp nào hoàn hảo cả. Thêm vào đó, bạn hoàn toàn có thể xem các sản phẩm thì có nhiều linh kiện giống nhau. Từ đó mối quan hệ "one to Many " thành "Many to Many" rồi

To have kinh nghiệm lập trình Node. js thực tế, hãy tham khảo từ khóa học "Node. js build web site speed cao"

Một đến Squillions

Một ví dụ cho cái cuối cùng của loại này à. Clip. Cái này dành cho những cái gì siêu rác. Ví dụ Ghi nhật ký hệ thống , nơi bạn lưu lại các tin nhắn từ nhiều máy chủ khác nhau. Từng máy chủ tạo ra đủ lượng tin nhắn để kích thước tràn của dữ liệu là 16 MB kể cả khi bạn sử dụng ObjectID. Giải pháp cho vấn đề này là "tham chiếu cha mẹ" (Tạo tham chiếu đến thằng cha). Bạn có một bản dữ liệu cho từng máy chủ, sau đó bạn lưu ObjectJD của máy chủ trên từng tin nhắn

> db.hosts.findOne()
{
    _id : ObjectID('AAAB'),
    name : 'goofy.example.com',
    ipaddr : '127.66.66.66'
}

>db.logmsg.findOne()
{
    time : ISODate("2014-03-28T09:42:41.382Z"),
    message : 'cpu is on fire!',
    host: ObjectID('AAAB')       // Reference to the Host document
}

Làm cách nào để lấy toàn bộ thư từ một máy chủ

// tìm thằng server
> host = db.hosts.findOne({ipaddr : '127.66.66.66'});  // assumes unique index
   // liệt kê 5000 message của thằng server
> last_5k_msg = db.logmsg.find({host: host._id}).sort({time : -1}).limit(5000).toArray()

Tổng kết

Ngay cả ở cấp độ cơ bản, rõ ràng là công việc thiết kế Mongo Schema có nhiều vấn đề cần phải suy nghĩ hơn. Có hai câu hỏi bạn cần trả lời khi thiết kế

• Có cần coi Nhiều kẻ trong "một đến nhiều" là một thực thể hay không ?
• Số lượng của Many là bao nhiêu ?
• Nhúng toàn bộ dữ liệu "Many" vào đối tượng "One"
• Sử dụng mảng ObjectID đại diện cho các tên "Nhiều" trong tên Đối tượng "Một"
• Tạo tham chiếu bằng ObjectID đến thằng "One" trong từng thằng "Many"

Bài viết được lược dịch theo bản gốc. http. //Blog. mongodb. org/post/87200945828/6-rules-of-thumb-for-mongodb-schema-design-part-1