Có một quy ước đặt tên cho MySQL?


162

Đây là cách tôi làm điều đó:

  1. Tên bảng là trường hợp thấp hơn, sử dụng dấu gạch dưới các từ riêng biệt, và là số ít (ví dụ foo, foo_barvv
  2. Tôi thường (không phải luôn luôn) có PK tăng tự động. Tôi sử dụng quy ước sau: tablename_id(ví dụ foo_id, foo_bar_idvv).
  3. Khi một bảng chứa một cột là khóa ngoại, tôi chỉ cần sao chép tên cột của khóa đó từ bất kỳ bảng nào mà nó xuất phát. Ví dụ: giả sử bảng foo_barcó FK foo_id( foo_idPK là ở đâu foo).
  4. Khi xác định FK để thực thi tính toàn vẹn tham chiếu, tôi sử dụng như sau: tablename_fk_columnname(ví dụ: tiếp tục ví dụ 3, nó sẽ như vậy foo_bar_foo_id). Vì đây là kết hợp tên bảng / tên cột, nên nó được đảm bảo là duy nhất trong cơ sở dữ liệu.
  5. Tôi đặt hàng các cột như thế này: PK, FK, sau đó các cột còn lại theo thứ tự bảng chữ cái

Có cách nào tốt hơn, chuẩn hơn để làm điều này?


6
Có sai không khi sử dụng PK tự động chỉ là "id"? Tại sao? Tên của cột chỉ có ý nghĩa trong ngữ cảnh của bảng. Vì vậy, tôi có một "id" trong mỗi bảng và có thể có nhiều id_ <tên_bảng> cho FK.
Zbyszek

3
@Zbyszek Tôi nghĩ lý do đơn giản nhất chống lại điều đó chỉ đơn giản là vì tính nhất quán / đơn giản. Thay vì có id_tableB=> oh không có cột có tên khác id , tính nhất quán của id_tableB=> id_tableBchỉ trông gọn gàng hơn ... hoặc như OP làm điều đó: foo_id=> foo_idchứ không phải foo_id=>id
Don Cheadle

Câu trả lời:


106

Tôi sẽ nói rằng đầu tiên và quan trọng nhất: phải nhất quán.

Tôi nghĩ bạn gần như ở đó với các quy ước mà bạn đã nêu trong câu hỏi của bạn. Một vài ý kiến ​​mặc dù:

Điểm 1 và 2 là tôi nghĩ tốt.

Điểm 3 - đáng buồn là điều này không phải lúc nào cũng có thể. Hãy suy nghĩ về cách bạn sẽ đối phó với một bảng duy nhất foo_barcó các cột foo_idanother_foo_idcả hai đều tham chiếu cột foobảng foo_id. Bạn có thể muốn xem xét làm thế nào để đối phó với điều này. Đây là một chút của một trường hợp góc mặc dù!

Điểm 4 - Tương tự như Điểm 3. Bạn có thể muốn giới thiệu một số ở cuối tên khóa ngoại để phục vụ cho việc có nhiều hơn một cột tham chiếu.

Điểm 5 - Tôi sẽ tránh điều này. Nó cung cấp cho bạn rất ít và sẽ trở nên đau đầu khi bạn muốn thêm hoặc xóa các cột khỏi bảng vào một ngày sau đó.

Một số điểm khác là:

Quy ước đặt tên

Bạn có thể muốn giới thiệu một quy ước đặt tên cho các chỉ mục - đây sẽ là một trợ giúp tuyệt vời cho bất kỳ công việc siêu dữ liệu cơ sở dữ liệu nào mà bạn có thể muốn thực hiện. Ví dụ, bạn có thể chỉ muốn gọi một chỉ mục foo_bar_idx1hoặc foo_idx1- hoàn toàn tùy thuộc vào bạn nhưng đáng để xem xét.

Tên cột số ít và số nhiều

Nó có thể là một ý tưởng tốt để giải quyết vấn đề gai góc của số nhiều so với đơn trong tên cột cũng như tên bảng của bạn. Chủ đề này thường gây ra những cuộc tranh luận lớn trong cộng đồng DB. Tôi sẽ gắn bó với các hình thức số ít cho cả tên bảng và cột. Đó Tôi đã nói rồi.

Điều chính ở đây là tất nhiên sự nhất quán!


Điều gì sẽ tốt hơn điểm 5? Tại sao nó có thể trở thành một cơn đau đầu?
Rasshu

7
Để theo dõi, tôi thấy điều này rất hữu ích cho những người sẽ đến đây sau: launchbylunch.com/posts/2014/Feb/16/sql-naming-conventions/ Lỗi
Enissay 2/2/2016

1
Tôi gặp khó khăn khi tìm một "lược đồ" tốt để đặt tên các bảng của mình chứa các đối tượng của các mô hình bao gồm hai tên (DocumentCh CHƯƠNG, DocumentVersion, DocumentType, v.v.). Ví dụ cho DocumentType tôi có thể đặt tên cho nó documenttypehoặc document_type. Tôi thích cái thứ hai hơn, nhưng hầu hết thời gian tôi có nhiều mối quan hệ và tôi cần một cái bàn trông giống nhưdocument_document_type . Bất kỳ đề nghị làm thế nào để xử lý này?
vựng

@ rsb2097 Re: điểm 5 - Sau khi thêm một cột (vào cuối), đơn hàng có thể trở nên không hợp lệ. Bạn không nên thêm bất kỳ ràng buộc nào yêu cầu sắp xếp lại các cột vì đó là một chi phí không cần thiết.
Will Sheppard

21

Tính nhất quán là chìa khóa cho bất kỳ tiêu chuẩn đặt tên. Miễn là nó hợp lý và nhất quán, bạn có 99% ở đó.

Bản thân tiêu chuẩn có rất nhiều sở thích cá nhân - vì vậy nếu bạn thích tiêu chuẩn của mình, thì hãy chạy theo nó.

Để trả lời câu hỏi của bạn hoàn toàn - không, MySQL không có quy ước / tiêu chuẩn đặt tên ưa thích, do đó, việc tự thực hiện là tốt (và bạn có vẻ hợp lý).



4

Rất may, các nhà phát triển PHP không phải là "Những trường hợp lạc đà" như một số cộng đồng phát triển mà tôi biết.

Quy ước của bạn nghe tốt.

Chỉ cần chúng là một) đơn giản và b) nhất quán - Tôi không thấy bất kỳ vấn đề nào :)

