Tại sao các khóa chính có tên của riêng họ?


19

Từ quan điểm toán học, cho rằng một bảng có nhiều nhất một khóa chính, dường như đó là một quyết định thiết kế thiển cận để tham chiếu các khóa chính bằng một số tên tùy ý thay vì thuộc tính bảng đơn giản.

Do đó, để thay đổi một khóa chính từ không bao gồm thành cụm hoặc ngược lại, trước tiên bạn phải tìm kiếm tên của nó, hơn là thả nó và cuối cùng lấy lại nó.

Có một số lợi thế trong việc sử dụng các tên tùy ý mà tôi không thấy hoặc có DBMS không sử dụng các tên tùy ý cho các khóa chính không?

Chỉnh sửa 2011 / 02-22 (22/02/2011 cho những ai không muốn sắp xếp ngày ở đó):

Hãy để tôi hiển thị hàm, trong đó bạn có thể lấy được tên của khóa chính từ tên bảng của nó (sử dụng các bảng hệ thống sybase sql-sever aka đầu tiên):

create function dbo.get_pk (@tablename sysname)
returns sysname
as
begin
    return (select k.name
    from sysobjects o 
        join sysobjects k   on k.parent_obj = o.id 
    where o.name = @tablename
    and o.type = 'U'
    and k.type = 'k')
end
go

Vì gbn tuyên bố không có người thực sự thích tên được tạo, khi bạn không cung cấp tên rõ ràng:

create table example_table (
    id int primary key
)

select dbo.get_pk('example_table')  

Tôi vừa có

PK__example___3213E83F527E2E1D

Nhưng tại sao tên trong sysobjects là duy nhất. Sẽ hoàn toàn ổn khi sử dụng chính xác cùng tên cho bảng và khóa chính của nó.

Làm theo cách đó, chúng tôi không cần thiết lập các quy ước đặt tên, có thể vô tình bị vi phạm.

Bây giờ câu trả lời cho Marian:

  1. Tôi chỉ sử dụng nhiệm vụ thay đổi một cụm thành khóa chính không bao gồm như một ví dụ mà tôi cần biết tên thực tế của pk để có thể thả nó.
  2. Những thứ không cần phải có tên riêng, nó là đủ nếu chúng có thể dễ dàng được ký hiệu duy nhất. Đó là cơ sở của sự trừu tượng. Lập trình hướng đối tượng đi theo cách này. Bạn không cần sử dụng các tên khác nhau cho các thuộc tính tương tự của các lớp khác nhau.
  3. Nó là tùy ý, bởi vì nó là một thuộc tính của một bảng. Tên của bảng là tất cả những gì bạn cần biết nếu bạn muốn sử dụng nó.

Câu trả lời:


17

Các khóa chính (và các ràng buộc duy nhất khác) được triển khai dưới dạng các chỉ mục và được xử lý theo cùng một cách - không có nghĩa gì theo quan điểm của lập trình viên để có các đường dẫn mã riêng cho PK và chỉ mục (nó sẽ tăng gấp đôi tiềm năng cho lỗi).

Khác với việc được gọi bằng khóa ngoại, PK chỉ là một ràng buộc duy nhất được thực hiện như một chỉ mục, do đó, việc thay đổi các thuộc tính của PK cũng giống như thay đổi các thuộc tính của bất kỳ chỉ mục nào khác. Ngoài ra có một tên rõ ràng có nghĩa là chúng có thể được tham chiếu trong các gợi ý truy vấn như bất kỳ chỉ mục nào khác.


1
Vâng, điều đó có nghĩa là cột nào được sử dụng làm PK có thể được thay đổi. Vì vậy, đối với sách, bạn có thể sử dụng ISBN làm PK (mà bạn muốn gọi là ISBN để rõ ràng), nhưng sau đó, trong quá trình phát triển, bạn có thể quyết định rằng bạn cũng có thể lưu trữ sách cũ, nghĩa là bạn sẽ muốn một bản ghi riêng (ví dụ ngoài đỉnh đầu của tôi). Vì vậy, bạn sẽ cần thay đổi trường PK thành một số ID duy nhất.
Nathan MacInnes

