Các khóa ngoại có thực sự cần thiết trong thiết kế cơ sở dữ liệu không?

Theo như tôi biết, các khóa ngoại (FK) được sử dụng để hỗ trợ lập trình viên thao tác dữ liệu theo cách chính xác. Giả sử một lập trình viên đã thực sự làm điều này theo đúng cách, thì liệu chúng ta có thực sự cần khái niệm về khóa ngoại không?

Có bất kỳ cách sử dụng nào khác cho khóa ngoại không? Am i thiếu cái gì ở đây?

Khóa ngoại giúp thực thi tính toàn vẹn tham chiếu ở cấp dữ liệu. Chúng cũng cải thiện hiệu suất vì chúng thường được lập chỉ mục theo mặc định.

Các khóa ngoại cũng có thể giúp lập trình viên viết ít mã hơn bằng cách sử dụng những thứ như ON DELETE CASCADE. Điều này có nghĩa là nếu bạn có một bảng chứa người dùng và một bảng khác chứa đơn đặt hàng hoặc thứ gì đó, thì việc xóa người dùng có thể tự động xóa tất cả các đơn hàng trỏ đến người dùng đó.

Tôi không thể tưởng tượng việc thiết kế một cơ sở dữ liệu mà không có khóa ngoại. Nếu không có chúng, cuối cùng bạn nhất định mắc lỗi và làm hỏng tính toàn vẹn của dữ liệu.

Chúng không bắt buộc , nói đúng ra, nhưng lợi ích là rất lớn.

Tôi khá chắc chắn rằng FogBugz không có các ràng buộc khóa ngoại trong cơ sở dữ liệu. Tôi rất muốn nghe cách nhóm Fog Creek Software cấu trúc mã của họ để đảm bảo rằng họ sẽ không bao giờ đưa ra sự mâu thuẫn.

Một lược đồ cơ sở dữ liệu không có ràng buộc FK giống như lái xe mà không có dây an toàn.

Một ngày nào đó, bạn sẽ hối hận. Không dành thêm ít thời gian cho các nguyên tắc cơ bản về thiết kế và tính toàn vẹn của dữ liệu là một cách chắc chắn để đảm bảo các vấn đề đau đầu sau này.

Bạn có chấp nhận đoạn mã cẩu thả đó trong ứng dụng của mình không? Điều đó đã truy cập trực tiếp vào các đối tượng thành viên và trực tiếp sửa đổi cấu trúc dữ liệu.

Tại sao bạn nghĩ rằng điều này đã được thực hiện khó khăn và thậm chí không thể chấp nhận được trong các ngôn ngữ hiện đại?

Đúng.

1. Họ giữ cho bạn trung thực
2. Họ giữ cho các nhà phát triển mới trung thực
3. Bạn có thể làm ON DELETE CASCADE
4. Chúng giúp bạn tạo ra các sơ đồ đẹp tự giải thích các liên kết giữa các bảng

Giả sử một lập trình viên thực sự đang làm điều này theo đúng cách đã

Đưa ra một giả định như vậy đối với tôi dường như là một ý tưởng cực kỳ tồi; nói chung, phần mềm thường gặp nhiều lỗi.

Và đó thực sự là vấn đề. Các nhà phát triển không thể làm đúng mọi thứ, vì vậy việc đảm bảo cơ sở dữ liệu không thể chứa đầy dữ liệu xấu là Điều tốt.

Mặc dù trong một thế giới lý tưởng, các phép nối tự nhiên sẽ sử dụng các mối quan hệ (tức là các ràng buộc FK) hơn là khớp với các tên cột. Điều này sẽ làm cho FKs thậm chí còn hữu ích hơn.

Cá nhân tôi ủng hộ các khóa ngoại vì nó chính thức hóa mối quan hệ giữa các bảng. Tôi nhận thấy rằng câu hỏi của bạn giả định rằng lập trình viên không giới thiệu dữ liệu sẽ vi phạm tính toàn vẹn tham chiếu, nhưng tôi đã thấy quá nhiều trường hợp vi phạm tính toàn vẹn tham chiếu của dữ liệu, mặc dù có ý định tốt nhất!

Các ràng buộc trước khóa ngoại (hay còn gọi là tính toàn vẹn tham chiếu khai báo hoặc DRI) đã dành rất nhiều thời gian để thực hiện các mối quan hệ này bằng cách sử dụng trình kích hoạt. Thực tế là chúng ta có thể chính thức hóa mối quan hệ bằng một ràng buộc khai báo là rất mạnh mẽ.

