2009-07-24 31 views
5

Tôi đang sử dụng những gì có vẻ là một thủ thuật thông thường để tạo một cái nhìn tham gia:Giá trị tối đa cho khóa CouchDB hợp chất là gì?

// a Customer has many Orders; show them together in one view: 
function(doc) { 
    if (doc.Type == "customer") { 
    emit([doc._id, 0], doc); 
    } else if (doc.Type == "order") { 
    emit([doc.customer_id, 1], doc); 
    } 
} 

Tôi biết tôi có thể sử dụng các truy vấn sau đây để có được một đơn customer và tất cả liên quan Order s:

?startkey=["some_customer_id"]&endkey=["some_customer_id", 2] 

Nhưng bây giờ tôi đã gắn truy vấn của mình rất chặt chẽ với mã xem của tôi. Có một giá trị tôi có thể đặt ở nơi tôi đặt "2" của mình để nói rõ hơn, "Tôi muốn mọi thứ được liên kết với Khách hàng này"? Tôi nghĩ rằng tôi đã nhìn thấy

?startkey=["some_customer_id"]&endkey=["some_customer_id", {}] 

Nhưng tôi không chắc chắn rằng {}nhất định để sắp xếp sau mọi thứ khác.

Tín dụng cho cmlenz cho phương thức tham gia.

Tiếp tục làm rõ từ CouchDB wiki page on collation:

Truy vấn startkey=["foo"]&endkey=["foo",{}] sẽ phù hợp với hầu hết các phím mảng với "foo" trong phần tử đầu tiên, chẳng hạn như ["foo","bar"]["foo",["bar","baz"]]. Tuy nhiên nó sẽ không phù hợp ["foo",{"an":"object"}]

Vì vậy {}cuối trong thứ tự sắp xếp, nhưng chắc chắn không phải cuối cùng.

Trả lời

1

Thay vì cố gắng tìm giá trị có thể lớn nhất đối với các yếu tố thứ hai trong chính mảng của bạn, tôi sẽ đề nghị thay vì cố gắng tìm nhất giá trị có thể lớn hơn đầu tiên: ?startkey=["some_customer_id"]&endkey=["some_customer_id\u0000"]&inclusive_end=false.

+0

Lưu ý "bao gồm_hàng" bảo vệ chống lại trường hợp vô lý nơi bạn thực sự có một khóa của biểu mẫu "some_customer_id \ u0000", bởi không bao gồm tài liệu khớp với "khóa kết thúc" trong kết quả. – user359996

0

CouchDB chủ yếu được viết bằng Erlang. Tôi không nghĩ rằng sẽ có giới hạn trên đối với các kích thước chuỗi phức hợp/chuỗi tổng hợp khác với tài nguyên hệ thống (ví dụ: một khóa quá lâu nên nó sử dụng tất cả bộ nhớ có sẵn). Các giới hạn của khả năng mở rộng CouchDB không được biết theo trang CouchDB. Tôi đoán rằng bạn có thể tiếp tục thêm các trường vào một khóa chính phức hợp lớn và điều duy nhất sẽ ngăn bạn là tài nguyên hệ thống hoặc các giới hạn cứng chẳng hạn như kích thước nguyên tối đa trên kiến ​​trúc đích.

Vì CouchDB lưu trữ mọi thứ bằng cách sử dụng JSON, nó có thể bị giới hạn ở các giá trị số lớn nhất theo tiêu chuẩn ECMAScript. Tất cả các số trong JavaScript được lưu trữ dưới dạng điểm nổi kép IEEE 754. Tôi tin rằng đôi 64-bit có thể đại diện cho các giá trị từ - 5e-324 đến + 1.7976931348623157e + 308.

+0

