Những bảng cụ thể này cần khóa thay thế?

Lý lịch

Tôi có cái bàn này

+-------------------------+  +------------------------+
|Airport                  |  |Country                 |
|-------------------------|  |------------------------|
|airport_code string (PK) |  |country_code string (PK)|
|address string           |  |name string             |
|name  string             |  +------------------------+
+-------------------------+

+-------------------------+
|Currency                 |
|-------------------------|
|currency_code string (PK)|
|name string              |
+-------------------------+

sân bay_code là mã sân bay IATA (Hiệp hội vận tải hàng không quốc tế) , bạn có thể nhìn thấy chúng trong thẻ hành lý của bạn khi bạn đi bằng máy bay.

country_code là mã quốc gia tiêu chuẩn ISO 3166-1 A3 , bạn có thể thấy chúng trong olympics.

tệ_code là mã tiền tệ 3 ký tự tiêu chuẩn IS0 417 , bạn có thể thấy chúng trong các bảng hiển thị trao đổi tiền tệ quốc tế.

Câu hỏi

Những PK tự nhiên này có đủ tốt không?

Là sử dụng các tiêu chuẩn tôn trọng thế giới, được chấp nhận bởi toàn bộ ngành công nghiệp đủ tốt cho PK?

Làm bảng này cần người thay thế không có vấn đề gì?

Không, họ không. Những chìa khóa đó chắc chắn là đủ tốt!

Chúng là duy nhất, không hiếm khi thay đổi và có ý nghĩa , đó là một bước tiến lên trên một khóa thay thế. Đó là khá nhiều định nghĩa của một PK tốt.

