[Survey] Tạo primary key: auto increment hay unique id ?

[fotech_nd]

Các bác nói sao chứ Youtube dùng varchar có vấn đề gì đâu nào.

Cái slug url thì có liên quan gì tới PK nhỉ

[bka]

- sao bạn bik nó là varchar?
- theo mình, tốt nhất là để theo int AI, cái varchar bạn thấy có thể là encryption từ 1 số int nào đó

chính xác . không phải bàn

[alone_hero]

Công nhận nhiều người bị bệnh nghề nghiệp, cứ phức tạp hóa vấn đề. Tại sao cứ phải cố gắng nghĩ ra 1 cách mà bản thân nó đã có cách hiệu quả rồi. auto increment được sinh ra là để phục vụ cho việc làm PK rất tốt rồi, còn phải nghĩ ra varchar làm gì, rồi lại còn nhìn huyền bí nữa chứ.
Sản phẩm miễn là đến người dùng hiệu quả, bảo mật tốt (nếu có nhu cầu) đâu phải varchar làm PK là bảo mật được tốt đâu, bảo mật ở cách thiết kế hệ thống mà.

[bachnga]

Tôi thừa nhận là không có kinh nghiệm gì trong lĩnh vực thiết kế, quản trị database, nên ý kiến của tôi có thể sai.
Tùy theo nhiệm vụ của bảng dữ liệu mà khóa chính có thể là int auto increment hay varchar.
Khi chỉ cần nhìn vào mã hóa đơn mà ông chủ biết ngay hóa đơn này do ai lập, vào thời gian nào... thì auto increment nói lên được gì?
Hơn nữa, khi tạo 1 database không chỉ đơn thuần là lưu trữ, cập nhật dữ liệu.
Nếu các bạn tìm hiểu kỹ về cấu trúc index của một khóa chính thì không phải tranh cãi về vấn đề này.
Theo tôi nghĩ dùng auto increment là do nhiều người chỉ có biết MySQL thì phải.

[khonggiannet]

Công nhận nhiều người bị bệnh nghề nghiệp, cứ phức tạp hóa vấn đề. Tại sao cứ phải cố gắng nghĩ ra 1 cách mà bản thân nó đã có cách hiệu quả rồi. auto increment được sinh ra là để phục vụ cho việc làm PK rất tốt rồi, còn phải nghĩ ra varchar làm gì, rồi lại còn nhìn huyền bí nữa chứ.
Sản phẩm miễn là đến người dùng hiệu quả, bảo mật tốt (nếu có nhu cầu) đâu phải varchar làm PK là bảo mật được tốt đâu, bảo mật ở cách thiết kế hệ thống mà.

Chắc chắn là bác không chịu đọc các post trên hoặc đọc mà không hiểu . Tại sao Youtube sử dụng link kiểu youtube.com/watch?v=Wl3CGQP1gFQ mà không là youtube.com/watch?v=23074809328549 ? Bác nào vẫn không hiểu tại sao phải đề cập đến varchar ở đây thì nên đọc cái này trước khi spam http://stackoverflow.com/questions/1...s-like-youtube

Tôi cũng không nghĩ là nó dùng PK là autoincrement int sau đó encryption qua varchar để tạo ra URL trông có vẻ "huyền bí". Việc gì phải chuyển qua chuyển qua chuyển lại như vậy cho down performance vậy? Mà autoincrement cũng không thể scale tốt. Cách hiệu quả nhất là CSDL của Youtube và Google dùng chính varchar hoặc char làm primary key. Nếu ai có ý kiến khác thì cho giải thích hợp lí chứ đừng reply hời hợt như bác trên.

Tôi thừa nhận là không có kinh nghiệm gì trong lĩnh vực thiết kế, quản trị database, nên ý kiến của tôi có thể sai.
Tùy theo nhiệm vụ của bảng dữ liệu mà khóa chính có thể là int auto increment hay varchar.
Khi chỉ cần nhìn vào mã hóa đơn mà ông chủ biết ngay hóa đơn này do ai lập, vào thời gian nào... thì auto increment nói lên được gì?
Hơn nữa, khi tạo 1 database không chỉ đơn thuần là lưu trữ, cập nhật dữ liệu.
Nếu các bạn tìm hiểu kỹ về cấu trúc index của một khóa chính thì không phải tranh cãi về vấn đề này.
Theo tôi nghĩ dùng auto increment là do nhiều người chỉ có biết MySQL thì phải.

Đúng là nhiều người không biết rằng nhiều CSDL không hỗ trợ auto increment.

[kenphan19]

http://stackoverflow.com/questions/1...s-like-youtube
Cũng như topic này chứ cũng chả có gì ! quay qua về lại vẫn bấy nhiêu người có ý kiến trùng nhau. Tốt nhất thì tùy vào hệ thống mà sử dụng solution.

base62 or base64 encode your primary key's value then store it in another field.

example base62 for primary key 12443 = 3eH

saves some space, which is why im sure youtube is using it.