Có lẽ tôi chưa đủ rõ ràng. ID cho khách hàng đó không thay đổi giữa giá trị tối thiểu và giá trị tối đa. CouchDB, tuy nhiên, cho phép các phím ghép. Nó đặt hàng đầu tiên bởi mục nhập đầu tiên (không đổi ở đây và bằng "some_customer_id"), sau đó là thứ hai (null cho khóa bắt đầu, 2 hoặc {} cho khóa kết thúc), v.v. Tôi tự hỏi liệu (và tại sao) {} là giá trị tối đa có thể cho một khóa trong thứ tự của CouchDB. –

+0

Tôi nghĩ rằng vấn đề nằm trong tiêu đề câu hỏi của tôi - Tôi sẽ đổi tên để rõ ràng. –

+0

Ồ, tôi không thấy bạn đang nói về các phím tổng hợp. Dường như có rất ít hạn chế trên CouchDB tôi nghi ngờ có một giới hạn cứng về kích thước của bộ tuple cho khóa tổng hợp. Tôi tin rằng tài nguyên hệ thống sẽ được thử nghiệm cho một số hoạt động db nếu bạn đã tạo một bảng với hàng nghìn trường và hàng trăm trường như một phần của chỉ mục tổng hợp. –

0

Có vẻ như sẽ rất tuyệt khi có một tính năng trong đó endKey có thể được bao gồm thay vì độc quyền.

+0

Trên thực tế, "endkey" được bao gồm theo mặc định. Bạn phải chỉ định "endkey_inclusive = false" để nhận hành vi độc quyền. – user359996

0

này nên làm như lừa:

?startkey=["some_customer_id"]&endkey=["some_customer_id", "\uFFFF"] 

này nên bao gồm bất cứ điều gì mà bắt đầu với một nhân vật ít hơn \ uFFFF (tất cả các ký tự unicode)

+2

Tôi không nghĩ vậy. Bài viết bạn đã liên kết để nói rằng tất cả các chuỗi đều xuất hiện trước tất cả các mảng, lần lượt xuất hiện trước tất cả các dấu gạch ngang. Vì vậy, ["some_customer_id", "\ uFFFF"] là 'less than' ["some_customer_id", {}]. –

+0

làm thế nào về:?key = ["some_customer_id"] & include_docs = true – bogphanny

+0

Đây không phải là truy vấn cơ sở dữ liệu quan hệ. Dấu phẩy không phải là một kết hợp ngầm định. Tất cả các khóa được phát ra cho chế độ xem này là mảng hai phần tử, do đó truy vấn của bạn sẽ không mang lại kết quả nào. – user359996

2

Tôi có hai ý nghĩ.

Sử dụng timestamps

Thay vì sử dụng đơn giản 0 và 1 cho hành vi chiếu của họ, sử dụng dấu thời gian kỷ lục được tạo ra (giả sử họ là một phần của hồ sơ) a la [doc._id, doc.created_at]. Sau đó, bạn có thể truy vấn chế độ xem của mình bằng một khóa khởi đầu của một số ngày đủ sớm (epoch có thể hoạt động) và một khóa kết thúc của "now", ví dụ: date +%s. Đó là phạm vi quan trọng nên luôn luôn bao gồm tất cả mọi thứ, và nó có thêm lợi ích của collating theo ngày, mà có lẽ là những gì bạn muốn anyways.

hay, chỉ cần đừng lo lắng về điều đó

Bạn có thể chỉ index bởi customer_id và không có gì hơn. Điều này sẽ có lợi thế tốt đẹp của việc có thể truy vấn bằng cách sử dụng chỉ key=<customer_id>. Chắc chắn, các hồ sơ sẽ không được đối chiếu khi họ quay lại, nhưng đó có phải là vấn đề cho ứng dụng của bạn không? Trừ khi bạn đang mong đợi tấn hồ sơ trở lại, nó có thể sẽ là tầm thường để chỉ cần nhổ bản ghi khách hàng ra khỏi danh sách khi bạn có dữ liệu được truy xuất bởi ứng dụng của bạn.

Ví dụ trong ruby:

customer_records = records.delete_if { |record| record.type == "customer" }

Anyways, timestamps có lẽ là câu trả lời hấp dẫn hơn đối với trường hợp của bạn.

Các vấn đề liên quan