Các khóa ngoại có nên trở thành khóa chính của bảng không?

Question

Tôi có một bảng (session_comments) với cấu trúc lĩnh vực sau:

student_id (foreign key to students table) 
session_id (foreign key to sessions table) 
session_subject_ID (foreign key to session_subjects table) 
user_id (foreign key to users table) 
comment_date_time 
comment 

Bây giờ, sự kết hợp của student_id, session_id và session_subject_id sẽ nhận ra duy nhất một lời nhận xét về sinh viên mà cho rằng đối tượng session.

Cho rằng kết hợp chúng là duy nhất, mặc dù chúng là khóa ngoài, có lợi thế nào để tôi tạo cho chúng khóa chính kết hợp cho bảng đó không?

Xin cảm ơn một lần nữa.

Answer 1

1. Đặt cho họ khóa chính sẽ buộc tính duy nhất (trái ngược với ngụ ý).
2. Khóa chính có thể được nhóm lại (tùy thuộc vào dbms) sẽ cải thiện hiệu suất cho một số truy vấn.
3. Nó tiết kiệm không gian thêm một ràng buộc duy nhất mà trong một số DBMS cũng tạo ra một chỉ mục duy nhất.

Cho dù bạn tạo ba khóa chính hay không, bạn vẫn sẽ cần một số ràng buộc duy nhất để đảm bảo rằng học sinh không thể được kết hợp với cùng một phiên và session_subject_id hai lần. Nếu kịch bản đó được cho phép, thì bạn sẽ cần phải mở rộng ràng buộc duy nhất của bạn ra để bao gồm một cột khác.

Không có vấn đề gì bạn chọn, bạn hoàn toàn nên có một số loại ràng buộc duy nhất trên bảng.

Nếu bạn đang tranh luận về việc có nên tạo khóa chính thay thế + ràng buộc duy nhất trên ba cột, tôi có thể nói rằng nó phụ thuộc vào việc bảng này có bảng con hay không. Nếu có, thì việc tham khảo khóa thay thế sẽ dễ dàng hơn và nhỏ hơn. Nếu không, thì IMO, chìa khóa thay thế không thực sự cung cấp cho bạn nhiều và bạn cũng có thể sử dụng ba cột như PK.

Answer 2

Tôi thực sự khuyên bạn nên sử dụng khóa chính do cơ sở dữ liệu bạn chọn tạo ra cho bạn. Chủ yếu là vì nếu bạn thay đổi cấu trúc của bảng đó trong bất kỳ bảo trì nào trong tương lai thì bạn sẽ gặp nguy cơ khóa duy nhất của bạn trở thành không duy nhất. Đó có thể là một vấn đề thực sự khó khăn để phân loại. Cũng có một khóa chính duy nhất làm cho truy vấn bảng nhiều, dễ dàng hơn nhiều.

ID độc đáo cho postgres: http://www.postgresql.org/docs/8.1/interactive/datatype.html#DATATYPE-SERIAL

ID độc đáo cho Mysql: http://dev.mysql.com/doc/refman/5.0/en/example-auto-increment.html

Answer 3

Lý do duy nhất để làm cho họ thành một khóa chính tổng hợp sẽ được thực thi một bình luận cho mỗi sinh viên/khóa/Chủ đề. Giả sử bạn không muốn làm điều đó, tôi sẽ không tạo ra một khóa khác.

Answer 4

No. Phím FOREIGN có thể chứa NULL không được phép trong các khóa CHÍNH. Điều tốt nhất bạn có thể làm là tạo ra một chỉ số UNIQUE từ các cột.

Tạo khóa CHÍNH trên bảng.

Trả lời: Câu hỏi tiếp theo của tôi là: Có khả năng chồng chéo giữa các phím từ 4 bảng không?

Hai sẽ tạo ra chìa khóa hợp cùng 101.010.101: sinh: 1010, phiên: 10, chủ đề: 10, người sử dụng: 1 sinh viên: 10, kỳ họp thứ: 1010, subject: 10, người sử dụng: 1

Tôi chỉ đang chỉ ra rằng bốn cột phải có các miền rõ ràng khác nhau để chồng chéo để giảm bớt khả năng.

Có lẽ tốt nhất để đi với khóa chính thực sự.

Answer 5

Tùy thuộc vào phần còn lại của ứng dụng.
Nếu bạn không có chìa khóa nước ngoài vào bảng bình luận (có vẻ như có thể xảy ra), điều này là tốt.
Nếu bạn cần tham khảo ý kiến ​​từ một bảng khác, bạn nên tạo chỉ mục duy nhất với 3 trường của mình, cộng với khóa chính AutoNumber sẽ phục vụ trong các bảng khác làm khóa ngoại (đơn giản hơn nhiều và rẻ hơn so với 3 lĩnh vực).

Answer 6

Cuộc tranh luận về khóa tự nhiên so với nhân tạo cũ kỹ như bất kỳ triển khai cơ sở dữ liệu nào. Đọc về chuyên gia và con trên wikipedia.

Đối số cho khóa thay thế có thể dễ dàng bị tranh chấp ở cấp độ lý thuyết (ví dụ: đối số với khóa tự nhiên bạn chạy nguy cơ PK của bạn trở thành không duy nhất có thể phản đối bằng câu trả lời - tốt! nó là tốt mà mọi thứ sẽ phá vỡ thay vì có các khóa chính nhân tạo duy nhất với bản ghi trùng lặp cho dữ liệu thực tế).

Một lý lẽ khác là khóa nhân tạo hoặc là dự phòng (có một khóa duy nhất khác trên bảng) hoặc chúng cho phép bạn lưu trữ các bản ghi không duy nhất về bản chất.

Tuy nhiên, việc tìm kiếm các phím tự nhiên tốt đôi khi rất khó để bạn phải chọn một thứ gì đó nhân tạo và cho phép tình huống khi bạn có một người có cùng tên, sinh vào cùng ngày (hoặc không rõ ngày), với một thuộc tính xy khác có cùng giá trị.

Ngoài ra, nó không phải là như vậy rõ ràng những gì là nhân tạo và những gì là tự nhiên. Bạn có thể nói ví dụ rằng SSN là tự nhiên cho dữ liệu của bạn. Mặc dù nó thực sự là số lượng.

Đối với hiệu suất của các mối quan hệ đa khóa - điều này không tệ như bạn nghĩ, hơn nữa - nó phân đoạn các chỉ mục một cách tự nhiên và với các khóa như vậy, bạn thường kết thúc với một cơ sở dữ liệu các truy vấn phổ biến mà không có bất kỳ chỉ mục bổ sung nào.

Nếu bạn xem xét những vấn đề nghiêm trọng và nếu bạn đang cố gắng để xây dựng hệ thống phức tạp, vui lòng đọc một số tài liệu tốt (C.J.Date Giới thiệu về hệ thống cơ sở dữ liệu, hiện trong phiên bản thứ 8 nói đến cái tâm)