doing a base62(A-Za-z0-9) encode on your PK or unique identifier will prevent the overhead of having to check to see if the key already exists

vãi hà

[BnoL]

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)

Tôi cũng không nghĩ là nó dùng PK là autoincrement int sau đó encryption qua varchar để tạo ra URL trông có vẻ "huyền bí". Việc gì phải chuyển qua chuyển qua chuyển lại như vậy cho down performance vậy? Mà autoincrement cũng không thể scale tốt. Cách hiệu quả nhất là CSDL của Youtube và Google dùng chính varchar hoặc char làm primary key. Nếu ai có ý kiến khác thì cho giải thích hợp lí chứ đừng reply hời hợt như bác trên.

- Tại sao lại không nhỉ? Base trên phần ban đầu bạn phân tích về ưu và nhược điểm thì encryption có thể giải quyết được vấn đề:
1/ Vẫn giữ được ưu điểm của bạn nêu ra vì bản chất nó vẫn là int ai.
2/ Khắc phục được tất cả các nhược điểm bạn đã nêu. Chỉ cần không cho user access record = PK (int).
3/ Việc down performance là không đáng kể so với việc bạn dùng varchar làm PK. Chưa kể việc tạo và quản lý FK dễ dàng hơn so với varchar.

[khonggiannet]

- Tại sao lại không nhỉ? Base trên phần ban đầu bạn phân tích về ưu và nhược điểm thì encryption có thể giải quyết được vấn đề:
1/ Vẫn giữ được ưu điểm của bạn nêu ra vì bản chất nó vẫn là int ai.
2/ Khắc phục được tất cả các nhược điểm bạn đã nêu. Chỉ cần không cho user access record = PK (int).
3/ Việc down performance là không đáng kể so với việc bạn dùng varchar làm PK. Chưa kể việc tạo và quản lý FK dễ dàng hơn so với varchar.

Nếu vậy thì vấn đề sống còn là phải bảo đảm được thuật toán encryption 2 chiều đó là không ai biết. Vì nếu có người biết thuật toán đó thì họ có thể dò ra PK và cái nhược điểm của cách dùng auto increment lại lộ rõ (http://en.wikipedia.org/wiki/Surroga...Surrogate_Keys).

Youtube dùng varchar trong URL vì không muốn bị nhược điểm trên. Tuy nhiên tôi không tin tưởng lắm vào việc tồn tại một thuật toán encryption đơn giản (để đảm bảo performance) mà không ai mò ra được trong ngần ấy năm.

Dù sao ý kiến của bạn cũng có khả năng. Thanks.

[BnoL]

Nếu vậy thì vấn đề sống còn là phải bảo đảm được thuật toán encryption 2 chiều đó là không ai biết. Vì nếu có người biết thuật toán đó thì họ có thể dò ra PK và cái nhược điểm của cách dùng auto increment lại lộ rõ (http://en.wikipedia.org/wiki/Surroga...Surrogate_Keys).

Youtube dùng varchar trong URL vì không muốn bị nhược điểm trên. Tuy nhiên tôi không tin tưởng lắm vào việc tồn tại một thuật toán encryption đơn giản (để đảm bảo performance) mà không ai mò ra được trong ngần ấy năm.

Dù sao ý kiến của bạn cũng có khả năng. Thanks.

Một thuật toán encryption luôn có password kết hợp w input để generate ra output (như vBB có salt kết hợp w password vậy). Cùng 1 thuật toán encryption nhưng khác password thì output ra sẽ khác. Nên trừ khi bạn để lộ password thì k ai mò, decrypt ra đc

[pcdinh]

Khi nào các bạn tự build và quản lý hệ thống streaming như YouTube hoặ ít nhất thì như clip.vn thì các bạn sẽ hiểu được vấn đề thôi.

Bàn về distributed system mà dùng các thuật ngữ hoàn toàn lệch lạc như varchar với cái gì đó là ko hiểu vấn đề. Bạn ko thể dùng kiến thức hay kinh nghiệm thiết kế 1 relational database chạy trên 1 server để bàn về hệ thống có hàng ngàn server và chẳng có gì chắc là họ dùng relational database.

+ Censored URL ko có nghĩa là mã hóa 2 chiều. Key của video trên YouTube giống nhau không có nghĩa là chúng được sinh ra bởi 1 thuật toán hay một secret key.
+ Dùng ID có cả chữ ko có nghĩa là dùng varchar trên DB
+ Dùng sequential ID ko chắc là cách làm của các site có write cỡ lớn như YouTube vì bottleneck và vì chẳng ai lại sinh key trên 1 server khi khối lượng công việc cần phải phân tán.

[=========> Bổ sung bài viết <=========]

ko xài id thì khó order by đó bác
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

Vậy em toàn order theo ID à . Khi ko chỉ định cột để order tì MyISAM order theo thứ tự insert, còn InnoDB thì đã sinh row ID nội bộ và order theo cái cột ẩn đó