Tôi đang xem xét thay đổi một số bảng để sử dụng nvarchar (50) làm khóa chính thay vì khóa chính int. Sử dụng một ID int cho một khóa thực sự là dữ liệu không liên quan, đó là chuỗi mà tôi quan tâm. Loại hit hiệu suất nào sẽ xảy ra, hoặc bạn nghiên cứu ở đâu? Khác hơn là cắt và cố gắng đó là.SQL Server 2005 có phạt tôi vì sử dụng nvarchar (50) làm khóa chính, thay vì số nguyên không?
Bạn đã gặp phải một trong những "cuộc chiến tranh thánh" lớn về thiết kế cơ sở dữ liệu. Cuộc tranh luận mà bạn đang đề cập đến là đối số "thay thế so với khóa tự nhiên" đã được hoành hành miễn là đã có RDBMS (gần như tôi có thể nói).
Cuộc tranh luận về cơ bản sẽ xem xét liệu khóa đại diện (thay thế, ví dụ cột IDENTITY) có được sử dụng hay không khi sử dụng dữ liệu thực tế mô tả duy nhất bản ghi (khóa tự nhiên).
Tôi sẽ nói rằng không có câu trả lời "đúng". Các biện pháp hiệu suất là một tạo phẩm của nền tảng và cần được đánh giá bằng thử nghiệm, nhưng hiệu suất không có khả năng là mối quan tâm chính.
Điều tôi coi là đối số chính cho khóa thay thế là bất biến của khóa chính. Nếu bạn chọn sử dụng khóa tự nhiên, bạn từ bỏ tùy chọn thay đổi khóa đó sau khi nó được thiết lập. Bạn cũng từ bỏ khả năng nó có thể trở thành không duy nhất tại một thời điểm nào đó trong tương lai. Vì những lý do đó, tôi thường (không phải luôn luôn) sử dụng các khóa thay thế cho hầu hết các bảng của tôi.
Tuy nhiên, như tôi đã đề cập, có một cuộc tranh luận rất dài với các cuộc thảo luận về các chiến lược lập chỉ mục và tuân thủ hình thức thông thường sẽ được đọc nếu bạn nghiêng.
Tôi sẽ Google "thay thế bằng khóa tự nhiên".Dưới đây là một số liên kết để giúp bạn bắt đầu:
Hope this helps.
Cân nhắc sử dụng khóa thay thế (khóa int chính) làm khóa chỉ mục khóa/nhóm chính. Vấn đề với việc sử dụng nvarchar (50) làm khóa chính/nhóm chỉ mục chính là bảng của bạn sẽ được sắp xếp theo khóa đó có nghĩa là nó có khả năng bị phân mảnh cao và bất kỳ chỉ mục nào khác sẽ có gánh nặng tham chiếu khóa chính.
Một vấn đề khác là có lẽ bạn cần phải THAM GIA trên các bảng khác theo loại giá trị này là một hoạt động tốn kém hơn khi kích thước của khóa tăng lên.
Tôi nghĩ rằng có rất ít trường hợp mà khóa chính của nvarchar (50) có ý nghĩa.
Nói chung, các khóa chính phải là một UNLESS thay thế bạn có khóa không thay đổi nhỏ. Có thể cho rằng, SSN, ví dụ, có thể được coi là một khóa bất biến tự nhiên.
Đối với hiệu suất, tôi thường yêu cầu sau đây:
bao nhiêu hàng? 1.000 hoặc 1.000.000 hoặc 10.000.000 ??
máy chủ đang ngồi trên máy chủ nào? (bộ nhớ, diskspace)
Tôi sẽ cấu hình và sau đó xem. Thông thường đối với tôi, nút cổ chai không phải là cơ sở dữ liệu, mã được viết kém, được triển khai kém, v.v ...
Tại sao UNICODE? ví dụ. nếu tôi dịch một từ tiếng Anh sang ký tự Hán Trung Quốc, chúng có được coi là trùng lặp không?
Tại sao lại thay đổi? Chiều rộng cố định là một đặc tính vật lý tốt của một khóa.
Tại sao có 50 ký tự? Đó là rất nhiều keying cho người dùng (tôi đồng ý "một int ID cho một khóa thực sự là dữ liệu không liên quan" và nghĩ rằng cái gọi là 'chìa khóa thay thế' không bao giờ nên được tiếp xúc với người dùng cuối, BTW).
Ngoài ra, đối với tôi NVARCHAR(50) là một chút của một 'mùi': một mặc định của Microsoft, một cổng thẳng từ MS Access, có lẽ? Điều này không có nghĩa là bạn đã không đưa ra suy nghĩ và cân nhắc đến chìa khóa của bạn, tất nhiên, chỉ là một trong những điều đó có thể xem xét.
Xin lỗi: bạn có nghĩa là PRIMARY KEY, đúng không? Giả sử bạn sử dụng một cách rõ ràng chỉ mục nhóm (mỗi bảng) của bạn, chỉ định AFAIK PRIMARY KEY không có ý nghĩa vật lý trong miền SQL Server. Tất nhiên, tất cả các khóa ứng cử viên của bạn nên được bao phủ bởi các ràng buộc NOT NULL UNIQUE; một trong những bạn chọn để thúc đẩy để PRIMARY chính là tùy ý.
Để chắc chắn ghi ra tất cả các đối số được đề xuất bởi các nhà lãnh đạo của giải pháp khóa tự nhiên (cf surrogate vs natural key war), và để làm cho nó ngắn, tôi nên nói rằng chìa khóa thay thế LUÔN LUÔN làm việc, trong khi các khóa tự nhiên có một xu hướng loosy dẫn đến vấn đề và thất vọng, thường vào những thời điểm bất ngờ.
Tôi không nói rằng chúng là giải pháp tối ưu cho mọi tình huống, nhưng để tránh mất thời gian (và của người khác) suy nghĩ về các thông số thích hợp cho khóa tự nhiên tốt nhất khi tạo bảng, chỉ cần chọn thay thế và hoàn thành . Và nếu bảng của bạn dường như có một khóa tự nhiên thích hợp, chỉ cần thêm nó như là một trường có chỉ mục (duy nhất?).
Và để làm cho các nhà phát triển dễ dàng, luôn có trường đầu tiên của bạn làm khóa chính, khóa thứ hai là khóa tự nhiên giả/giả. bảng của bạn chỉ nên xem xét như thế:
Tbl_whatever
id_whatever, unique identifier, primary key
code_whatever, nvarchar(your favorite length), indexed
.....
đâu id_ là tiền tố cho khóa chính, và code_ được sử dụng cho lĩnh vực lập chỉ mục "tự nhiên"
Kim Tripp nói chuyện về chủ đề này trong một "Run As Đài phát thanh gần đây " đề tài. http://www.runasradio.com/default.aspx?showNum=76 – Hafthor