@John - Các cơ sở dữ liệu khác có thể tự động tạo chỉ mục cho khóa ngoại, nhưng SQL Server thì không. Trong SQL Server, các mối quan hệ khóa ngoại chỉ là các ràng buộc. Bạn phải xác định chỉ mục của mình trên các khóa ngoại một cách riêng biệt (điều này có thể có lợi.)

Chỉnh sửa: Tôi muốn nói thêm rằng, IMO, việc sử dụng các khóa ngoại để hỗ trợ BẬT XÓA hoặc BẬT CẬP NHẬT CASCADE không nhất thiết là một điều tốt. Trong thực tế, tôi nhận thấy rằng việc phân tầng khi xóa cần được xem xét cẩn thận dựa trên mối quan hệ của dữ liệu - ví dụ: bạn có cha-con tự nhiên ở đó điều này có thể OK hay bảng liên quan là một tập hợp các giá trị tra cứu. Sử dụng cập nhật theo tầng có nghĩa là bạn đang cho phép sửa đổi khóa chính của một bảng. Trong trường hợp đó, tôi có một bất đồng triết học chung là khóa chính của một bảng không được thay đổi. Các phím phải không đổi.

Nếu không có khóa ngoại thì làm cách nào để biết rằng hai bản ghi trong các bảng khác nhau có liên quan với nhau?

Tôi nghĩ những gì bạn đang đề cập đến là tính toàn vẹn tham chiếu, trong đó bản ghi con không được phép tạo mà không có bản ghi mẹ hiện có, v.v. Chúng thường được gọi là ràng buộc khóa ngoại - nhưng đừng nhầm lẫn với sự tồn tại của khóa ngoại trong nơi đầu tiên.

Có lợi ích gì khi không có khóa ngoại không? Trừ khi bạn đang sử dụng một cơ sở dữ liệu tồi tệ, còn không thì FK không khó để thiết lập. Vậy tại sao bạn lại có chính sách tránh chúng? Có một quy ước đặt tên nói rằng một cột tham chiếu đến cột khác, điều khác là biết cơ sở dữ liệu đang thực sự xác minh mối quan hệ đó cho bạn.

Tôi cho rằng bạn đang nói về các ràng buộc khóa ngoại được thực thi bởi cơ sở dữ liệu . Có thể bạn đã sử dụng khóa ngoại, chỉ là bạn chưa nói với cơ sở dữ liệu về nó.

Giả sử một lập trình viên đã thực sự làm điều này theo đúng cách, thì liệu chúng ta có thực sự cần khái niệm về khóa ngoại không?

Về mặt lý thuyết, không. Tuy nhiên, chưa bao giờ có một phần mềm nào không có lỗi.

Các lỗi trong mã ứng dụng thường không nguy hiểm - bạn xác định lỗi và sửa nó, sau đó ứng dụng chạy mượt mà trở lại. Nhưng nếu một lỗi cho phép dữ liệu bị gián đoạn xâm nhập vào cơ sở dữ liệu, thì bạn đang mắc kẹt với nó! Rất khó để khôi phục dữ liệu bị hỏng trong cơ sở dữ liệu.

Xem xét liệu một lỗi nhỏ trong FogBugz có cho phép ghi khóa ngoại bị hỏng trong cơ sở dữ liệu hay không. Có thể dễ dàng sửa lỗi và nhanh chóng đưa bản sửa lỗi cho khách hàng trong bản phát hành sửa lỗi. Tuy nhiên, làm thế nào để sửa dữ liệu bị hỏng trong hàng chục cơ sở dữ liệu? Mã đúng bây giờ có thể đột nhiên bị hỏng vì các giả định về tính toàn vẹn của khóa ngoại không còn giữ nữa.

Trong các ứng dụng web, bạn thường chỉ có một chương trình nói chuyện với cơ sở dữ liệu, vì vậy chỉ có một nơi mà lỗi có thể làm hỏng dữ liệu. Trong một ứng dụng doanh nghiệp có thể có một số ứng dụng độc lập nói chuyện với cùng một cơ sở dữ liệu (chưa kể những người làm việc trực tiếp với vỏ cơ sở dữ liệu). Không có cách nào để chắc chắn rằng tất cả các ứng dụng tuân theo cùng một giả định mà không có lỗi, luôn luôn và mãi mãi.

