Có bao giờ là ý hay khi không có khóa chính 'id' cho bảng?

Question

Dường như với tôi như một ý tưởng hay, luôn có một trường hợp nào đó tốt hơn là bạn không có điều này trong bảng?

Answer 1

Theo kinh nghiệm của tôi, hầu như không bao giờ. (Đối với một "vấn đề tốc độ, tôi chỉ cần chèn và không thực sự quan tâm về việc thu hồi tại thời điểm này" phong cách của ứng dụng, có lẽ.)

Trong khi bạn có thể tưởng tượng không bao giờ sử dụng trường ID, nó gần như luôn luôn khôn ngoan để có một AUTO_INCREMENTing hạnh phúc, bởi vì một ngày bạn có thể cần một. (Tất nhiên, bạn có thể làm một 'ALTER ..' để thêm một, nhưng đó là ngoài điểm.)

Answer 2

Thông thường, bạn nên có một số loại PRIMARY KEY.

Có một số tình huống thực sự đặc biệt khi bạn không muốn, đáng chú ý nhất là các bảng nhật ký được sắp xếp heap (không được nhóm) không có bất kỳ chỉ mục nào để tăng tốc độ chèn.

Lưu ý rằng trong MySQL, InnoDB bảng không thể được sắp xếp theo thứ tự do đó điều này chỉ liên quan đến MyISAM bảng.

Cũng lưu ý rằng một PRIMARY KEY có thể được tổng hợp, như trong bảng mối quan hệ many-to-many. Bạn sẽ không có cột id trong bảng như vậy nhưng bạn sẽ có khóa chính kết hợp gồm các cột id của các bảng có liên quan.

Xem câu hỏi này để biết thêm chi tiết:

• Should each and every table have a primary key?

Answer 3

Câu trả lời ngắn gọn: có.

Câu trả lời dài hơn: nếu bạn có một bảng được sử dụng trong mối quan hệ nhiều-nhiều, bạn không thực sự cần một khóa chính. Sau đó, nó có thể được coi là một sự lãng phí không gian. Có thể có nhiều ví dụ hơn, đây chỉ là một bằng chứng cho câu trả lời "có" :-)

Answer 4

Có khóa chính là ý tưởng hay (và cần thiết nếu bạn muốn thiết kế cơ sở dữ liệu được chuẩn hóa hoàn toàn).

Cá nhân, nếu bảng có khóa ứng cử viên tự nhiên, tôi sẽ sử dụng hầu hết thời gian, thay vì thêm cột ID phải được điền giả tạo.

Answer 5

Đối với hiệu suất/không gian, tôi tránh trường ID tự động nếu có thể. Nếu bạn có một bảng rất lớn (nhiều triệu hoặc hàng tỷ hồ sơ) thì không gian là quan trọng. nếu bạn có thể tìm thấy khóa chính tốt, có thể sử dụng dựa trên các trường (hoặc các trường khác) thì bạn nên sử dụng khóa đó hơn là giới thiệu một trường ID.

Không có ý nghĩa khi có khóa chính tự động nếu bạn có thể sử dụng một nhóm trường mà bạn có chỉ mục duy nhất làm khóa chính. Bạn chỉ cần cẩn thận với UPDATEs để duy trì tính toàn vẹn tham chiếu.

Answer 6

Đối với cơ sở dữ liệu của first normal form hoặc second normal form.

Answer 7

Tùy thuộc vào thiết kế dữ liệu của bạn và cách thức bạn truy cập dữ liệu trong bảng.

Bảng nhật ký thường không cần khóa chính vì bạn thường truy cập nhật ký theo nhóm và không xóa/chỉnh sửa thư đơn (bạn có thể dọn toàn bộ bảng hoặc cửa sổ nhật ký thời gian).

Các thời điểm khác, trường ID có thể không cần thiết. Nếu khách hàng đăng ký với trang web của bạn bằng cách sử dụng OpenID (hoặc chỉ đơn giản là một địa chỉ email) thì bạn đã có khóa chính của mình. Tuy nhiên, trong trường hợp này, bạn nên thêm trường ID dư thừa, vì số nguyên sử dụng ít không gian hơn chuỗi và bạn phải lặp lại ID trong tất cả các mối quan hệ mà thực thể có liên quan!

Cuối cùng, bảng quan hệ không cần ID rõ ràng trong 99% trường hợp. Ví dụ: mối quan hệ nhiều-nhiều giữa Người dùng và Nhóm. Bảng quan hệ chỉ bao gồm ID người dùng và ID nhóm và rằng là khóa chính của bạn (bạn muốn lập chỉ mục hai trường riêng biệt cho hiệu suất ...).

Nhân tiện, ID tăng tự động không làm chậm hiệu suất đáng kể. Giá trị truy cập được lưu trữ trong siêu dữ liệu của bảng, vì vậy khi DBMS thực hiện chèn, nó sẽ tự động tăng bộ đếm tham chiếu và điều này có thể được thực hiện với số AtomicInteger và số Interlocked tương đương của Java, vì vậy bạn không phải lo lắng về nó !