1
Tôi thích cụm từ: "PK là một ràng buộc sử dụng một chỉ mục" . Đôi khi hai ràng buộc (PK và FK - hoặc 2 FK) có thể sử dụng cùng một chỉ mục.
ypercubeᵀᴹ

@ypercube Tôi thích "PK là một ràng buộc sử dụng chỉ mục trong 99,99% cơ sở dữ liệu trong thế giới thực" , điều đó tất nhiên có nghĩa là có thể có ràng buộc PK mà không có chỉ mục, nhưng không ai có kế hoạch sử dụng cơ sở dữ liệu đó trong thế giới thực sẽ từng thực hiện nó vì lý do hiệu suất.
Pacerier

6

Không chắc chắn tôi hoàn toàn hiểu câu hỏi.

Nếu bạn có một chỉ mục trên một bảng và bạn muốn / cần thay đổi chỉ mục, bạn cũng không cần phải thay đổi nó theo tên của nó chứ? Tôi cho rằng bạn có thể tra cứu objectID cho chỉ mục và thực hiện cập nhật theo cách đó, nhưng tên có xu hướng giúp mọi người hiểu một cách logic về đối tượng mà họ đang làm việc.

Vì vậy, có lẽ câu trả lời là nếu bạn có một quy ước đặt tên mạnh đang được sử dụng (ví dụ, tên_PK cho Khóa chính), thì bạn có thể dễ dàng xác định rằng bạn đang làm việc với khóa chính của bảng.

Tôi cho rằng điều tương tự cũng có thể được nói để xác định mối quan hệ FK. Tôi nghĩ rằng việc sử dụng tên được thực hiện để giải thích logic, vì bản thân các đối tượng đều có các ID đối tượng riêng biệt.


5

Tôi muốn nói rằng đó là một chi tiết thực hiện cho khả năng đọc của con người.

Tên Hạn chế là không bắt buộc (trong SQL Server ít nhất), nhưng tôi muốn có PK_MyTablecho MyTablechứ không phải làPK_MyTabl___16feb6d8a


3

Trong lịch sử, Khóa chính và Khóa duy nhất đều được gọi là Khóa ứng viên được giảng dạy bởi Christopher J. Date.

Khóa Ứng viên là một chỉ mục duy nhất và có thể phát cuộn chính. Do đó, tất cả các Khóa Ứng viên là Khóa duy nhất. Khóa chính đơn giản là sự chỉ định của một trong các Khóa Ứng viên là cách ưa thích để truy cập dữ liệu bảng.

Theo cách này, tên PRIMARY KEY là tên tùy ý của khóa ứng viên ưa thích được đính kèm dưới dạng một thuộc tính bảng. Chỉ có thể có một Khóa chính.

Trong thực tế, việc tạo khóa Ứng viên có tên chỉ nên đủ.

Để thay đổi một chỉ mục từ cụm thành không bao gồm và trở lại sẽ chỉ là một bài tập tìm kiếm KHÓA CHÍNH, nhiều nhất là 1 theo định nghĩa. Tôi đoán bạn có thể nói rằng có một định nghĩa CHÍNH CHÍNH về cơ bản là một cảm giác hoài cổ cho những người theo chủ nghĩa cơ sở dữ liệu. Cảm giác về độ tinh khiết của cơ sở dữ liệu nên đã gọi các khóa duy nhất bằng các từ khóa CANDIDATE KEY thay vì các từ thực tế UNIQUE KEY.

Nhấn vào đây để xem Định nghĩa về Khóa Ứng viên và nhận xét của CJDate về nó


1

Không có gì để nói rằng khóa chính sẽ đại diện cho đối tượng bảng. Đối tượng bảng là chỉ mục được nhóm, không phải là khóa chính. Không có gì nói rằng khóa chính phải giống với chỉ mục được nhóm. Thường là vậy, nhưng nó không phải như vậy. Khóa chính có thể dễ dàng đủ được thực thi bởi một chỉ mục không được nhóm.

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.