Nếu các ràng buộc được mã hóa trong cơ sở dữ liệu, thì điều tồi tệ nhất có thể xảy ra với lỗi là người dùng được hiển thị một thông báo lỗi xấu xí về một số ràng buộc SQL không được thỏa mãn. Điều này rất có lợi khi để dữ liệu bị gián đoạn vào cơ sở dữ liệu doanh nghiệp của bạn, nơi nó sẽ phá vỡ tất cả các ứng dụng của bạn hoặc chỉ dẫn đến tất cả các loại đầu ra sai hoặc sai lệch.

Ồ, và các ràng buộc khóa ngoại cũng cải thiện hiệu suất vì chúng được lập chỉ mục theo mặc định. Tôi không thể nghĩ ra bất kỳ lý do gì để không sử dụng các ràng buộc khóa ngoại.

FK rất quan trọng và phải luôn tồn tại trong lược đồ của bạn, trừ khi bạn là eBay .

Tôi nghĩ rằng một số điều đơn lẻ tại một số thời điểm phải có trách nhiệm đảm bảo các mối quan hệ hợp lệ.

Ví dụ, Ruby on Rails không sử dụng khóa ngoại, nhưng nó tự xác nhận tất cả các mối quan hệ. Nếu bạn chỉ truy cập cơ sở dữ liệu của mình từ ứng dụng Ruby on Rails đó, thì điều này là tốt.

Tuy nhiên, nếu bạn có các ứng dụng khách khác đang ghi vào cơ sở dữ liệu, thì nếu không có khóa ngoại, họ cần thực hiện xác thực riêng của mình. Sau đó, bạn có hai bản sao của mã xác thực có nhiều khả năng khác nhau, mà bất kỳ lập trình viên nào cũng có thể nhận ra đó là lỗi chính.

Tại thời điểm đó, các khóa ngoại thực sự là cần thiết, vì chúng cho phép bạn chuyển trách nhiệm về một điểm duy nhất một lần nữa.

Các khóa ngoại cho phép ai đó chưa từng xem cơ sở dữ liệu của bạn trước đây xác định mối quan hệ giữa các bảng.

Mọi thứ có thể ổn bây giờ, nhưng hãy nghĩ điều gì sẽ xảy ra khi lập trình viên của bạn rời đi và người khác phải tiếp quản.

Các khóa ngoại sẽ cho phép họ hiểu cấu trúc cơ sở dữ liệu mà không cần tra cứu hàng nghìn dòng mã.

Theo như tôi biết, các khóa ngoại được sử dụng để hỗ trợ lập trình viên thao tác dữ liệu theo cách chính xác.

FK cho phép DBA bảo vệ tính toàn vẹn của dữ liệu khỏi sự lóng ngóng của người dùng khi lập trình viên không làm như vậy, và đôi khi để bảo vệ khỏi sự lóng ngóng của người lập trình.

Giả sử một lập trình viên đã thực sự làm điều này theo đúng cách, thì liệu chúng ta có thực sự cần khái niệm về khóa ngoại không?

Các lập trình viên rất bình thường và dễ sai lầm. FK mang tính chất khai báo khiến chúng khó bắt vít hơn.

Có bất kỳ cách sử dụng nào khác cho khóa ngoại không? Am i thiếu cái gì ở đây?

Mặc dù đây không phải là lý do tại sao chúng được tạo ra, FK cung cấp gợi ý đáng tin cậy mạnh mẽ cho các công cụ lập sơ đồ và để truy vấn các nhà xây dựng. Điều này được chuyển cho người dùng cuối, những người rất cần những gợi ý mạnh mẽ đáng tin cậy.

Chúng không hoàn toàn cần thiết, theo cách mà dây an toàn không hoàn toàn cần thiết. Nhưng chúng thực sự có thể giúp bạn tránh làm điều gì đó ngu ngốc làm rối tung cơ sở dữ liệu của bạn.

Việc gỡ lỗi ràng buộc FK sẽ tốt hơn nhiều so với việc phải tạo lại một lần xóa đã phá vỡ ứng dụng của bạn.

Chúng rất quan trọng, vì ứng dụng của bạn không phải là cách duy nhất dữ liệu có thể được thao tác trong cơ sở dữ liệu. Ứng dụng của bạn có thể xử lý tính toàn vẹn tham chiếu một cách trung thực như nó muốn, nhưng tất cả những gì nó cần là một bozo với các đặc quyền phù hợp đi kèm và đưa ra lệnh chèn, xóa hoặc cập nhật ở cấp cơ sở dữ liệu và tất cả việc thực thi toàn vẹn tham chiếu ứng dụng của bạn bị bỏ qua. Đưa các ràng buộc FK vào ở cấp cơ sở dữ liệu có nghĩa là, cấm bozo này chọn vô hiệu hóa ràng buộc FK trước khi ban hành lệnh của chúng, ràng buộc FK sẽ khiến câu lệnh chèn / cập nhật / xóa không thành công với vi phạm toàn vẹn tham chiếu.

