Internet chứa đầy những nguyên tắc giáo điều về cách chọn và sử dụng các khóa trong cơ sở dữ liệu quan hệ. Đôi khi các tranh chấp thậm chí biến thành holivars: nên sử dụng khóa tự nhiên hay nhân tạo? Tự động tăng số nguyên hoặc UUID? Show Sau khi đọc sáu mươi bốn bài báo, lướt qua các phần của năm cuốn sách và đặt rất nhiều câu hỏi về IRC và StackOverflow, tôi (Joe "begriffs" Nelson, tác giả của bài báo gốc) dường như đã ghép các mảnh ghép lại với nhau và bây giờ có thể hòa giải các đối thủ. Nhiều tranh chấp quan trọng thực sự phát sinh từ sự hiểu lầm về quan điểm của người khác. Hãy tách vấn đề ra và đặt nó lại với nhau ở phần cuối. Trước tiên, hãy đặt câu hỏi - "chìa khóa" là gì? Hãy tạm quên các khóa chính đi, chúng ta quan tâm đến một ý tưởng tổng quát hơn. Key là một cột (column) hoặc các cột không có giá trị trùng lặp trong rows . Ngoài ra, các cột phải là duy nhất tối giản, tức là không có tập hợp con nào của các cột có tính duy nhất này. Nhưng trước tiên, một số lý thuyết: khóa chính Khóa chínhđược sử dụng trực tiếp để xác định các hàng trong bảng. Nó phải tuân thủ các hạn chế sau:
Thông thường, khóa chính đại diện cho một cột duy nhất của bảng, nhưng nó cũng có thể là khóa tổng hợp bao gồm nhiều cột. Tổ hợp phím Khóa tùy chỉnh- sự kết hợp của các thuộc tính (cột) xác định duy nhất mỗi hàng của bảng. Nó có thể là tất cả các cột, một số và một. Trong trường hợp này, không nên lặp lại các dòng chứa giá trị của các thuộc tính này. chìa khóa tiềm năng khóa ứng cử viên- đại diện cho khóa tổng hợp tối thiểu của quan hệ (bảng), nghĩa là một tập hợp các thuộc tính thỏa mãn một số điều kiện:
5.2 Trường hợp kỳ lạ của khóa chínhCái mà chúng ta vừa gọi là “khóa” trong phần trước thường được gọi là “khóa ứng viên”. Thuật ngữ "ứng cử viên" ám chỉ rằng tất cả các khóa như vậy đều cạnh tranh vai trò danh dự là "khóa chính" (primary key), còn lại được gán cho "khóa thay thế" (alternate keys). Phải mất một thời gian để các triển khai SQL vượt qua sự không phù hợp giữa các khóa và mô hình quan hệ, và các cơ sở dữ liệu sớm nhất hướng tới khái niệm cấp thấp về khóa chính. Các khóa chính trong cơ sở dữ liệu như vậy được yêu cầu để xác định vị trí thực của một hàng trên phương tiện lưu trữ tuần tự. Đây là cách Joe Celko giải thích: Thuật ngữ "khóa" có nghĩa là khóa sắp xếp tệp, cần thiết để thực hiện bất kỳ thao tác xử lý nào trên hệ thống tệp tuần tự. Một bộ thẻ đục lỗ được đọc theo một và chỉ một thứ tự; không thể quay lại. Các ổ đĩa băng ban đầu bắt chước hành vi tương tự và không cho phép truy cập hai chiều. Nghĩa là, Sybase SQL Server ban đầu được yêu cầu "tua ngược" bảng về đầu để đọc hàng trước đó. Trong SQL hiện đại, bạn không cần tập trung vào biểu diễn vật lý của thông tin, các mối quan hệ mô hình bảng và thứ tự bên trong của các hàng hoàn toàn không quan trọng. Tuy nhiên, ngay cả bây giờ máy chủ SQL theo mặc định tạo chỉ mục nhóm cho các khóa chính và theo truyền thống cũ, sắp xếp vật lý thứ tự của các hàng. Trong hầu hết các cơ sở dữ liệu, các khóa chính đã là dĩ vãng và cung cấp ít hơn một vị trí phản chiếu hoặc vị trí thực. Ví dụ: trong bảng PostgreSQL, việc khai báo khóa chính sẽ tự động thực thi một ràng buộc Khóa chính không ghi đè khả năng khai báo các khóa khác. Đồng thời, nếu không có khóa nào được chỉ định làm khóa chính thì bảng vẫn hoạt động tốt. Trong mọi trường hợp, sét sẽ không đánh bạn. 5.3 Tìm khóa tự nhiênCác khóa được thảo luận ở trên được gọi là "tự nhiên" vì chúng là các thuộc tính của đối tượng được mô hình hóa mà bản thân chúng rất thú vị, ngay cả khi không ai muốn tạo khóa từ chúng.  Điều đầu tiên cần nhớ khi kiểm tra một bảng để tìm các khóa tự nhiên có thể có là cố gắng đừng quá thông minh. Người dùng sqlvogel trên StackExchange đưa ra lời khuyên sau: Một số người gặp khó khăn trong việc chọn khóa "tự nhiên" vì họ đưa ra các tình huống giả định trong đó một khóa cụ thể có thể không phải là duy nhất. Họ không hiểu ý nghĩa của nhiệm vụ. Ý nghĩa của khóa là xác định quy tắc theo đó các thuộc tính tại bất kỳ thời điểm nào phải là duy nhất trong một bảng cụ thể. Bảng chứa dữ liệu trong một ngữ cảnh cụ thể và được hiểu rõ (trong "lĩnh vực chủ đề" hoặc "lĩnh vực diễn ngôn") và ý nghĩa duy nhất là ứng dụng của sự hạn chế trong lĩnh vực cụ thể đó. Thực tế cho thấy rằng cần phải đưa ra một ràng buộc chính khi cột là duy nhất với các giá trị khả dụng và sẽ duy trì như vậy trong các tình huống có thể xảy ra. Và nếu cần, hạn chế có thể được gỡ bỏ (nếu điều này làm phiền bạn, thì bên dưới chúng tôi sẽ nói về độ ổn định của phím.) Ví dụ: cơ sở dữ liệu về các thành viên câu lạc bộ sở thích có thể có tính duy nhất trong hai cột - Khi cơ sở dữ liệu phát triển và khối lượng thông tin tăng lên, việc chọn khóa tự nhiên có thể trở nên khó khăn hơn. Dữ liệu chúng tôi lưu trữ là sự đơn giản hóa của thực tế bên ngoài và không chứa một số khía cạnh phân biệt các đối tượng trên thế giới, chẳng hạn như tọa độ của chúng thay đổi theo thời gian. Nếu một đối tượng không có bất kỳ mã nào, làm thế nào bạn có thể phân biệt hai lon nước uống hoặc hai hộp bột yến mạch ngoài cách sắp xếp không gian hoặc sự khác biệt nhỏ về trọng lượng hoặc bao bì? Đó là lý do tại sao các cơ quan tiêu chuẩn hóa tạo ra và áp dụng các dấu hiệu phân biệt cho các sản phẩm. Các phương tiện được đóng dấu với Số nhận dạng phương tiện (VIN) , sách được in ISBN và bao bì thực phẩm có UPC . Bạn có thể phản đối rằng những con số này có vẻ không tự nhiên. Vậy tại sao tôi gọi chúng là khóa tự nhiên? Tính tự nhiên hoặc tính nhân tạo của các thuộc tính duy nhất trong cơ sở dữ liệu có liên quan đến thế giới bên ngoài. Một chìa khóa giả tạo khi nó được tạo ra trong cơ quan tiêu chuẩn hoặc cơ quan chính phủ trở nên tự nhiên đối với chúng tôi, bởi vì nó trở thành tiêu chuẩn trên toàn thế giới và / hoặc được in trên các vật thể. Có nhiều tiêu chuẩn công nghiệp, công cộng và quốc tế cho nhiều chủ đề khác nhau, bao gồm tiền tệ, ngôn ngữ, công cụ tài chính, hóa chất và chẩn đoán y tế. Dưới đây là một số giá trị thường được sử dụng làm khóa tự nhiên:
Tôi khuyên bạn nên khai báo khóa bất cứ khi nào có thể và hợp lý, thậm chí có thể nhiều khóa trên mỗi bảng. Nhưng hãy nhớ rằng tất cả những điều trên có thể có ngoại lệ.
5.4 Chìa khóa nhân tạoCho rằng khóa là một cột có các giá trị duy nhất trong mỗi hàng, một cách để tạo nó là gian lận - bạn có thể viết các giá trị duy nhất hư cấu trong mỗi hàng. Đây là các khóa nhân tạo: mã được phát minh dùng để chỉ dữ liệu hoặc đối tượng. Điều rất quan trọng là mã được tạo từ chính cơ sở dữ liệu và không ai biết ngoại trừ người dùng cơ sở dữ liệu. Đây là điểm phân biệt các khóa nhân tạo với các khóa tự nhiên được tiêu chuẩn hóa. Mặc dù các khóa tự nhiên có ưu điểm là bảo vệ khỏi các hàng trùng lặp hoặc không nhất quán trong một bảng, nhưng các khóa nhân tạo rất hữu ích vì chúng giúp con người hoặc các hệ thống khác tham chiếu hàng dễ dàng hơn, đồng thời tăng tốc độ tra cứu và tham gia vì chúng không sử dụng so sánh chuỗi (hoặc nhiều cột).keys. người thay thếCác khóa nhân tạo được sử dụng làm điểm neo - bất kể quy tắc và cột thay đổi như thế nào, một hàng luôn có thể được xác định theo cùng một cách. Khóa nhân tạo được sử dụng cho mục đích này được gọi là "khóa thay thế" và cần được chú ý đặc biệt. Chúng tôi sẽ xem xét các đại diện dưới đây. Các khóa nhân tạo không thay thế rất hữu ích để tham chiếu một hàng từ bên ngoài cơ sở dữ liệu. Khóa nhân tạo xác định ngắn gọn dữ liệu hoặc đối tượng: nó có thể được chỉ định dưới dạng URL, được đính kèm với hóa đơn, được đọc qua điện thoại, được lấy từ ngân hàng hoặc được in trên biển số xe. (Biển số ô tô là chìa khóa tự nhiên đối với chúng tôi, nhưng được chính phủ thiết kế như một chìa khóa nhân tạo.) Các khóa tổng hợp nên được chọn có tính đến các phương tiện truyền tải có thể để giảm thiểu lỗi chính tả và lỗi. Cần lưu ý rằng khóa có thể được nói, đọc được in ra, gửi qua SMS, đọc viết tay, nhập từ bàn phím và được nhúng trong một URL. Ngoài ra, một số khóa nhân tạo, chẳng hạn như số thẻ tín dụng, chứa tổng kiểm tra để nếu xảy ra lỗi nhất định, ít nhất chúng có thể được nhận ra. Ví dụ:
Hãy nhớ rằng ngay khi bạn giới thiệu chiếc chìa khóa nhân tạo của mình với thế giới, mọi người sẽ bắt đầu chú ý đặc biệt đến nó một cách kỳ lạ. Chỉ cần nhìn vào biển số xe của "những tên trộm" hoặc vào hệ thống tạo số nhận dạng có thể phát âm được, hệ thống này đã trở thành công cụ tạo lời nguyền tự động khét tiếng. Ngay cả khi chúng ta giới hạn bản thân với các phím số, thì vẫn có những điều cấm kỵ như tầng mười ba. Mặc dù các proquint có mật độ thông tin cao hơn trên mỗi âm tiết được nói, nhưng các con số cũng tốt theo nhiều cách: trong URL, bàn phím ghim và ghi chú viết tay, miễn là người nhận biết khóa chỉ là các con số. Tuy nhiên, xin lưu ý rằng bạn không nên sử dụng thứ tự tuần tự trong các khóa số công khai, vì điều này cho phép bạn lục lọi tài nguyên (/videos/1.mpeg, /videos/2.mpeg, v.v.) và cũng làm rò rỉ thông tin về số dữ liệu. Đặt mạng lưới Feistel chồng lên trên một dãy số và bảo toàn tính duy nhất trong khi ẩn thứ tự của các số. Đối số duy nhất chống lại việc khai báo các khóa bổ sung là mỗi khóa mới mang theo một chỉ mục duy nhất khác và làm tăng chi phí ghi vào bảng. Tất nhiên, nó phụ thuộc vào mức độ quan trọng của tính chính xác của dữ liệu đối với bạn, nhưng rất có thể, các khóa vẫn phải được khai báo. Cũng đáng để khai báo một số khóa nhân tạo, nếu có. Ví dụ: một tổ chức có các ứng viên (Ứng viên) và nhân viên (Nhân viên). Mỗi nhân viên đã từng là một ứng viên và đề cập đến các ứng viên bằng mã định danh riêng của họ, đây cũng là mã khóa của nhân viên. Một ví dụ khác, bạn có thể đặt ID nhân viên và tên đăng nhập làm hai khóa trong Nhân viên. 5.5 Khóa thay thếNhư đã đề cập, một loại khóa nhân tạo quan trọng được gọi là "khóa thay thế". Nó không cần phải ngắn gọn và dễ hiểu như các khóa nhân tạo khác, nhưng được sử dụng như một nhãn bên trong luôn xác định chuỗi. Nó được sử dụng trong SQL, nhưng ứng dụng không truy cập nó một cách rõ ràng. Nếu bạn đã quen thuộc với các cột hệ thống của PostgreSQL, thì bạn có thể coi các đại lượng thay thế gần như là một tham số triển khai cơ sở dữ liệu (như ctid), tuy nhiên, tham số này không bao giờ thay đổi. Giá trị thay thế được chọn một lần trên mỗi hàng và không bao giờ thay đổi sau đó. Khóa thay thế tuyệt vời như khóa ngoại và các ràng buộc xếp tầng phải được chỉ định Mặt khác, khóa ngoại đối với khóa được chia sẻ công khai phải được đánh dấu bằng Đừng tạo khóa thay thế "tự nhiên". Khi bạn hiển thị giá trị của khóa thay thế cho người dùng cuối hoặc tệ hơn là để họ làm việc với giá trị đó (đặc biệt là thông qua tra cứu), bạn đang cung cấp cho khóa một giá trị một cách hiệu quả. Sau đó, khóa được hiển thị từ cơ sở dữ liệu của bạn có thể trở thành khóa tự nhiên trong cơ sở dữ liệu của người khác. Việc buộc các hệ thống bên ngoài sử dụng các khóa nhân tạo khác được thiết kế đặc biệt để truyền cho phép chúng tôi thay đổi các khóa đó khi cần để đáp ứng nhu cầu thay đổi, đồng thời duy trì tính toàn vẹn tham chiếu nội bộ với các khóa thay thế. Tự động tăng INT/BIGINTCách sử dụng phổ biến nhất cho các khóa thay thế là cột "bigserial" tự động tăng , còn được gọi là IDENTITY . (Trên thực tế, PostgreSQL 10 hiện hỗ trợ cấu trúc IDENTITY, cũng như Oracle, xem TẠO BẢNG.) Tuy nhiên, tôi tin rằng số nguyên tăng tự động là một lựa chọn tồi cho các khóa thay thế. Ý kiến này không phổ biến, vì vậy hãy để tôi giải thích. Nhược điểm của khóa nối tiếp:
UUIDHãy xem xét một tùy chọn khác: sử dụng các số nguyên lớn (128-bit) được tạo theo một mẫu ngẫu nhiên. Các thuật toán để tạo mã định danh duy nhất toàn cầu (UUID) như vậy có xác suất chọn cùng một giá trị hai lần rất thấp, ngay cả khi chạy trên hai bộ xử lý khác nhau cùng một lúc. Trong trường hợp đó, UUID có vẻ như là một lựa chọn tự nhiên để sử dụng làm khóa thay thế, phải không? Nếu bạn muốn gắn nhãn các hàng theo một cách độc đáo, thì không gì có thể đánh bại một nhãn duy nhất! Vậy tại sao không phải ai cũng sử dụng chúng trong PostgreSQL? Có một số lý do giả định cho điều này và một lý do hợp lý có thể giải quyết được, và tôi sẽ trình bày các điểm chuẩn để minh họa quan điểm của mình. Đầu tiên, tôi sẽ nói về những lý do xa vời. Một số người nghĩ rằng UUID là các chuỗi vì chúng được viết theo ký hiệu thập lục phân truyền thống với dấu gạch ngang: UUID cũng bị buộc tội là cồng kềnh, nhưng ai sẽ phát âm, gõ hoặc đọc chúng? Chúng tôi đã nói rằng việc hiển thị các khóa nhân tạo là hợp lý, nhưng không ai (theo định nghĩa) sẽ thấy UUID thay thế. Có thể UUID sẽ được xử lý bởi một nhà phát triển đang chạy các lệnh SQL trong psql để gỡ lỗi hệ thống, nhưng đó là về nó. Và nhà phát triển cũng có thể tham khảo các chuỗi bằng cách sử dụng các khóa thuận tiện hơn, nếu chúng được cung cấp. Vấn đề thực sự với UUID là các giá trị được ngẫu nhiên hóa cao dẫn đến khuếch đại ghi do ghi toàn bộ trang vào nhật ký ghi trước (WAL) . Tuy nhiên, sự suy giảm hiệu suất thực sự phụ thuộc vào thuật toán tạo UUID. Hãy đo khuếch đại ghi . Trên thực tế, vấn đề nằm ở các hệ thống tệp cũ hơn. Khi PostgreSQL ghi vào đĩa, nó sẽ thay đổi "trang" trên đĩa. Nếu bạn tắt nguồn máy tính, hầu hết các hệ thống tệp vẫn báo ghi thành công trước khi dữ liệu được lưu trữ an toàn trên đĩa. Nếu PostgreSQL ngây thơ nhận thấy một hành động như vậy là đã hoàn thành, thì cơ sở dữ liệu sẽ bị hỏng trong lần khởi động hệ thống tiếp theo. Vì PostgreSQL không thể tin tưởng hầu hết các hệ điều hành/hệ thống tệp/cấu hình đĩa để cung cấp tính liên tục, nên cơ sở dữ liệu sẽ lưu toàn bộ trạng thái của trang đĩa đã thay đổi vào nhật ký ghi trước có thể được sử dụng để khôi phục sau sự cố có thể xảy ra. Lập chỉ mục các giá trị được ngẫu nhiên hóa cao như UUID thường liên quan đến một loạt các trang đĩa khác nhau và dẫn đến kích thước trang đầy đủ (thường là 4 hoặc 8 KB) được ghi vào WAL cho mỗi mục nhập mới. Đây được gọi là viết toàn trang (viết toàn trang, FPW). Một số thuật toán tạo UUID (chẳng hạn như "bông tuyết" của Twitter hoặc uuid_generate_v1() trong tiện ích mở rộng uuid-ossp của PostgreSQL) tạo ra các giá trị tăng dần đơn điệu trên mỗi máy. Cách tiếp cận này hợp nhất việc ghi vào ít trang đĩa hơn và giảm FPW. 5.6 Kết luận và khuyến nghịBây giờ chúng ta đã thấy các loại khóa khác nhau và cách sử dụng chúng, tôi muốn liệt kê các đề xuất của mình để sử dụng chúng trong cơ sở dữ liệu của bạn. Đối với mỗi bảng:
Cách tiếp cận này đảm bảo tính ổn định của các khóa bên trong đồng thời cho phép và thậm chí bảo vệ các khóa tự nhiên. Ngoài ra, các khóa nhân tạo có thể nhìn thấy không được gắn vào bất kỳ thứ gì. Khi đã hiểu mọi thứ một cách chính xác, bạn không thể chỉ dừng lại ở "các phím chính" và sử dụng tất cả các khả năng sử dụng các phím. Trong mô hình dữ liệu quan hệ khóa chính là gì?Khái niệm khóa trong mô hình dữ liệu quan hệ Mô hình dữ liệu quan hệ được hình thành bởi việc sử dụng khóa chính và khóa ngoại để tạo ra và giúp liên kết mối quan hệ giữa các bảng. - Khóa chính (Primary Key) có thể hiểu chính là sử dụng các cột trong bảng để giúp bảo đảm được tính duy nhất và định danh cho mỗi hàng. Khóa của một quan hệ là gì?Định nghĩa: Cho quan hệ r( R ), tập K ⊂ R được gọi là khóa của quan hệ r nếu:K+=R nếu bớt một phần tử khỏi K thì bao đóng của nó sẽ khác R. Như thế tập K ⊂ R nếu K+=R và ( K \ A )+ ≠ R , ∀ A ⊂ R. Mô hình dữ liệu quan hệ là gì?Mô hình quan hệ dữ liệu, tiếng anh là Relational Data Model, biểu diễn cơ sở dữ liệu dưới dạng một tập hợp các quan hệ, trong đó một quan hệ là một bảng chứa các giá trị của các dữ liệu. Mỗi hàng trong bảng đại diện cho các giá trị của dữ liệu đó. Khóa của một bạn là gì?Khóa chính là một trường hoặc tập hợp trường chứa các giá trị duy nhất xuyên suốt một bảng. Bạn có thể sử dụng các giá trị của khóa để tham chiếu tới toàn bộ các bản ghi, do mỗi bản ghi lại có một giá trị khóa khác nhau. Mỗi bảng chỉ có thể có một khóa chính. |
