Trong các bảng mà bạn chỉ cần 1 cột làm khóa và các giá trị trong cột có thể là số nguyên, khi bạn không nên sử dụng trường nhận dạng?Khi có cột nhận dạng không phải là một ý tưởng hay?
Ngược lại, trong cùng một bảng và cột, khi nào bạn sẽ tạo giá trị của nó theo cách thủ công và bạn sẽ không sử dụng giá trị tự tạo cho mỗi bản ghi?
Tôi đoán rằng nó sẽ là trường hợp khi có rất nhiều chèn và xóa bảng. Tôi có đúng không? Những tình huống khác có thể là gì?
Nếu bạn đã định cư ở bên thay thế của Great Primary Key Debacle thì tôi không thể tìm thấy một lý do nào không sử dụng khóa nhận dạng. Các lựa chọn thay thế thông thường là các guids (chúng có nhiều disadvatage, chủ yếu từ kích thước và ngẫu nhiên) và các lớp ứng dụng được tạo ra. Nhưng việc tạo khóa thay thế trong lớp ứng dụng hơi khó hơn một chút và cũng không bao gồm việc truy cập dữ liệu không liên quan đến ứng dụng (ví dụ: tải hàng loạt, nhập, các ứng dụng khác, v.v.). Một trường hợp đặc biệt là các ứng dụng được phân phối khi các hướng dẫn và thậm chí cả các trình tự tuần tự có thể cung cấp một lựa chọn tốt hơn cho các id trang + khóa nhận dạng ..
Tôi cho rằng nếu bạn đang tạo bảng liên kết nhiều người, trong đó cả hai trường là foreign keys, bạn không cần trường nhận dạng.
Ngày nay, tôi tưởng tượng rằng hầu hết các ORMs mong đợi có trường nhận dạng trong mỗi bảng. Nói chung, nó là một thực hành tốt để cung cấp một.
Bạn có thể không (thường) xác định giá trị khi chèn vào cột sắc, vì vậy ví dụ nếu cột "id" được quy định như một xác định SQL sau đây sẽ thất bại:
INSERT INTO MyTable (id, name) VALUES (1, 'Smith')
Để thực hiện loại này của chèn bạn cần phải có IDENTITY_INSERT trên cho bảng đó - điều này là không có ý định được trên bình thường và chỉ có thể được trên cho tối đa là 1 bảng trong cơ sở dữ liệu tại bất kỳ điểm nào trong thời gian.
Tôi không chắc mình hiểu đầy đủ về ngữ cảnh của bạn, nhưng tôi giải thích câu hỏi của bạn là:
"Nếu tôi cần cơ sở dữ liệu để tạo cột duy nhất (vì bất kỳ lý do gì), khi nào nó không phải là cột số nguyên tăng dần (danh tính)?"
Trong những trường hợp đó, không có lý do gì để sử dụng bất kỳ thứ gì khác ngoài cơ sở do DBMS cung cấp cho mục đích đó; trong trường hợp của bạn (SQL Server?) đó là một bản sắc.
Trừ:
Nếu bao giờ bạn sẽ cần phải hợp nhất bảng với dữ liệu từ một nguồn khác, sử dụng một GUID, mà sẽ ngăn chặn các phím trùng lặp khỏi va chạm.
Nếu bạn cần hợp nhất cơ sở dữ liệu, việc này sẽ dễ dàng hơn nhiều nếu bạn không phải tạo lại khóa.
Nếu tôi cần người đại diện, tôi sẽ sử dụng cột IDENTITY hoặc cột GUID tùy thuộc vào nhu cầu về tính duy nhất toàn cầu.
Nếu có khóa chính tự nhiên hoặc khóa chính được xác định là tổ hợp duy nhất của các khóa ngoại khác, thì tôi thường không có IDENTITY, cũng như không sử dụng nó làm khóa chính.
Có một ngoại lệ, đó là các bảng cấu hình chụp nhanh mà tôi đang theo dõi bằng trình kích hoạt kiểm tra. Trong trường hợp này, thường có một "khóa chính" hợp lý (thường là ngày chụp nhanh và khóa tự nhiên của hàng - như một trung tâm chi phí hoặc số tài khoản gl mà hàng là bản ghi cấu hình), nhưng thay vì sử dụng tự nhiên "khóa chính" làm khóa chính, tôi thêm một IDENTITY và tạo khóa chính và tạo một chỉ mục hoặc ràng buộc duy nhất về ngày tháng và khóa tự nhiên. Mặc dù về mặt lý thuyết, ngày tháng và khóa tự nhiên không thay đổi, trong các bảng này, nếu người dùng thực hiện điều đó thay vì thêm hàng mới và xóa hàng cũ, tôi muốn kiểm toán (phản ánh thay đổi đối với hàng được xác định bằng khóa chính của nó) để thực sự phản ánh một sự thay đổi trong hàng - không phải là sự biến mất của một chìa khóa và sự xuất hiện của một cái mới.
Một trường hợp không muốn một trường nhận dạng sẽ có mối quan hệ 1-1. Bảng phụ sẽ có khóa chính của nó có cùng giá trị với bảng chính. Lý do duy nhất để có một lĩnh vực nhận dạng trong tình huống đó dường như là để đáp ứng một ORM.
Gần đây tôi đã triển khai một Suffix Trie trong C# có thể lập chỉ mục tiểu thuyết và sau đó cho phép tìm kiếm được thực hiện cực nhanh, tuyến tính với kích thước của chuỗi tìm kiếm. Một phần của các yêu cầu (đây là một bài tập về nhà) là sử dụng lưu trữ ngoại tuyến, vì vậy tôi đã sử dụng MS SQL và cần một cấu trúc để biểu diễn một nút trong bảng.
Tôi đã kết thúc với cấu trúc sau: NodeID Character ParentID, v.v., trong đó NodeID là khóa chính.
Tôi không muốn điều này được thực hiện dưới dạng danh tính tự động cho hai lý do chính.
+1 - Tôi thích thông tin bổ sung về GUID được phân phối. Từ kinh nghiệm, đây là chính xác trường hợp nó có thể được dễ dàng hơn bằng cách sử dụng một phím số nguyên. –