Tôi nghĩ về nó về mặt chi phí / lợi ích ... Trong MySQL , thêm một ràng buộc là một dòng bổ sung duy nhất của DDL . Đó chỉ là một số từ khóa và một vài giây suy nghĩ. Đó là "chi phí" duy nhất theo tôi ...

Các công cụ yêu thích khóa nước ngoài. Khóa ngoại ngăn dữ liệu xấu (nghĩa là các hàng không có) có thể không ảnh hưởng đến logic kinh doanh hoặc chức năng và do đó sẽ không được chú ý và tích lũy. Nó cũng ngăn các nhà phát triển không quen với lược đồ triển khai toàn bộ khối công việc mà không nhận ra rằng họ đang thiếu một mối quan hệ. Có lẽ mọi thứ đều tuyệt vời trong phạm vi ứng dụng hiện tại của bạn, nhưng nếu bạn bỏ lỡ điều gì đó và một ngày nào đó có điều gì đó không mong muốn được thêm vào (hãy nghĩ đến báo cáo thú vị), bạn có thể phải dọn dẹp thủ công dữ liệu xấu đã tích tụ từ khi mới thành lập của lược đồ mà không có kiểm tra thực thi cơ sở dữ liệu.

Thời gian ít ỏi cần thiết để hệ thống hóa những gì đã có trong đầu bạn khi bạn sắp xếp mọi thứ lại với nhau có thể giúp bạn hoặc người khác phải trải qua một loạt các tháng hoặc năm đau buồn trên đường.

Câu hỏi:

Có bất kỳ cách sử dụng nào khác cho khóa ngoại không? Am i thiếu cái gì ở đây?

Nó được tải một chút. Chèn chú thích, thụt lề hoặc đặt tên biến thay cho "khóa ngoại" ... Nếu bạn đã hiểu hoàn toàn điều được đề cập, thì điều đó "không có ích gì" đối với bạn.

Giảm entropy. Giảm khả năng xảy ra các kịch bản hỗn loạn trong cơ sở dữ liệu. Chúng tôi gặp khó khăn vì nó đang xem xét tất cả các khả năng có thể, vì vậy, theo tôi, giảm entropy là chìa khóa để duy trì bất kỳ hệ thống nào.

Ví dụ, khi chúng ta đưa ra một giả định: mỗi đơn hàng có một khách hàng thì giả định đó phải được thực thi bởi một thứ gì đó . Trong cơ sở dữ liệu mà "cái gì đó" là khóa ngoại.

Tôi nghĩ điều này đáng để đánh đổi tốc độ phát triển. Chắc chắn, bạn có thể viết mã nhanh hơn khi tắt chúng và đây có thể là lý do tại sao một số người không sử dụng chúng. Cá nhân tôi đã giết một số giờ với NHibernate và một số ràng buộc khóa ngoại khiến tôi tức giận khi thực hiện một số thao tác. TUY NHIÊN, tôi biết vấn đề là gì nên nó ít có vấn đề hơn. Tôi đang sử dụng các công cụ bình thường và có các tài nguyên để giúp tôi giải quyết vấn đề này, thậm chí có thể có người trợ giúp!

Giải pháp thay thế là cho phép một lỗi xâm nhập vào hệ thống (và có đủ thời gian, nó sẽ xảy ra) khi khóa ngoại không được đặt và dữ liệu của bạn trở nên không nhất quán. Sau đó, bạn nhận được một báo cáo lỗi bất thường, điều tra và "OH". Cơ sở dữ liệu bị hỏng. Bây giờ điều đó sẽ mất bao lâu để sửa chữa?

Bạn có thể xem khóa ngoại như một ràng buộc,

• Giúp duy trì tính toàn vẹn của dữ liệu
• Hiển thị cách dữ liệu có liên quan với nhau (có thể giúp thực thi logic và quy tắc nghiệp vụ)
• Nếu được sử dụng đúng cách, có thể giúp tăng hiệu quả mà dữ liệu được tìm nạp từ các bảng.

