Quy ước đặt tên MySQL, tên trường có nên bao gồm tên bảng không?

Question

Một người bạn nói với tôi rằng tôi nên bao gồm tên bảng trong tên trường của cùng một bảng, và tôi tự hỏi tại sao? Và nó sẽ như thế này? Ví dụ:

(Table) Users 
(Fields) user_id, username, password, last_login_time 

Tôi thấy rằng tiền tố 'user_' là vô nghĩa vì tôi biết nó đã dành cho người dùng. Nhưng tôi cũng muốn nghe từ bạn. Lưu ý: Tôi đang lập trình bằng php, mysql.

Answer 1

Tôi đồng ý với bạn. Nơi duy nhất tôi bị cám dỗ để đặt tên bảng hoặc một dạng rút ngắn của nó là trên các khóa chính và nước ngoài hoặc nếu tên "tự nhiên" là một từ khóa.

Users: id or user_id, username, password, last_login_time 
Post: id or post_id, user_id, post_date, content 

Tôi thường sử dụng 'id' làm tên trường khóa chính nhưng trong trường hợp này tôi nghĩ user_id và post_id hoàn toàn OK. Lưu ý rằng ngày sau được gọi là 'POST_DATE" vì 'ngày' là một từ khóa.

Ít nhất đó là ước của tôi. Mileage của bạn có thể thay đổi.

Answer 2

Với lĩnh vực chung chung như 'id' và 'tên', nó là tốt để đặt tên bảng trong.

Lý do là nó có thể gây nhầm lẫn khi viết tham gia trên nhiều bảng.

Đó là sở thích cá nhân, thực sự, nhưng đó là lý do đằng sau nó (và tôi luôn luôn làm theo cách này).

Bất kỳ phương pháp nào bạn chọn, hãy đảm bảo phương pháp đó nhất quán trong dự án.

Answer 3

Tôi thấy không có lý do gì để bao gồm tên bảng, đó là không cần thiết. trong các truy vấn bạn có thể tham khảo các lĩnh vực như tên < bảng >. tên < lĩnh vực > anyway (ví dụ. "user.id").

Answer 4

Prefixing tên cột với tên bảng là một cách để đảm bảo tên cột độc đáo , giúp việc tham gia dễ dàng hơn.

Nhưng nó là một thực hành mệt mỏi, đặc biệt là khi chúng ta có tên bảng dài. Nói chung dễ dàng hơn khi chỉ sử dụng bí danh khi thích hợp. Bên cạnh đó, nó không giúp ích gì khi chúng tôi tự tham gia.

Là người sửa đổi dữ liệu, tôi thấy khó có thể nhất quán mọi lúc. Với các cột ID tôi về mặt lý thuyết thích có chỉ ID nhưng tôi thường tìm tôi có bảng với các cột gọi là USER_ID, ORDER_ID vv

Có kịch bản mà nó có thể là một cách tích cực có lợi cho sử dụng một tên cột phổ biến trên nhiều bảng. Ví dụ, khi một mối quan hệ kiểu siêu/kiểu logic được kết xuất chỉ là các bảng con, rất hữu ích để giữ cột của siêu kiểu trên tất cả các bảng kiểu phụ (ví dụ: ITEM_STATUS) thay vì đổi tên nó thành từng phần con -type (ORDER_ITEM_STATUS, INVOICE_ITEM_STATUS, v.v.) Điều này đặc biệt đúng khi chúng là enums với một tập hợp chung của các giá trị.

Answer 5

Cá nhân tôi không thêm tên bảng cho tên trường trong bảng chính nhưng khi sử dụng tên đó làm trường nước ngoài trong bảng khác, tôi sẽ thêm tiền tố cho nó với tên của bảng nguồn. ví dụ. Trường id trên bảng người dùng sẽ được gọi là id, nhưng trên bảng bình luận nó, nơi các bình luận được liên kết với người dùng đã đăng chúng, nó sẽ là user_id.

Điều này tôi đã chọn từ sơ đồ đặt tên của CakePHP và tôi nghĩ nó khá gọn gàng.

Answer 6

Ví dụ, cơ sở dữ liệu của bạn có bảng lưu trữ thông tin về bán hàng và bộ phận nguồn nhân lực, bạn có thể đặt tên cho tất cả các bảng của bạn liên quan đến bộ phận bán hàng như hình dưới đây:

SL_NewLeads SL_Territories SL_TerritoriesManagers

