Tôi luôn thích sử dụng số nguyên dài làm khóa chính trong cơ sở dữ liệu, vì sự đơn giản và tốc độ (giả định). Nhưng khi sử dụng lược đồ URL giống REST hoặc Rails cho các trường hợp đối tượng, sau đó tôi sẽ kết thúc với các URL như sau:
http://example.com/user/783
Và sau đó, giả định là cũng có những người dùng có ID là 782, 781, ..., 2 và 1. Giả sử rằng ứng dụng web được đề cập là đủ an toàn để ngăn mọi người nhập các số khác để xem người dùng khác mà không được phép, a khóa đại diện đơn giản được gán tuần tự cũng "rò rỉ" tổng số phiên bản (cũ hơn phiên bản này), trong trường hợp này là người dùng, có thể là thông tin đặc quyền. (Ví dụ: tôi là người dùng # 726 trong stackoverflow.)
Một sẽ UUID / GUID là một giải pháp tốt hơn? Sau đó, tôi có thể thiết lập các URL như thế này:
http://example.com/user/035a46e0-6550-11dd-ad8b-0800200c9a66
Không chính xác ngắn gọn, nhưng có ít thông tin ngụ ý hơn về người dùng trên màn hình. Chắc chắn, nó có "bảo mật thông qua sự che giấu" không thể thay thế cho bảo mật thích hợp, nhưng ít nhất nó có vẻ an toàn hơn một chút.
Lợi ích đó có xứng đáng với chi phí và sự phức tạp của việc triển khai UUID cho các cá thể đối tượng có địa chỉ web không? Tôi nghĩ rằng tôi vẫn muốn sử dụng các cột số nguyên làm PK cơ sở dữ liệu chỉ để tăng tốc độ nối.
Ngoài ra còn có câu hỏi về biểu diễn trong cơ sở dữ liệu của UUID. Tôi biết MySQL lưu trữ chúng dưới dạng chuỗi 36 ký tự. Postgres dường như có một biểu diễn bên trong hiệu quả hơn (128 bit?) Nhưng tôi chưa tự mình thử. Ai có kinh nghiệm với cái này rồi nào?
Cập nhật: đối với những người đã hỏi về việc chỉ sử dụng tên người dùng trong URL (ví dụ: http://example.com/user/yukondude ), cách này hoạt động tốt đối với các trường hợp đối tượng có tên là duy nhất, nhưng đối với các trang web đối tượng ứng dụng thực sự chỉ có thể được xác định bằng số? Đơn đặt hàng, giao dịch, hóa đơn, tên hình ảnh trùng lặp, câu hỏi stackoverflow, ...