Chúng tôi hiện không sử dụng khóa ngoại. Và phần lớn chúng tôi không hối tiếc.

Điều đó nói lên rằng - chúng tôi có thể sẽ bắt đầu sử dụng chúng nhiều hơn trong tương lai gần vì một số lý do, cả hai đều vì những lý do tương tự:

1. Sơ đồ hóa. Sẽ dễ dàng hơn rất nhiều để tạo ra một sơ đồ của cơ sở dữ liệu nếu có các mối quan hệ khóa ngoại được sử dụng đúng cách.

2. Hỗ trợ công cụ. Việc xây dựng các mô hình dữ liệu bằng Visual Studio 2008 có thể được sử dụng cho LINQ to SQL dễ dàng hơn rất nhiều nếu có mối quan hệ khóa ngoại thích hợp.

Vì vậy, tôi đoán quan điểm của tôi là chúng tôi nhận thấy rằng nếu chúng tôi đang thực hiện nhiều công việc SQL thủ công (tạo truy vấn, chạy truy vấn, blahblahblah) thì khóa ngoại không nhất thiết phải cần thiết. Tuy nhiên, khi bạn bắt đầu sử dụng các công cụ, chúng sẽ trở nên hữu ích hơn rất nhiều.

Điều tốt nhất về các ràng buộc khóa ngoại (và các ràng buộc nói chung, thực sự) là bạn có thể dựa vào chúng khi viết các truy vấn của mình. Rất nhiều truy vấn có thể trở nên phức tạp hơn rất nhiều nếu bạn không thể dựa vào mô hình dữ liệu giữ "true".

Trong mã, chúng ta thường chỉ nhận được một ngoại lệ ở đâu đó - nhưng trong SQL , chúng ta thường chỉ nhận được câu trả lời "sai".

Về lý thuyết, SQL Server có thể sử dụng các ràng buộc như một phần của kế hoạch truy vấn - nhưng ngoại trừ các ràng buộc kiểm tra để phân vùng, tôi không thể nói rằng tôi đã từng thực sự chứng kiến ​​điều đó.

Khóa ngoại chưa bao giờ được khai báo rõ ràng (bảng (cột) TÀI LIỆU THAM KHẢO NGOẠI KHÓA) được khai báo trong các dự án (ứng dụng kinh doanh và trang web mạng xã hội) mà tôi đã làm việc.

Nhưng luôn có một loại quy ước đặt tên cho các cột là khóa ngoại.

Nó giống như với chuẩn hóa cơ sở dữ liệu - bạn phải biết mình đang làm gì và hậu quả của việc đó là gì (chủ yếu là hiệu suất).

Tôi biết các ưu điểm của khóa ngoại (tính toàn vẹn dữ liệu, chỉ mục cho cột khóa ngoại, các công cụ nhận biết về lược đồ cơ sở dữ liệu), nhưng tôi cũng sợ việc sử dụng khóa ngoại như quy tắc chung.

Ngoài ra, các công cụ cơ sở dữ liệu khác nhau có thể phục vụ khóa ngoại theo một cách khác, điều này có thể dẫn đến các lỗi nhỏ trong quá trình di chuyển.

Xóa tất cả các đơn đặt hàng và hóa đơn của khách hàng đã xóa bằng ON DELETE CASCADE là ví dụ hoàn hảo về lược đồ cơ sở dữ liệu đẹp, nhưng được thiết kế sai.

Đúng. BẬT XÓA [HẠN CHẾ | CASCADE] giúp các nhà phát triển không mắc kẹt dữ liệu, giữ cho dữ liệu luôn sạch sẽ. Gần đây tôi đã tham gia một nhóm các nhà phát triển Rails, những người không tập trung vào các ràng buộc cơ sở dữ liệu như khóa ngoại.

May mắn thay, tôi đã tìm thấy những thứ sau: http://www.redhillonrails.org/foreign_key_associations.html - Trình cắm thêm RedHill on Ruby on Rails tạo khóa ngoại bằng cách sử dụng quy ước về kiểu cấu hình . Việc di chuyển với product_id sẽ tạo ra một khóa ngoại cho id trong bảng sản phẩm .

Hãy xem các plugin tuyệt vời khác tại RedHill , bao gồm cả việc di chuyển trong giao dịch.

Nếu bạn có kế hoạch tạo mã truy cập dữ liệu của mình, tức là Entity Framework hoặc bất kỳ ORM nào khác, bạn hoàn toàn mất khả năng tạo mô hình phân cấp mà không có khóa ngoại