Bạn có thể đặt tên cho tất cả các bảng của bạn liên quan đến bộ phận Nhân sự như sau:

HR_Candidates HR_PremierInstitutes HR_InterviewSchedules

Quy ước đặt tên này đảm bảo rằng tất cả các bảng có liên quan được nhóm lại với nhau khi bạn liệt kê tất cả các bảng theo thứ tự bảng chữ cái. Tuy nhiên, nếu cơ sở dữ liệu của bạn chỉ giao dịch với một nhóm bảng logic, bạn không cần sử dụng quy ước đặt tên này.

Lưu ý rằng đôi khi bạn kết thúc các bảng phân vùng theo chiều dọc thành hai hoặc nhiều bảng, mặc dù các phân vùng này có hiệu quả đại diện cho cùng một thực thể. Trong trường hợp này, hãy thêm một từ xác định tốt nhất phân vùng, với tên đối tượng

Answer 7

Âm thanh như kết luận là: Nếu tên trường là duy nhất trên bảng - tiền tố có tên bảng. Nếu tên trường có khả năng được nhân đôi trong các bảng khác, hãy đặt tên nó là duy nhất.

Tôi đã tìm thấy các tên trường như "img, address, phone, year" vì các bảng khác nhau có thể bao gồm các hình ảnh, địa chỉ, số điện thoại và năm khác nhau.

Answer 8

Thực ra, có một lý do cho loại đặt tên đó, đặc biệt là khi nói đến các trường, bạn có khả năng tham gia. Trong MySQL ít nhất, bạn có thể sử dụng từ khóa USING thay vì ON, sau đó users u JOIN posts p ON p.user_id = u.id trở thành users u JOIN posts p USING(user_id) là IMO rõ ràng hơn.

Về các loại trường khác, bạn có thể hưởng lợi khi chọn *, vì bạn sẽ không phải chỉ định danh sách trường bạn cần và đảm bảo trường nào đến từ bảng nào. Nhưng nói chung việc sử dụng SELECT * không được khuyến khích trên cơ sở hiệu suất và nguồn gốc, vì vậy tôi xem xét tiền tố các trường như vậy với tên bảng là thực hành không tốt, mặc dù nó có thể khác với ứng dụng.

Answer 9

Chúng tôi nên xác định khóa chính có tiền tố tablename.

Chúng tôi nên sử dụng use_id thay thế nếu id và post_id thay vì chỉ id.

Lợi ích: -

1) Dễ dàng đọc được

2) dễ dàng phân biệt trong tham gia truy vấn. Chúng tôi có thể giảm thiểu việc sử dụng bí danh trong truy vấn.

sử dụng bảng: user_id (PK)

bài bảng: post_id (PK) user_id (FK) đây bảng người dùng PK và sau bảng FK là cùng

Theo documentation,

3) Bằng cách này, chúng tôi có thể nhận được lợi ích của TỰ NHIÊN VÀ THAM GIA SỬ DỤNG

Tham gia tự nhiên và tham gia với USING, bao gồm các biến thể tham gia bên ngoài, là được xử lý theo tiêu chuẩn SQL: 2003. Mục đích là để sắp xếp cú pháp và ngữ nghĩa của MySQL đối với NATURAL JOIN và JOIN ... SỬ DỤNG theo SQL: 2003. Tuy nhiên, những thay đổi này trong quá trình tham gia có thể dẫn đến các cột đầu ra khác nhau cho một số kết nối. Ngoài ra, một số truy vấn dường như hoạt động chính xác trong các phiên bản cũ hơn (trước 5.0.12) phải được viết lại để tuân thủ tiêu chuẩn.

Những thay đổi này có lăm khía cạnh chính:

1) Cách mà MySQL xác định các cột kết quả của TỰ NHIÊN hoặc sử dụng tham gia hoạt động (và do đó kết quả của toàn bộ mệnh đề FROM).

2) Mở rộng SELECT * và SELECT tbl_name. * Vào danh sách các cột đã chọn.

3) Độ phân giải của tên cột trong kết nối NATURAL hoặc USING.

4) Chuyển đổi tự nhiên hoặc SỬ DỤNG tham gia vào THAM GIA ... BẬT.

5) Độ phân giải của tên cột trong điều kiện ON của JOIN ... ON.

Ví dụ: -

SELECT * FROM user NATURAL LEFT JOIN post; 
SELECT * FROM user NATURAL JOIN post; 
SELECT * FROM user JOIN post USING (user_id);