Một khóa thay thế có bao giờ được tiếp xúc với người dùng?

Thông thường trong một bảng không có khóa tự nhiên, nó vẫn hữu ích cho người dùng để có thể có một định danh được tạo duy nhất. Nếu bảng có khóa chính thay thế (và trong trường hợp như vậy, bạn chắc chắn sẽ mong đợi nó) nếu khóa đó được hiển thị cho người dùng hoặc nên sử dụng trường khác cho mục đích đó?

Một lý do không để lộ khóa thay thế là bây giờ bạn không thể thực hiện các thao tác duy trì mối quan hệ giữa các bản ghi, nhưng thay đổi các giá trị khóa, chẳng hạn như xóa / chèn lại một số loại, nhiều phương pháp sao chép dữ liệu từ một cơ sở dữ liệu sang khác, v.v.

Ưu điểm chính của việc lộ khóa thay thế là sự đơn giản trong việc sử dụng một lĩnh vực mà bạn có.

Trong trường hợp nào thì tốt hơn là để lộ trực tiếp khóa thay thế cho người dùng?

Bạn cần sẵn sàng cho bất kỳ số nhận dạng nào được hiển thị cho người dùng / khách hàng cần được thay đổi và thay đổi danh tính của một hàng trong cơ sở dữ liệu và tuyên truyền thay đổi đó cho tất cả các khóa ngoại chỉ là yêu cầu ngắt dữ liệu.

Nếu dữ liệu không có khóa kinh doanh tự nhiên, bạn có thể thêm một trường bổ sung cho "số nhận dạng doanh nghiệp". Điều này nên được tối ưu hóa cho các quy trình mà nó được sử dụng cho. Nhập bàn phím điện thoại có nghĩa là chỉ số. Qua điện thoại / bằng lời nói có nghĩa là tránh các ký hiệu âm thanh tương tự (B / D, M / N, v.v.). Bạn thậm chí có thể tự động tạo một số cụm từ dễ nhớ ("thạch xanh").

Hiệu quả của việc này là doanh nghiệp sau này có thể thay đổi cách họ muốn tham chiếu đến các bản ghi và thay đổi lược đồ dữ liệu duy nhất là thêm một cột mới cho kiểu id đó hoặc biến đổi các id đã có. Thay đổi không lan truyền trong toàn bộ cơ sở dữ liệu và bạn vẫn có một id (đại diện thay thế) hợp lệ theo thời gian.

Nói tóm lại, tôi sẽ tránh để lộ các khóa thay thế cho người dùng. Như các ý kiến ​​chỉ ra, các khóa thay thế hầu như không bao giờ thay đổi. Ngược lại, các doanh nghiệp muốn thay đổi mọi thứ. Nếu khóa thay thế bị lộ, đó chỉ là vấn đề thời gian trước khi doanh nghiệp muốn thay đổi nó.

Như một lưu ý phụ, khi tôi nói "phơi bày" ở đây, tôi có nghĩa là đưa chìa khóa cho người dùng với mong muốn họ sử dụng nó trực tiếp (như gọi vào để hỗ trợ với số thứ tự của họ).

Trong một số trường hợp, các khóa thay thế được mong đợi và có ý nghĩa với người dùng. Ví dụ yêu thích của tôi là "số thứ tự". Số thứ tự không thực sự là khóa tự nhiên: khóa tự nhiên có thể là dấu thời gian cộng với người dùng hoặc có thể nhiều hơn thế nếu bạn mong muốn người dùng tạo nhiều hơn một đơn hàng trong độ chi tiết của dấu thời gian của bạn.

Tuy nhiên, người dùng hiểu và mong đợi sự tiện lợi của số thứ tự. Không có hại, và rất nhiều giá trị, nếu bạn cho người dùng biết về chúng.

Mặt khác, một số phím thay thế không có ý nghĩa với người dùng. Chắc chắn, công ty bảo hiểm sức khỏe của tôi có một số khóa thay thế nhận dạng tôi dựa trên id thành viên, ngày sinh, người vận chuyển, v.v., nhưng tôi không quan tâm đến điều đó, tôi quan tâm đến thông tin trên thẻ của tôi (thường bao gồm id dựa trên về chủ nhân của tôi và không phải là duy nhất trên toàn vũ trụ ... Do đó, khóa thay thế tại công ty bảo hiểm).

Bạn chỉ nên để lộ khóa thay thế nếu đó là GUID / UUID được tạo đúng. Hiển thị các khóa thay thế liên tiếp là số 4 trong 10 vấn đề bảo mật hàng đầu của OWASP.

* Trong thực tế, tốt nhất là giả định rằng nó không được tạo đúng cho các mục đích này trừ khi bạn biết rằng nó được tạo bởi một trình tạo số ngẫu nhiên hoặc giả ngẫu nhiên an toàn bằng mật mã.

Nếu một bảng không có khóa tự nhiên, các khóa thay thế cho phép các hàng như thế này.

surrogate_key  some_name
--
1              Wibble
2              Wibble
...
17             Wibble
...
235            Wibble

Tôi sẽ gọi những khóa nhân tạo này thay vì khóa thay thế, nhưng sự khác biệt đó không quan trọng đối với câu hỏi này.

Bây giờ, giả sử rằng có dữ liệu quan trọng tham chiếu các khóa thay thế này thông qua khóa ngoại, làm thế nào để người dùng cuối biết hàng nào sẽ cập nhật nếu họ không biết các giá trị khóa thay thế?

Theo cách nói của giáo dân:

• Người thay thế nên được ẩn khỏi người dùng.
• Bạn nên để lộ một số khóa ứng viên kinh doanh khác cho người dùng.
• Nếu không có khóa ứng viên nào khác tồn tại, bạn nên hiển thị PK. Nhưng trong trường hợp này, PK không được coi là thay thế vì nó không thay thế cho cột khác.

bạn CHỈ nên hiển thị một trường cho người dùng cung cấp thông tin hữu ích cho người dùng, trực tiếp hoặc báo cáo lỗi cho bạn.

ngược lại, bạn LUÔN LUÔN phơi bày "thay thế khóa chính" khi chúng là phương tiện chính để xác định một bản ghi (đơn giản hoặc phức tạp) cho tương tác mà người dùng thực hiện.

Không quan trọng bạn có để lộ chìa khóa hay không cho người dùng cuối. Ứng dụng của bạn nên thực hiện ủy quyền cần thiết sao cho chỉ cần biết id đơn hàng, chẳng hạn, không thể cho phép họ truy cập vào thứ mà họ thường không có quyền truy cập.

báo trước: điều này giả định một ứng dụng dựa trên web hoặc n-tier nơi ủy quyền phía máy chủ là có thể / khả thi. Nếu bạn có một ứng dụng VB trực tiếp thực hiện sql, thì đó là một vấn đề hoàn toàn.