# 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
CHỨNG KHOÁN RỒNG VIỆT tuyển **Chuyên viên Vận hành Core ($600-1000)**
----------------------------------------------
⭐️⭐️ Chi tiết: https://bit.ly/2VHjziT
✅ YÊU CẦU
- Kỹ năng viết SQL (DB2, SQL,Oracle) tốt, tối ưu câu lệnh.
- Có kinh nghiệm làm việc với các hệ quản trị cơ sơ dữ liệu SQL Server, Oracle , DB2
✅ Lương cạnh tranh, phúc lợi cực kỳ hấp dẫn: thưởng T13,14,15,..., thưởng dự án, BHXH, BHYT, BHTN, BH sức khỏe AON, du lịch, trợ cấp trang phục, cơm trưa, CLB yoga, bóng đá, ...
✅ Thời gian làm việc từ T2-T6, Quận 1
✅Làm việc cùng các chuyên gia giàu kinh nghiệm
Ứng viên quan tâm vui lòng gửi CV về email tuyendung@vdsc.com.vn để được phỏng vấn ngay nhé!
LH: Ms.Thi 0326129902 / www.vdsc.com.vn
----------------------------------------
#tuyendung #tuyển_dụng #androiddevelopment #android #software #java #dev #webdeveloper #webdev #objectivec #J2EE #DB2 #oracle #net #devops #coreoperations #securities #net #devop #react #sqlserver #core #corebanking #database #CSDL [#j2team_job](https://www.facebook.com/hashtag/j2team_job?hc_location=ufi)
#J2TeaM góc tìm đồng dâm
Cho mình hỏi trong group có anh em nào nghiên cứu về malware hay đang làm về malware không nhỉ, mình muốn trao đổi chút :D
Lưu ý không phải viết hay đi dắc malware như dắc thính nhé mà là về phát hiện và xây dựng database để chống !
#malware #database #detected