Các hạn chế về PK là bất biến và số nguyên không phải là một phần của Mô hình quan hệ (Codd's) hoặc bất kỳ tiêu chuẩn SQL nào (ANSI hoặc khác).

Tôi nghĩ rằng nhu cầu là một từ rất mạnh mẽ và theo một nghĩa nghiêm ngặt, các bảng có thể không cần khóa thay thế .

Tuy nhiên, nếu đó là cơ sở dữ liệu của tôi, tôi có thể sẽ thêm khóa thay thế. Tôi có thể không nhất thiết muốn thiết kế cơ sở dữ liệu của mình phụ thuộc vào một nhóm các bên thứ ba (IATA, ISO), bất kể tiêu chuẩn của họ ổn định đến mức nào. Hoặc, tôi có thể không muốn phụ thuộc vào một tiêu chuẩn cụ thể nào cả (có tiêu chuẩn mã tiền tệ nào khác không? Tôi không biết). Tôi có thể mô hình hóa các bảng của mình với các khóa thay thế như vậy:

+-------------------------+  +------------------------+
|Airport                  |  |Country                 |
|-------------------------|  |------------------------|
|airport_id       int (PK)|  |country_id     int (PK) |
|iata_airport_code string |  |iso_country_code string |
|icao_airport_code string |  +------------------------+
|faa_identifier    string |  
|address           string |  
|name              string |  
+-------------------------+

+-------------------------+
|Currency                 |
|-------------------------|
|currency_id int (PK)     |
|iso_currency_code string |
|name string              |
+-------------------------+

Nói cách khác, trừ khi các mã tiêu chuẩn công nghiệp đó vốn đã quan trọng đối với ứng dụng của tôi, tôi sẽ không sử dụng chúng làm PK trong các bảng của mình. Chúng chỉ là nhãn hiệu. Hầu hết các bảng khác của tôi có thể sẽ có các khóa thay thế và thiết lập này sẽ thêm tính nhất quán cho mô hình dữ liệu của tôi. Chi phí 'thêm' các khóa thay thế là tối thiểu.

Cập nhật dựa trên một số ý kiến:

Không biết ngữ cảnh của các bảng ví dụ, không thể biết những điều quan trọng như Mã sân bay IATA đối với ứng dụng sử dụng cơ sở dữ liệu như thế nào. Rõ ràng, nếu các mã IATA là trọng tâm tập trung và được sử dụng phổ biến trong toàn bộ ứng dụng, thì đó có thể là quyết định chính xác, sau khi phân tích chính xác, sử dụng mã làm PK của bảng.

Tuy nhiên, nếu bảng chỉ là bảng tra cứu được sử dụng ở một vài góc của ứng dụng, tầm quan trọng tương đối của mã IATA có thể không chứng minh được vị trí nổi bật như vậy trong cơ sở hạ tầng cơ sở dữ liệu. Chắc chắn, bạn có thể phải tham gia thêm vào một vài truy vấn ở đây và đó, nhưng nỗ lực đó có thể là tầm thường so với nỗ lực cần có để thực hiện nghiên cứu để đảm bảo rằng bạn hiểu đầy đủ ý nghĩa của việc tạo mã IATA trường khóa chính. Trong một số trường hợp, không chỉ tôi không quan tâm, mà tôi không muốn phải quan tâm đến mã IATA. @James Nhận xét của Snell dưới đây là một ví dụ hoàn hảo về điều mà tôi có thể không muốn phải lo lắng về việc ảnh hưởng đến PK của các bảng của mình.

Ngoài ra, tính nhất quán trong thiết kế là quan trọng. Nếu bạn có một cơ sở dữ liệu với hàng tá bảng, tất cả đều được thiết kế khóa thay thế một cách nhất quán, và sau đó một vài bảng tra cứu đang sử dụng mã của bên thứ 3 dưới dạng PK, điều đó đưa ra sự không nhất quán. Điều đó không hoàn toàn xấu, nhưng nó đòi hỏi sự chú ý thêm trong tài liệu và những thứ đó có thể không được bảo hành. Chúng là các bảng tra cứu vì lợi ích, chỉ cần sử dụng khóa thay thế cho tính nhất quán là hoàn toàn tốt.

Cập nhật dựa trên nghiên cứu thêm:

Ok, sự tò mò cắn tôi và tôi quyết định thực hiện một số nghiên cứu về mã sân bay IATA cho vui, bắt đầu với các liên kết được cung cấp trong câu hỏi.

Hóa ra, các mã IATA không phổ biến và có thẩm quyền như câu hỏi khiến chúng trở thành hiện thực. Theo trang này :

Hầu hết các quốc gia sử dụng mã ICAO bốn ký tự , không phải mã IATA, trong các ấn phẩm hàng không chính thức của họ.

Ngoài ra, mã IATA và mã ICAO khác với mã Định danh FAA , đây là một cách khác để xác định sân bay.

Quan điểm của tôi khi đưa ra những vấn đề này không phải là bắt đầu một cuộc tranh luận về việc mã nào tốt hơn hay phổ quát hơn hay toàn diện hơn hay toàn diện hơn, nhưng để chỉ ra chính xác lý do tại sao thiết kế cấu trúc cơ sở dữ liệu của bạn xung quanh một định danh bên thứ 3 tùy ý không phải là điều tôi sẽ chọn làm , trừ khi có một lý do kinh doanh cụ thể để làm như vậy .

Trong trường hợp này, tôi cảm thấy cơ sở dữ liệu của mình sẽ có cấu trúc tốt hơn, ổn định hơn và linh hoạt hơn, bằng cách gửi mã IATA (hoặc bất kỳ bên thứ 3 nào, mã có khả năng thay đổi) làm ứng cử viên khóa chính và sử dụng khóa thay thế. Bằng cách làm như vậy, tôi có thể từ bỏ bất kỳ cạm bẫy tiềm năng nào có thể mọc lên do lựa chọn khóa chính.

Mặc dù có các khóa thay thế trên các trường là tốt và không có gì sai khi điều đó cần xem xét có thể là kích thước trang chỉ mục.

Vì đây là cơ sở dữ liệu quan hệ, bạn sẽ thực hiện nhiều phép nối và có khóa thay thế kiểu số có thể giúp cơ sở dữ liệu dễ dàng xử lý hơn, tức là kích thước trang chỉ mục sẽ nhỏ hơn và do đó tìm kiếm nhanh hơn. Nếu đây là một dự án nhỏ, nó sẽ không thành vấn đề và bạn sẽ không gặp phải bất kỳ vấn đề nào, tuy nhiên ứng dụng càng lớn thì bạn càng muốn giảm bớt tắc nghẽn.

Có BIGINT, INT, SMALLINT, TINYINT hoặc bất kỳ loại dữ liệu giống như số nguyên nào có thể giúp bạn tránh khỏi một số rắc rối.

Chỉ 2 xu của tôi

CẬP NHẬT:

Dự án nhỏ - được sử dụng bởi một vài người, thậm chí vài chục người. Quy mô nhỏ, dự án demo, dự án để sử dụng cá nhân, một cái gì đó để thêm vào danh mục đầu tư khi trình bày các kỹ năng của bạn không có kinh nghiệm và tương tự.

Dự án lớn - được sử dụng bởi hàng ngàn, hàng chục nghìn, hàng triệu người dùng hàng ngày. Một cái gì đó bạn xây dựng cho một công ty quốc gia / quốc tế với lượng người dùng khổng lồ.

Thông thường những gì xảy ra là một vài trong số các bản ghi được chọn thường xuyên và máy chủ lưu trữ kết quả để truy cập nhanh, nhưng thỉnh thoảng bạn cần truy cập một số bản ghi ít được sử dụng, tại thời điểm đó, máy chủ sẽ phải nhúng vào chỉ mục trang. (trong ví dụ trên với tên sân bay, mọi người thường bay các hãng hàng không nội địa, nói Chichago -> Los Angeles, nhưng tần suất mọi người bay từ Boston -> Zimbabwe)

Nếu VARCHAR được sử dụng có nghĩa là khoảng cách không đồng nhất, trừ khi dữ liệu luôn có cùng chiều dài (tại thời điểm đó, giá trị CHAR có hiệu quả hơn). Điều này làm cho việc tìm kiếm chỉ mục chậm hơn và với việc máy chủ đang bận xử lý hàng nghìn và hàng nghìn truy vấn mỗi giây, giờ đây nó phải lãng phí thời gian để vượt qua một chỉ mục không thống nhất và thực hiện lại điều tương tự trên các liên kết (chậm hơn chọn thường xuyên trên một bảng không được tối ưu hóa, lấy DW làm ví dụ khi có càng ít phép nối càng tốt để tăng tốc độ truy xuất dữ liệu). Ngoài ra nếu bạn sử dụng UTF cũng có thể gây rối với công cụ cơ sở dữ liệu (Tôi đã thấy một số trường hợp).

Cá nhân, từ kinh nghiệm của riêng tôi, một chỉ mục được tổ chức hợp lý có thể tăng tốc độ tham gia ~ 70% và thực hiện tham gia trên một cột số nguyên có thể tăng tốc độ tham gia lên khoảng ~ 25% (tùy thuộc vào dữ liệu) . Khi các bảng chính bắt đầu phát triển và các bảng này được sử dụng trên chúng, bạn muốn có một kiểu dữ liệu số nguyên chiếm cột có một vài byte so với trường VARCHAR / CHAR sẽ chiếm nhiều không gian hơn. Nó tiết kiệm không gian đĩa, tăng hiệu suất và cấu trúc tổng thể của cơ sở dữ liệu quan hệ.

Ngoài ra, như James Snell đã đề cập:

Khóa chính cũng phải là bất biến, một số mã sân bay IATA chắc chắn là không. Chúng có thể được thay đổi theo ý thích của IATA.

Vì vậy, cân nhắc điều này, bạn có muốn cập nhật 1 bản ghi bị ràng buộc với một số, so với việc phải cập nhật một bản ghi đó cộng với tất cả các bản ghi trong bảng mà bạn tham gia.

Nếu bạn thực hiện phương pháp "Tôi sử dụng khóa thay thế mọi lúc", bạn sẽ bỏ qua loại lo ngại này. Đó có thể không phải là một điều tốt bởi vì điều quan trọng là cung cấp cho dữ liệu của bạn một số suy nghĩ, nhưng chắc chắn nó sẽ tiết kiệm rất nhiều thời gian, sự can thiệp và nỗ lực. Nếu bất cứ ai chấp nhận một quy tắc đối với quy tắc này, các ví dụ được liệt kê chắc chắn đủ điều kiện bởi vì nó cần một "hành động đại hội" gần để thực hiện thay đổi.

Các truy vấn đặc biệt của cơ sở dữ liệu với các khóa tự nhiên này chắc chắn rất hữu ích. Tạo các khung nhìn làm điều tương tự bằng cách bao gồm các bảng tra cứu cũng có thể hoạt động tốt. Cơ sở dữ liệu hiện đại thực hiện công việc tốt hơn nhiều với loại công cụ này đến mức có thể không quan trọng.

Có một số trường hợp cụ thể ở Hoa Kỳ, nơi các tiêu chuẩn đã được thay đổi mạnh mẽ: Mã bưu chính được mở rộng từ 5 - 9 chữ số, Chữ viết tắt của tiểu bang thành 2 chữ cái nhất quán và thoát khỏi thời kỳ (Hãy nhớ khi Illinois bị bệnh.?), Và hầu hết thế giới phải đối phó với Y2K. Nếu bạn có một ứng dụng thời gian thực với dữ liệu lan truyền khắp thế giới chứa hàng tỷ hồ sơ, cập nhật xếp tầng không phải là ý tưởng tốt nhất, nhưng chúng ta có nên làm việc ở những nơi phải đối mặt với những thách thức như vậy không? Với bộ dữ liệu đó, bạn có thể tự kiểm tra nó và đưa ra câu trả lời khác biệt hơn.