Có quy ước đặt tên bộ sưu tập trong MongoDB không?

Câu trả lời:

85

Các quy ước chung là:

  • Tên viết thường : điều này tránh các vấn đề phân biệt chữ hoa chữ thường , vì tên bộ sưu tập MongoDB phân biệt chữ hoa chữ thường .
  • Số nhiều : rõ ràng hơn là gắn nhãn một bộ sưu tập của một cái gì đó là số nhiều, ví dụ: "tệp" thay vì "tệp"
  • Không có dấu phân tách từ : Tránh các vấn đề khi những người khác nhau (không chính xác) phân tách các từ (tên người dùng <-> user_name, first_name <-> firstname). Cái này là để tranh luận theo một số người xung quanh đây, nhưng với điều kiện là đối số được tách biệt với tên bộ sưu tập, tôi không nghĩ nó nên như vậy;) Nếu bạn thấy mình cải thiện khả năng đọc cho tên bộ sưu tập của mình bằng cách thêm dấu gạch dưới hoặc camel tên bộ sưu tập có thể quá dài hoặc nên sử dụng các khoảng thời gian thích hợp là tiêu chuẩn để phân loại bộ sưu tập.
  • Ký hiệu dấu chấm cho các bộ sưu tập chi tiết cao hơn : Cung cấp một số dấu hiệu về cách các bộ sưu tập có liên quan. Ví dụ: bạn có thể chắc chắn một cách hợp lý rằng bạn có thể xóa "users.pagevisits" nếu bạn đã xóa "users", miễn là những người thiết kế lược đồ đã làm tốt;)

Ví dụ:

users
pagevisits
users.pagevisits

Các quy ước về tên trường (nên) tuân theo một số logic tương tự mặc dù các quy ước về tên trường là khá phổ biến.

— Remon van Vliet
nguồn
32
Tôi sẽ phải không đồng ý với bạn về toàn bộ điều "không có dấu tách từ", đặc biệt nếu bạn đang sử dụng MongoDB với Python. Dấu gạch dưới thay vì khoảng trắng rất dễ đọc, đây là một trong những phẩm chất mong muốn nhất của mã, lược đồ và những thứ tương tự.
— Noah McIlraith 27/12/12
2
Chủ quan là một điều tuyệt vời;) Nếu bạn thấy mình có tên trường hoặc bộ sưu tập có quá nhiều từ trong đó có dấu gạch dưới cải thiện khả năng đọc mã, bạn có lẽ nên xem xét lại toàn bộ tên. Tất nhiên cho mỗi người của họ. Tôi thấy vấn đề về sự mâu thuẫn có thể xảy ra trong những từ ngữ được tách biệt là một vấn đề lớn hơn nhiều. Không sử dụng trình tách từ là tương đối bất khả tri về ngôn ngữ. Ở nơi bạn thích nhấn mạnh, một nhà phát triển Java có thể sẽ thích ngụy trang hơn và điều đó trở nên lộn xộn khi vội vàng.
— Remon van Vliet
7
Số ít thay vì số nhiều, ngược lại nó ánh xạ tới các Đối tượng như Pojos ở Số nhiều và bạn kết thúc với một lớp Người dùng! chứ không phải là lớp Người dùng
— ricardoespsanto
4
@Ricky Tôi cho là vậy. Câu trả lời mà bạn đang đề cập đến là trộn lẫn các khái niệm giống nhau ở đây. Đặt tên cho thực thể so với đặt tên cho bộ sưu tập. Không ai sử dụng "Khách hàng" làm tên thực thể như tác giả của câu trả lời đó đề xuất mặc dù họ có thể sử dụng KHÁCH HÀNG làm tên bảng SQL. Như bạn nói đó là một cuộc thảo luận cực kỳ chủ quan. Miễn là nó nhất quán trên toàn bộ cơ sở mã thì sẽ không có quá nhiều vấn đề.
— Remon van Vliet
3
Tôi nghĩ số ít có ý nghĩa hơn, vì số nhiều được ngụ ý. Và như @Ricky nói, tiêu chuẩn này đã được thiết lập trong sql từ lâu. stackoverflow.com/questions/338156
— steampowered
32

Chỉ cần tránh sử dụng dấu gạch ngang trong tên bộ sưu tập của bạn.