PS: Cá nhân, tôi nghĩ 5) là quá mức ...


2
Khác xa với những người to xác, trường hợp lạc đà thực sự bị nhiều người trong cộng đồng DB cau mày vì một số RDBMS 'không nhạy cảm đến mức họ sẽ lột vỏ (hoặc thay đổi mọi thứ thành chữ hoa) để mọi thứ trở nên thực sự xấu xí nhanh chóng.
mal-wan

@mwan: bạn có thể chỉ định RDBMS nào không? Và tôi là một tay đua lạc đà. Các mũ chỉ phục vụ một mục đích trong lược đồ của tôi, để chỉ ra các bảng tham gia và (trong trường hợp các trường) để chỉ ra các ranh giới từ, sao cho _ có thể chỉ dành riêng cho một othertable_id (tức là tên bảng = othertable và trường trong bảng đó = id ). Ngoài ra, nếu RDBMS khác không phân biệt chữ hoa chữ thường, thì điều gì thực sự quan trọng? Tôi sẽ không bao giờ có phiên bản chữ hoa và chữ thường của cùng một bảng! Ồ, và tôi không thích RDBMS không phân biệt chữ hoa chữ thường - Tôi muốn viết mã nhất quán
Samuel Fullman

7
Tôi thích sự trớ trêu của người dùng MySQL không thích CamelCase và tên của sản phẩm chúng tôi sử dụng: MySQL, được viết bằng CamelCase
DBX12

