Danh sách bài viết theo tags- J2Team's Group Tool by Trợ lý Bé Điệu

Ngày tạo: 22-05-2021 lúc 05:50:30

Thay đổi lần cuối: 25-05-2021 lúc 16:49:39

# Khoá chính trong DB (primary key/PK) vì sao nên là Auto Increment Integer? Dùng dạng khác thì sẽ ảnh hưởng thế nào?

Đây là một câu hỏi hay. Vì để trả lời được chúng ta cần một chút kiến thức về Primary Key cơ bản.

## PK có 2 đặc tính quan trọng:
1. Unique (not null): không thể có 2 record có cùng giá trị PK và không thể là null.
1. Là một Index B-Tree, tuy nhiên nó sắp xếp record data vật lý luôn. (Có thể không đúng với mọi DB, tuy nhiên hầu với hết các RDBMS là vậy)

Vì thế khi query với PK sẽ có tốc độ rất nhanh, vì nó tìm thẳng mặt và trực tiếp. Giống như các bạn tìm trang X trong 1 quyển sách sẽ nhanh hơn các bạn tìm 1 keyword Y xuất hiện ở dòng nào, vì sẽ cần tìm trong index để ra được số trang mà Y có xuất hiện (tức là thêm một bước).

OK OK cái này ai cũng biết. Vấn đề sẽ nằm ở không gian lưu trữ và tốc độ INSERT/DELETE (change)

Vào việc chính thôi, PK nếu là số Integer thì sẽ gọn nhẹ, tiết kiệm không gian bộ nhớ, băng thông truy xuất. Phối hợp cùng Auto Increment (AI) thì ta đỡ tốn công đi generate unique ID, việc này sẽ tốn cost kha khá tuỳ thuật toán bạn đang sử dụng.

Đối với Unique ID dạng unique random (VD: UUID) thì khi DB insert vào sẽ tốn một loại COST ít ai để ý: thời gian tìm kiếm vị trí để insert cái record mới vào. Giá trị Unique ID khi random sẽ thường (hầu như) KHÔNG PHẢI GIÁ TRỊ LỚN NHẤT, tức là đâu đó ở giữa. Insert 1 node vào giữa B-Tree phức tạp thế nào các bạn tham khảo ở link: https://webdocs.cs.ualberta.ca/~holte/T26/ins-b-tree.html

Điều này tương tự khi chúng ra DELETE 1 record, DB cần build lại index tree. Hãy nhớ số lượng record càng lớn thì càng mất nhiều thời gian. Với UPDATE thì... à chả ai dại gì đi thay đổi PK nhỉ?!!

## THẾ NHƯNG đôi khi chúng ta không muốn dùng PK dạng AI để:
* PK có ý nghĩa hơn (cấu trúc có mục đích của người thiết kế, VD barcode)
* PK trên nhiều cột (thường là các bảng trung gian cho mối quan hệ Many-To-Many)
* PK trên những table có mối quan hệ 1-1 (bên kia xài PK kiểu gì thì bên này phải là kiểu đó, đương nhiên)
* PK quá dễ đoán nên dễ bị "cào" dữ liệu (*)

(*) Vẫn có cách đơn giản hơn để dùng lại AI mà không cần thay đổi structure của PK hoặc tạo thêm cột mới. Đương nhiên giữa security và performance là 2 đầu cán cân, vì thế bạn muốn trọng bên nào nên cân nhắc kỹ.

NOTE: các bạn share thì nên ở chế độ public để cùng lan toả kiến thức cho cộng đồng, cũng như động viên mình share tiếp nha.

#j2team_share #technote #sharing #primarykey #database

Link bài gốc của mình: https://www.facebook.com/photo/?fbid=4626112654083484&set=a.547824198579037