Tôi có thể có nhiều khóa chính trong một bảng không?
Tôi có thể có nhiều khóa chính trong một bảng không?
Câu trả lời:
Bảng có thể có Khóa chính tổng hợp là khóa chính được tạo từ hai hoặc nhiều cột. Ví dụ:
CREATE TABLE userdata (
userid INT,
userdataid INT,
info char(200),
primary key (userid, userdataid)
);
Cập nhật: Đây là một liên kết với một mô tả chi tiết hơn về các khóa chính tổng hợp.
Một bảng có thể có nhiều khóa ứng cử viên. Mỗi khóa ứng cử viên là một cột hoặc một tập hợp các cột là ĐỘC ĐÁO, được ghép lại với nhau và cũng KHÔNG PHẢI. Do đó, việc chỉ định giá trị cho tất cả các cột của bất kỳ khóa ứng cử viên nào là đủ để xác định rằng có một hàng đáp ứng tiêu chí hoặc không có hàng nào cả.
Khóa ứng viên là một khái niệm cơ bản trong mô hình dữ liệu quan hệ.
Đó là thông lệ, nếu có nhiều khóa trong một bảng, để chỉ định một trong các khóa ứng viên làm khóa chính. Đó cũng là cách phổ biến để tạo bất kỳ khóa ngoại nào vào bảng để tham chiếu khóa chính, thay vì bất kỳ khóa ứng cử viên nào khác.
Tôi khuyên bạn nên thực hành những điều này, nhưng không có gì trong mô hình quan hệ yêu cầu chọn khóa chính trong số các khóa ứng cử viên.
Đây là câu trả lời cho cả câu hỏi chính và cho câu hỏi của @ Kalmi về
Điều gì sẽ là điểm có nhiều cột tạo tự động?
Mã này dưới đây có một khóa chính tổng hợp. Một trong những cột của nó được tăng tự động. Điều này sẽ chỉ hoạt động trong MyISAM. InnoDB sẽ tạo ra lỗi " ERROR 1075 (42000): Định nghĩa bảng không chính xác; chỉ có thể có một cột tự động và nó phải được xác định là khóa ".
DROP TABLE IF EXISTS `test`.`animals`;
CREATE TABLE `test`.`animals` (
`grp` char(30) NOT NULL,
`id` mediumint(9) NOT NULL AUTO_INCREMENT,
`name` char(30) NOT NULL,
PRIMARY KEY (`grp`,`id`)
) ENGINE=MyISAM;
INSERT INTO animals (grp,name) VALUES
('mammal','dog'),('mammal','cat'),
('bird','penguin'),('fish','lax'),('mammal','whale'),
('bird','ostrich');
SELECT * FROM animals ORDER BY grp,id;
Which returns:
+--------+----+---------+
| grp | id | name |
+--------+----+---------+
| fish | 1 | lax |
| mammal | 1 | dog |
| mammal | 2 | cat |
| mammal | 3 | whale |
| bird | 1 | penguin |
| bird | 2 | ostrich |
+--------+----+---------+
(Đã nghiên cứu những điều này, rất nhiều)
Các khóa ứng cử viên - Một tổ hợp cột tối thiểu được yêu cầu để xác định duy nhất một hàng của bảng.
Phím ghép - 2 cột trở lên.
Nguồn:
https://en.wikipedia.org/wiki/Superkey
https://en.wikipedia.org/wiki/Candidate_key
https://en.wikipedia.org/wiki/Primary_key
https://en.wikipedia.org / wiki / Compound_key
Theo ghi nhận của những người khác, có thể có các khóa chính nhiều cột. Tuy nhiên, cần lưu ý rằng nếu bạn có một số phụ thuộc chức năng không được giới thiệu bởi một khóa, bạn nên xem xét bình thường hóa mối quan hệ của mình.
Thí dụ:
Person(id, name, email, street, zip_code, area)
Có thể có một sự phụ thuộc chức năng giữa id -> name,email, street, zip_code and area
Nhưng thường a zip_codeđược liên kết với a areavà do đó có một sự phụ thuộc chức năng bên trong giữa zip_code -> area.
Do đó, người ta có thể xem xét tách nó vào một bảng khác:
Person(id, name, email, street, zip_code)
Area(zip_code, name)
Vì vậy, nó phù hợp với hình thức bình thường thứ ba .
Khóa chính là ký hiệu rất đáng tiếc, vì ý nghĩa của "Chính" và mối liên hệ tiềm thức trong hệ quả với Mô hình logic. Vì vậy, tôi tránh sử dụng nó. Thay vào đó, tôi đề cập đến Khóa thay thế của Mô hình vật lý và Khóa tự nhiên của Mô hình logic.
Điều quan trọng là Mô hình logic cho mọi Thực thể phải có ít nhất một bộ "thuộc tính kinh doanh" bao gồm Khóa cho thực thể. Boyce, Codd, Date et al đề cập đến những điều này trong Mô hình quan hệ là Khóa ứng viên. Sau đó, khi chúng tôi xây dựng các bảng cho các Thực thể này, Khóa Ứng viên của chúng trở thành Khóa tự nhiên trong các bảng đó. Chỉ thông qua các Khóa tự nhiên đó, người dùng mới có thể xác định duy nhất các hàng trong bảng; vì các khóa thay thế phải luôn được ẩn khỏi người dùng. Điều này là do Khóa Surrogate không có ý nghĩa kinh doanh.
Tuy nhiên, Mô hình vật lý cho các bảng của chúng tôi trong nhiều trường hợp sẽ không hiệu quả nếu không có Khóa thay thế. Hãy nhớ lại rằng các cột không được bao phủ cho một chỉ mục không được phân cụm chỉ có thể được tìm thấy (nói chung) thông qua Tra cứu khóa vào chỉ mục được phân cụm (bỏ qua các bảng được triển khai dưới dạng heap trong giây lát). Khi (các) Khóa tự nhiên khả dụng của chúng tôi rộng, (1) này sẽ mở rộng chiều rộng của các nút lá không phân cụm của chúng tôi, tăng yêu cầu lưu trữ và truy cập đọc để tìm kiếm và quét chỉ mục không phân cụm đó; và (2) giảm quạt ra khỏi chỉ mục được nhóm của chúng tôi tăng chiều cao chỉ mục và kích thước chỉ mục, một lần nữa tăng yêu cầu đọc và lưu trữ cho các chỉ mục được nhóm của chúng tôi; và (3) tăng yêu cầu bộ đệm cho các chỉ mục được nhóm của chúng tôi. đuổi các chỉ mục và dữ liệu khác ra khỏi bộ đệm.
Đây là nơi một Khóa thay thế nhỏ, được chỉ định cho RDBMS là "Khóa chính" chứng tỏ có lợi. Khi được đặt làm khóa phân cụm, để được sử dụng cho tra cứu khóa vào chỉ mục được phân cụm từ các chỉ mục không được phân cụm và tra cứu khóa ngoại từ các bảng có liên quan, tất cả các nhược điểm này sẽ biến mất. Quạt tăng chỉ số cụm của chúng tôi tăng trở lại để giảm chiều cao và kích thước chỉ mục cụm, giảm tải bộ đệm cho các chỉ mục được nhóm của chúng tôi, giảm đọc khi truy cập dữ liệu thông qua bất kỳ cơ chế nào (cho dù quét chỉ mục, tìm kiếm chỉ mục, tra cứu khóa không phân cụm hoặc tra cứu khóa ngoài) và giảm yêu cầu lưu trữ cho cả các chỉ mục được nhóm và không bao gồm các bảng của chúng tôi.
Lưu ý rằng những lợi ích này chỉ xảy ra khi khóa thay thế vừa nhỏ vừa là khóa phân cụm. Nếu GUID được sử dụng làm khóa phân cụm, tình huống thường sẽ tồi tệ hơn nếu sử dụng Khóa tự nhiên nhỏ nhất có sẵn. Nếu bảng được tổ chức dưới dạng heap thì RowID 8 byte (heap) sẽ được sử dụng để tra cứu khóa, tốt hơn GUID 16 byte nhưng ít hiệu suất hơn số nguyên 4 byte.
Nếu GUID phải được sử dụng do các ràng buộc kinh doanh thì việc tìm kiếm khóa phân cụm tốt hơn là đáng giá. Ví dụ, nếu một số nhận dạng trang web nhỏ và "số thứ tự trang web" 4 byte là khả thi thì thiết kế đó có thể cho hiệu suất tốt hơn GUID là Khóa thay thế.
Nếu hậu quả của một đống (có thể là băm tham gia) làm cho lưu trữ ưu tiên thì chi phí của khóa phân cụm rộng hơn cần được cân bằng trong phân tích đánh đổi.
Xem xét ví dụ này ::
ALTER TABLE Persons
ADD CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)
trong đó tuple " (P_Id, LastName) " yêu cầu một ràng buộc duy nhất và có thể là một LastName Unicode dài cộng với một số nguyên 4 byte, nên (1) sẽ thực thi một cách khai báo ràng buộc này là " THÊM CONSTRAINT pk_PersonID UNIITE NON , LastName) "và (2) khai báo riêng một Khóa Surrogate nhỏ là" Khóa chính "của một chỉ mục được nhóm. Điều đáng chú ý là Anita chỉ có thể muốn thêm LastName vào ràng buộc này để tạo ra một trường được bao phủ, không cần thiết trong một chỉ mục được nhóm vì TẤT CẢ các trường được bao phủ bởi nó.
Khả năng trong SQL Server chỉ định Khóa chính là không bao gồm là một trường hợp lịch sử đáng tiếc, do sự kết hợp của ý nghĩa "khóa tự nhiên hoặc khóa ứng cử viên" (từ Mô hình logic) với nghĩa là "khóa tra cứu trong kho" Mô hình. Tôi hiểu rằng ban đầu, SQL Server SYBASE luôn sử dụng RowID 4 byte, cho dù là một heap hay một chỉ mục được nhóm, như là "khóa tra cứu trong lưu trữ" từ Mô hình vật lý.
Một số người sử dụng thuật ngữ "khóa chính" có nghĩa chính xác là một cột số nguyên có các giá trị được tạo bởi một số cơ chế tự động. Ví dụ: AUTO_INCREMENTtrong MySQL hoặc IDENTITYMicrosoft SQL Server. Bạn đang sử dụng khóa chính theo nghĩa này?
Nếu vậy, câu trả lời phụ thuộc vào thương hiệu cơ sở dữ liệu bạn đang sử dụng. Trong MySQL, bạn không thể làm điều này, bạn gặp lỗi:
mysql> create table foo (
id int primary key auto_increment,
id2 int auto_increment
);
ERROR 1075 (42000): Incorrect table definition;
there can be only one auto column and it must be defined as a key
Trong một số thương hiệu cơ sở dữ liệu khác, bạn có thể xác định nhiều hơn một cột tạo tự động trong một bảng.
Có hai khóa chính cùng một lúc, là không thể. Nhưng (giả sử rằng bạn chưa làm hỏng trường hợp bằng khóa tổng hợp), có thể điều bạn có thể cần là làm cho một thuộc tính duy nhất.
CREATE t1(
c1 int NOT NULL,
c2 int NOT NULL UNIQUE,
...,
PRIMARY KEY (c1)
);
Tuy nhiên, lưu ý rằng trong cơ sở dữ liệu quan hệ, 'siêu khóa' là tập hợp con của các thuộc tính xác định duy nhất một tuple hoặc hàng trong bảng. 'Khóa' là một 'siêu khóa' có thuộc tính bổ sung loại bỏ bất kỳ thuộc tính nào khỏi khóa, làm cho khóa đó không còn là 'siêu khóa' (hay đơn giản là 'khóa' là một siêu khóa tối thiểu). Nếu có nhiều khóa, tất cả chúng đều là khóa ứng cử viên. Chúng tôi chọn một trong các khóa ứng cử viên làm khóa chính. Đó là lý do tại sao nói về nhiều khóa chính cho một mối quan hệ hoặc bảng đang là một xung đột.
Khóa chính là khóa xác định duy nhất một bản ghi và được sử dụng trong tất cả các chỉ mục. Đây là lý do tại sao bạn không thể có nhiều hơn một. Nó cũng thường là khóa được sử dụng để tham gia vào các bảng con nhưng đây không phải là một yêu cầu. Mục đích thực sự của PK là đảm bảo rằng một cái gì đó cho phép bạn xác định duy nhất một bản ghi để thay đổi dữ liệu ảnh hưởng đến bản ghi chính xác và để có thể tạo các chỉ mục.
Tuy nhiên, bạn có thể đặt nhiều trường trong một khóa chính (PK tổng hợp). Điều này sẽ làm cho các phép nối của bạn chậm hơn (đặc biệt nếu chúng là các trường kiểu chuỗi lớn hơn) và các chỉ mục của bạn lớn hơn nhưng nó có thể loại bỏ sự cần thiết phải tham gia trong một số bảng con, theo như hiệu suất và thiết kế, hãy đưa nó vào trường hợp trường hợp cơ sở. Khi bạn làm điều này, mỗi lĩnh vực tự nó không phải là duy nhất, nhưng sự kết hợp của chúng là. Nếu một hoặc nhiều trường trong khóa tổng hợp cũng phải là duy nhất, thì bạn cần một chỉ mục duy nhất trên đó. Có khả năng mặc dù nếu một lĩnh vực là duy nhất, đây là một ứng cử viên tốt hơn cho PK.
Bây giờ, đôi khi, bạn có nhiều hơn một ứng cử viên cho PK. Trong trường hợp này, bạn chọn một khóa làm PK hoặc sử dụng khóa thay thế (cá nhân tôi thích khóa thay thế cho trường hợp này). Và (điều này rất quan trọng!) Bạn thêm các chỉ mục duy nhất vào mỗi khóa ứng cử viên không được chọn làm PK. Nếu dữ liệu cần là duy nhất, nó cần một chỉ mục duy nhất cho dù đó là PK hay không. Đây là một vấn đề toàn vẹn dữ liệu. (Lưu ý điều này cũng đúng bất cứ khi nào bạn sử dụng khóa thay thế; mọi người gặp rắc rối với các khóa thay thế vì họ quên tạo các chỉ mục duy nhất trên các khóa ứng viên.)
Đôi khi bạn muốn có nhiều hơn một khóa thay thế (thường là PK nếu bạn có chúng). Trong trường hợp này, những gì bạn muốn không phải là PK nhiều hơn, đó là nhiều trường hơn với các khóa được tạo tự động. Hầu hết các DB không cho phép điều này, nhưng có nhiều cách để khắc phục nó. Trước tiên hãy xem xét trường thứ hai có thể được tính dựa trên khóa được tạo tự động đầu tiên (ví dụ Field1 * -1) hoặc có lẽ nhu cầu về khóa tự động thứ hai thực sự có nghĩa là bạn nên tạo một bảng có liên quan. Các bảng liên quan có thể trong mối quan hệ một-một. Bạn sẽ thực thi điều đó bằng cách thêm PK từ bảng cha vào bảng con và sau đó thêm trường được tạo tự động mới vào bảng và sau đó bất kỳ trường nào phù hợp với bảng này. Sau đó chọn một trong hai khóa làm PK và đặt một chỉ mục duy nhất ở bên kia (trường được tạo tự động không phải là PK). Và đảm bảo thêm FK vào trường trong bảng cha. Nói chung nếu bạn không có các trường bổ sung cho bảng con, bạn cần kiểm tra lý do tại sao bạn nghĩ rằng bạn cần hai trường tự phát.
Câu trả lời kỹ thuật tốt đã được đưa ra theo cách tốt hơn tôi có thể làm. Tôi chỉ có thể thêm vào chủ đề này:
Nếu bạn muốn một cái gì đó không được phép / chấp nhận, đó là lý do tốt để lùi lại.
Hy vọng nó sẽ giúp được ai đó.
Có, có thể có trong SQL, nhưng chúng tôi không thể đặt nhiều hơn một khóa chính trong MsAccess. Sau đó, tôi không biết về các cơ sở dữ liệu khác.
CREATE TABLE CHAPTER (
BOOK_ISBN VARCHAR(50) NOT NULL,
IDX INT NOT NULL,
TITLE VARCHAR(100) NOT NULL,
NUM_OF_PAGES INT,
PRIMARY KEY (BOOK_ISBN, IDX)
);