1
@ DBX12 Để trở thành mô phạm, đó là PascalCase, không phải camelCase, nhưng quan điểm của bạn vẫn đứng vững.
MarredCheese

@MarredCheese Không bao giờ nghĩ về điều đó, nhưng bạn đã đúng. camelCase không nên có bướu khi bắt đầu.
DBX12

1

Trả lời đơn giản: KHÔNG

Chà, ít nhất là một quy ước đặt tên như được khuyến khích bởi Oracle hoặc cộng đồng, tuy nhiên, về cơ bản, bạn phải nhận thức được việc tuân theo các quy tắc và giới hạn cho mã định danh, như được nêu trong tài liệu MySQL: https://dev.mysql.com /doc/refman/8.0/en/identifier.html

Về quy ước đặt tên mà bạn tuân theo, tôi nghĩ nó ổn, chỉ là số 5 hơi không cần thiết, tôi nghĩ rằng hầu hết các công cụ trực quan để quản lý cơ sở dữ liệu đều cung cấp tùy chọn sắp xếp tên cột (tôi sử dụng DBeaver và nó có) nếu purpouse có một bản trình bày trực quan đẹp về bảng của bạn, bạn có thể sử dụng tùy chọn này tôi đề cập.

Theo kinh nghiệm cá nhân, tôi muốn giới thiệu điều này:

  • Sử dụng chữ thường . Điều này gần như đảm bảo khả năng tương tác khi bạn di chuyển cơ sở dữ liệu của mình từ máy chủ này sang máy chủ khác. Đôi khi, lower_case_table_namescấu hình không chính xác và máy chủ của bạn bắt đầu ném lỗi chỉ bằng cách không nhận ra tiêu chuẩn camelCase hoặc PascalCase của bạn (vấn đề độ nhạy trường hợp).
  • Tên ngắn . Đơn giản và rõ ràng. Dễ dàng và nhanh nhất là xác định bảng hoặc cột của bạn, thì tốt hơn. Tin tôi đi, khi bạn thực hiện nhiều truy vấn khác nhau trong một khoảng thời gian ngắn thì tốt hơn hết là bạn nên viết (và đọc) đơn giản.
  • Tránh tiền tố . Trừ khi bạn đang sử dụng cùng một cơ sở dữ liệu cho các bảng của các ứng dụng khác nhau, không sử dụng tiền tố. Điều này chỉ thêm nhiều chi tiết cho các truy vấn của bạn. Có những tình huống khi điều này có thể hữu ích, ví dụ, khi bạn muốn xác định khóa chính và khóa ngoại, thông thường tên bảng được sử dụng làm tiền tố cho các cột id.
  • Sử dụng dấu gạch dưới để phân tách các từ . Nếu bạn vẫn muốn sử dụng nhiều hơn một từ để đặt tên cho bảng, cột, v.v., thì hãy sử dụng dấu gạch dưới để phân tách_the_words , điều này sẽ giúp cho mức độ dễ đọc (mắt và não bị căng thẳng của bạn sẽ cảm ơn bạn).
  • Hãy kiên định . Một khi bạn có tiêu chuẩn của riêng bạn, hãy làm theo nó. Don Tiếtt là người tạo ra các quy tắc và là người đầu tiên phá vỡ chúng, thật đáng xấu hổ.

Và những gì về cách đặt tên "số nhiều vs số ít"? Vâng, đây là hầu hết một tình huống của sở thích cá nhân. Trong trường hợp của tôi, tôi cố gắng sử dụng tên số nhiều cho các bảng vì tôi nghĩ rằng một bảng như là một tập hợp các phần tử hoặc một gói chứa các phần tử, vì vậy một tên số nhiều có ý nghĩa đối với tôi; và tên số ít cho các cột vì tôi thấy các cột là các thuộc tính mô tả số ít cho các thành phần bảng đó.

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 cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.