10/10/2018, 10:41
[Survey] Tạo primary key: auto increment hay unique id ?
Câu hỏi rất rõ ràng. Khi tạo 1 table, ví dụ post thì bạn có thể chọn primary key dạng integer với thuộc tính auto increment hoặc là varchar bằng cách sử dụng 1 hàm phù hợp để tạo ra unique id.
Nếu primary key là auto increment:
Ưu điểm:
- Không phải lo về việc các id phải khác nhau, CSDL tự lo.
Nhược điểm:
- Dễ bị lấy dữ liệu tự động (leech) (cho id chạy từ 1 cho đến hiện tại là thấy hết dữ liệu trên site)
- Để lộ thứ tự các record được tạo nên (id nhỏ hơn sẽ được tạo ra trước). Như vậy đôi khi không đảm bảo được tính privacy, nhất là vơi các trang mạng xã hội... Nhiều người tò mò thay đổi id tăng hoặc giảm một chút là thấy được dữ liệu do người khác tạo ra trước đó hay ngay sau mình.
- Dài, một id dạng 324235434 thì trông không gọn bằng yHfs ...
(Ưu điểm ít, nhược điểm nhiều)
Điểm qua một số site và script:
- Các open source hầu như đều thiết kế trên auto increment.
- Hầu hết các site trên Internet vì thế cũng chọn primary key là auto increment. Ngay cả facebook cũng thế. Và tò mò một chút bạn sẽ biết ngay Mark Zuckerberg cũng là profile được tạo đầu tiên trên MXH này http://www.facebook.com/profile.php?id=4 . Nghe nói là do thiết kế kiểu này nên facebook rất dễ bị dò bằng phần mềm tự động. (Đã từng có vụ dò email trên facebook như vậy, theo Wikipedia).
- Các site không dùng int auto increment mà dùng unique varchar điển hình là Youtube.com, mp3.zing.vn, vnexpress.net, nhaccuatui.com... và các site rút gọn link.
Lưu ý: nên đọc cái này trước khi spam http://stackoverflow.com/questions/1...s-like-youtube
Nếu primary key là auto increment:
Ưu điểm:
- Không phải lo về việc các id phải khác nhau, CSDL tự lo.
Nhược điểm:
- Dễ bị lấy dữ liệu tự động (leech) (cho id chạy từ 1 cho đến hiện tại là thấy hết dữ liệu trên site)
- Để lộ thứ tự các record được tạo nên (id nhỏ hơn sẽ được tạo ra trước). Như vậy đôi khi không đảm bảo được tính privacy, nhất là vơi các trang mạng xã hội... Nhiều người tò mò thay đổi id tăng hoặc giảm một chút là thấy được dữ liệu do người khác tạo ra trước đó hay ngay sau mình.
- Dài, một id dạng 324235434 thì trông không gọn bằng yHfs ...
(Ưu điểm ít, nhược điểm nhiều)
Điểm qua một số site và script:
- Các open source hầu như đều thiết kế trên auto increment.
- Hầu hết các site trên Internet vì thế cũng chọn primary key là auto increment. Ngay cả facebook cũng thế. Và tò mò một chút bạn sẽ biết ngay Mark Zuckerberg cũng là profile được tạo đầu tiên trên MXH này http://www.facebook.com/profile.php?id=4 . Nghe nói là do thiết kế kiểu này nên facebook rất dễ bị dò bằng phần mềm tự động. (Đã từng có vụ dò email trên facebook như vậy, theo Wikipedia).
- Các site không dùng int auto increment mà dùng unique varchar điển hình là Youtube.com, mp3.zing.vn, vnexpress.net, nhaccuatui.com... và các site rút gọn link.
Lưu ý: nên đọc cái này trước khi spam http://stackoverflow.com/questions/1...s-like-youtube
Bài liên quan
dù là bik id nhưng trong php có thể check xem đủ quyền mà xem thông tin ko chứ ?
xài unique varchar thì url xấu . ví dụ thay vì http://site.php/post/hello-world-1.html thì thay bằng http://site.php/post/hello-world-qukemqwoiuupopoas.html
Tôi cũng không nghĩ là varchar thì xấu mà còn ngược lại, nhất là với website có nội dung nhiều. Một varchar(6) có thể tạo được hơn 2 tỉ record khác nhau (chỉ dùng 36 kí tự 0-9, A-Z). Phải dùng int(10) mới tạo được ngần ấy.
Thay vì một id dài như http://example.com/about-1686257907.html thì một id ngắn kiểu http://example.com/about.HY6HJT.html trông gọn gàng hơn. Bác hãy vào Zing mp3 mà xem sẽ thấy.
Nhân tiện post lên cái hàm tạo primary key ngắn bằng varchar(6) vừa viết cho ai cần thì xài, cần dùng vòng lặp while để kiểm tra xem primary key này đã tồn tại trong table chưa. Vì hàm này có thể sinh ra hơn 2 tỉ primary key khác nhau nên nếu web của bạn có dưới 2 triệu record thì hiệu suất khá cao (xác xuất vòng lặp được thực thi chỉ là 1/1000). Nếu web bạn không có 2 lần insert trong 1/10000 giây thì cách làm này good. Nếu không phải vậy thì sẽ có lỗi ở cấp độ database với xác suất khoảng 1/200000 (2 record được insert vào cùng thời điểm và sử dụng primary key ngẫu nhiên giống nhau )
// create a short random key based on current timestamp to use as a primary key
function random_id()
{
// using micro time as the last 4 digits in base 10 to prevent collision with another request
list($micro_time, $time) = explode(' ', microtime());
$id = round((rand(0, 217677) + $micro_time)*10000);
$id = strtoupper(base_convert($id, 10, 36));
return $id;
}
với lại tạo unique varchar thì nên có 1 key riêng chỉ có mình bik . có nhiều cách để tạo
...order by post_date // chẳng hạn
Mình thì vẫn xài kiểu đánh id theo auto increment.