SQL: Cột khóa chính. Nhân tạo cột "Id" vs "tự nhiên" cột

Question

thể trùng lặp:
Relational database design question - Surrogate-key or Natural-key?

Khi tôi tạo bảng quan hệ có một cám dỗ để chọn cột khóa chính cột mà giá trị là duy nhất . Nhưng với mục đích tối ưu hóa và đồng nhất, tôi tạo cột Id nhân tạo mỗi lần. Nếu có một cột (hoặc cột kết hợp) mà nên là duy nhất tôi tạo ra chỉ số duy nhất cho rằng thay vì đánh dấu chúng như là (composite) cột khóa chính (s).

Thực sự là một thực hành tốt luôn luôn thích cột "Id" nhân tạo + chỉ mục thay vì cột tự nhiên cho khóa chính?

Answer 1

Đây là một chút của một cuộc tranh luận tôn giáo. Sở thích cá nhân của tôi là có các khóa chính tổng hợp hơn là các khóa chính tự nhiên nhưng có các đối số tốt ở cả hai bên. Thực tế, miễn là bạn nhất quán và hợp lý, một trong hai cách tiếp cận có thể hoạt động tốt.

Nếu bạn sử dụng khóa tự nhiên, hai nhược điểm chính là sự hiện diện của các phím tổng hợp và làm thay đổi giá trị khóa chính.Nếu bạn có các khóa chính kết hợp, bạn rõ ràng phải có nhiều cột trong mỗi bảng con. Điều đó có thể trở nên khó sử dụng từ góc độ mô hình dữ liệu khi có nhiều mối quan hệ giữa các thực thể. Nhưng nó cũng có thể gây đau buồn cho những người đang phát triển truy vấn-- thật dễ dàng để tạo các truy vấn sử dụng N-1 của N điều kiện tham gia và nhận được kết quả gần như đúng. Nếu bạn có khóa tự nhiên, bạn chắc chắn sẽ gặp phải tình huống mà giá trị khóa tự nhiên thay đổi và sau đó bạn phải gợn sóng thay đổi đó qua nhiều thực thể khác nhau-- phức tạp hơn nhiều so với thay đổi giá trị duy nhất trong bảng. Mặt khác, nếu bạn sử dụng khóa tổng hợp, bạn đang lãng phí dung lượng bằng cách thêm các cột bổ sung, bổ sung thêm chi phí để duy trì chỉ mục bổ sung và bạn đang tăng nguy cơ bạn sẽ nhận được kết quả trùng lặp về chức năng. Thật dễ dàng để quên tạo một ràng buộc duy nhất trên khóa nghiệp vụ hoặc để thấy rằng có một chỉ mục không duy nhất trên kết hợp và chỉ giả định rằng đó là một chỉ mục duy nhất. Tôi thực sự chỉ bị cắn bởi điều này đặc biệt không một vài ngày trước-- Tôi đã lập chỉ mục chìa khóa tự nhiên tổng hợp (với một chỉ số không duy nhất) thay vì tạo ra một ràng buộc duy nhất. Câm lầm sai lầm nhưng một trong đó là tương đối dễ dàng để thực hiện.

Từ quan điểm viết và đặt tên quy ước, tôi cũng có khuynh hướng thích khóa tổng hợp hơn vì bạn biết khi bạn tham gia các bảng mà khóa chính của A sẽ là A_ID và khóa chính của B là sẽ là B_ID. Việc tự ghi nhiều hơn là cố gắng nhớ rằng khóa chính của A là sự kết hợp giữa A_NAME và A_REVISION_NUMBER và khóa chính của B là B_CODE.

Answer 2

Vâng, đúng vậy. Nếu không có gì khác, một trong những thuộc tính quan trọng nhất của khóa chính nhân tạo là opacity, có nghĩa là khóa nhân tạo không phản ánh bất kỳ thông tin nào ngoài chính nó; nếu bạn sử dụng nội dung hàng tự nhiên cho các khóa, bạn sẽ tiết lộ thông tin đó cho những thứ như giao diện Web, đây chỉ là một ý tưởng khủng khiếp về mọi phương diện của nguyên tắc.

Answer 3

Tùy chọn của tôi là luôn sử dụng khóa nhân tạo.

Đầu tiên là nhất quán. Bất cứ ai làm việc trên ứng dụng của bạn đều biết rằng có một chìa khóa và họ có thể đưa ra các giả định về nó. Điều này giúp dễ hiểu và dễ bảo trì hơn.

Tôi cũng đã thấy các tình huống trong đó khóa tự nhiên (còn gọi là một chuỗi từ hệ thống nhân sự xác định nhân viên) phải thay đổi trong suốt thời gian của ứng dụng. Nếu bạn có một khóa nhân tạo liên kết id tự nhiên với bản ghi nhân viên của bạn thì bạn chỉ phải thay đổi id tự nhiên đó trong một bảng. Tuy nhiên, nếu id tự nhiên đó là khóa chính và bạn đã sao chép nó qua một số bảng khác dưới dạng khóa ngoại, thì bạn có một mớ hỗn độn trên tay.

Answer 4

Theo quan điểm khiêm tốn của tôi, tốt hơn là nên có một Id nhân tạo, nếu tôi hiểu đúng ý nghĩa của bạn về nó. Ví dụ, một số người sẽ sử dụng các giá trị duy nhất đáng kể trong kinh doanh như Id bảng của họ và tôi đã đọc trên MSDN, và ngay cả trong tài liệu chính thức NHibernate rằng một giá trị kinh doanh vô nghĩa duy nhất được ưu tiên hơn (ID nhân tạo) bạn muốn tạo chỉ mục trên giá trị đó để tham khảo trong tương lai. Vì vậy, ngày công ty sẽ thay đổi danh pháp của họ, hệ thống vẫn sẽ hoạt động hoàn hảo.

Answer 5

Tùy thuộc vào các cột tự nhiên của bạn. Nếu chúng nhỏ và đều đặn, thì chúng là những ứng cử viên tốt cho khóa chính.

• nhỏ - nhỏ hơn chìa khóa, các giá trị nhiều hơn bạn có thể nhận được vào một hàng duy nhất, và nhanh hơn lần quét chỉ mục của bạn sẽ được
• đều đặn tăng - sản xuất ít reshuffles chỉ số như bảng phát triển, cải thiện hiệu suất.

Answer 6

Có rất ít hoặc không có sự khác biệt giữa khóa được thực thi thông qua ràng buộc CHÍNH PRIMARY KEY và khóa được thực thi thông qua ràng buộc UNIQUE. Điều quan trọng là bạn thực thi TẤT CẢ các khóa cần thiết từ phối cảnh toàn vẹn dữ liệu. Thông thường, điều đó có nghĩa là ít nhất một khóa "tự nhiên" (chìa khóa được tiếp xúc với người dùng/người tiêu dùng dữ liệu và được sử dụng để xác định sự thật về vũ trụ của bài diễn văn) trên mỗi bảng.

Tùy chọn bạn cũng có thể muốn tạo các khóa "kỹ thuật" để hỗ trợ các tính năng của ứng dụng và cơ sở dữ liệu thay vì người dùng cuối (thường được gọi là khóa thay thế). Đó sẽ là rất nhiều xem xét thứ hai tuy nhiên. Vì lợi ích của sự đơn giản (và rất thường xuyên thực hiện tốt) nó thường có ý nghĩa chỉ để tạo ra chìa khóa thay thế, nơi bạn đã xác định một nhu cầu cụ thể cho họ và không phải trước đây.