Và đó chỉ bởi vì, nếu bạn sử dụng cli của hai lệnh gọi dưới đây, thì lệnh đầu tiên là JavaScript không hợp lệ:

db.foo-bar.find();
db['foo-bar'].find();

Cả hai đều giống hệt nhau về chức năng, nhưng thứ hai hơi khó chịu hơn khi nhập và không hoàn thành tab.

Ngoài ra, lợi thế / bất lợi phụ thuộc vào việc bạn sử dụng các bộ sưu tập. Nhất quán quan trọng hơn quy ước bạn chọn.

— AD7six
nguồn
Có :hợp lệ cho tên bộ sưu tập không gian tên, như trong foo:barkhông?
— raffian
bất cứ điều gì đều hợp lệ cho mongo. ví dụ db["\n"].insert({});- không có lỗi. Những điều cần quan tâm chủ yếu là sự thuận tiện với trình điều khiển bạn đang sử dụng.
— AD7six
1
Điều này đã thay đổi trong 2.2 trên windows: / \. "* <>: |? không còn hợp lệ - xem docs.mongodb.org/manual/release-notes/2.2/…
— toong
5
@toong, đó là tên cơ sở dữ liệu , không phải bộ sưu tập.
— BorisOkunskiy
19

Trong http://docs.mongodb.org/manual/reference/limits/ , hướng dẫn sử dụng quy định rằng tên bộ sưu tập phải bắt đầu bằng dấu gạch dưới ('_') hoặc ký tự chữ cái và không được:

  • chứa $.
  • là một chuỗi rỗng (ví dụ: "").
  • chứa ký tự null.
  • bắt đầu với hệ thống. tiếp đầu ngữ. (Dành riêng cho việc sử dụng nội bộ.)

Tuy nhiên, nếu bạn tuân theo quy tắc và tạo một bộ sưu tập với '_' là chữ cái đầu, chẳng hạn như "_TWII", bạn sẽ gặp rắc rối khi muốn bỏ bộ sưu tập. Hãy xem bài kiểm tra bên dưới và cách khắc phục. Bộ sưu tập '_TWII' đã được tạo trong db 'people'.

> show collections
_TWII
employees
system.indexes
> db._TWII.drop()
2015-02-19T16:34:56.738-0800 TypeError: Cannot call method 'drop' of undefined

> use admin
switched to db admin

> db.runCommand({renameCollection:"people._TWII",to:"people.TWII"})
{ "ok" : 1 }
> use people
switched to db people
> show collections
TWII
employees
system.indexes
> db.TWII.drop()
true
> show collections
employees
system.indexes
>

Một đoạn ngắn để xóa bộ sưu tập _TWII khi ở dưới db 'people':

> db.createCollection('^TWII')
{ "ok" : 1 }
> db.getCollection('^TWII').drop()
true
— Daniel C. Deng
nguồn
0

MongoDB có một số quy ước đặt tên. Một trong số đó là tên cơ sở dữ liệu không phân biệt chữ hoa chữ thường. Ngoài ra, mongo sẽ đặt tên bộ sưu tập của bạn ở số nhiều nếu không được chỉ định. "khóa học" sẽ trở thành "các khóa học".

Vì tên cơ sở dữ liệu không phân biệt chữ hoa chữ thường trong MongoDB, tên cơ sở dữ liệu không thể chỉ khác nhau theo trường hợp của các ký tự.

Vì chúng, hãy cố gắng đặt tên cho tất cả bộ sưu tập của bạn bằng chữ thường và không có ký tự đặc biệt. Bạn sẽ tránh được nhiều lỗi - đặc biệt nếu bạn sử dụng Mongoose. Mongoose có một số đặc điểm truy vấn kỳ lạ.

Ví dụ: nếu bạn có một bộ sưu tập có tên "các khóa học", đây là cách bạn cần cấu trúc mô hình của mình:

const LawModel = mongoose.model(
  "course",
  new mongoose.Schema({
    id: String,
    name: String,

  }),

Lưu ý "khóa học" là số ít như thế nào? Mongoose sẽ ở số nhiều, do đó tại sao bạn có thể thấy một mảng trống "[]". -> bạn đang truy vấn một bộ sưu tập chưa tồn tại.

Hãy thử đổi tên và điều chỉnh mô hình của bạn.

— Dom355
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.