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?


94

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, vậy thì chúng ta có thực sự cần khái niệm về khóa ngoại không?

Có cách nào khác để sử dụng khóa ngoài không? Am i thiếu cái gì ở đây?

+66

"Giả sử một lập trình viên thực sự làm điều này theo đúng cách" - Tôi thậm chí không thể tưởng tượng được một kịch bản như vậy. 19 apr. 092009-04-19 15:05:38

+11

"Foreign Key" là một ý tưởng, không phải là một công nghệ. Đó là một quy tắc quan hệ. Câu hỏi của bạn thực sự là về việc liệu bạn có nên cố gắng thực thi quy tắc trong mã của mình hay để cơ sở dữ liệu trợ giúp bạn. Khi đồng thời có liên quan, tốt nhất là để cho cơ sở dữ liệu thực thi quy tắc, vì nó nhận thức được mọi thứ xảy ra trong cơ sở dữ liệu, trong khi mã của bạn không thể nhận biết được. 25 aug. 092009-08-25 18:20:01

  0

@Triynko, khái niệm về khóa ngoại không phải là quy tắc quan hệ. 08 feb. 102010-02-08 12:21:33

  0

@Triynko - Để mở rộng những gì đã được nói, các khóa ngoại không phải là một quy tắc quan hệ, chúng là một quy tắc * mối quan hệ * 12 feb. 102010-02-12 21:30:26

+5

@lubos & cdeszaq. Trên thực tế, nó là một quy tắc quan hệ ... đó là một tập hợp con của quy tắc 10 của "Twleve Răn" của Codd ... "Độc lập toàn vẹn", về cơ bản nói rằng tính toàn vẹn quan hệ của RDBMS phải được duy trì độc lập với bất kỳ ứng dụng nào truy cập nó, chính xác là những gì tôi đã giải thích một cách dễ hiểu. Quy tắc này được thực hiện bởi, trong số những thứ khác, các ràng buộc khoá ngoại. Vì vậy, có, ý tưởng của một khóa ngoại là "một" quy tắc quan hệ. 24 feb. 102010-02-24 22:01:31

  0

@Triynko, tùy thuộc vào tôi liệu tôi muốn có tính toàn vẹn tham chiếu giữa hai quan hệ hay không. Không nơi nào được viết rằng nếu tôi có quan hệ Khách hàng và Hóa đơn, tôi cũng phải có và duy trì tính toàn vẹn tham chiếu giữa chúng. Tôi nghĩ cả hai chúng tôi đồng ý rằng đó là một ý tưởng tốt để thực thi tính toàn vẹn tham chiếu khi áp dụng nhưng nó chỉ là một ý tưởng tốt, không yêu cầu mô hình quan hệ. 25 feb. 102010-02-25 12:46:27

+1

@lubos: Để làm rõ, bạn đang nói về việc bạn có sử dụng một tính năng cụ thể hay không, nhưng tôi đang nói về sự hiện diện của tính năng đó là cần thiết để có một RDBMS hoàn chỉnh, đầy đủ chức năng. Ràng buộc tham chiếu, nếu và khi bạn chọn sử dụng chúng, là thứ cần được thực thi bên trong RDBMS (chứ không phải ứng dụng), vì vậy nó là một tính năng cần phải có, và theo nghĩa đó, nó là yêu cầu của mô hình quan hệ nếu bạn sẽ phát triển một RDBMS hoàn chỉnh. 01 mar. 102010-03-01 18:27:04

  0

Khóa ngoài giống như khóa chính từ xa.Khi bạn có hai bảng liên quan, một khóa ngoài liên kết dữ liệu từ một bảng riêng biệt, mà nếu không sẽ được bao gồm (dư thừa) trong bảng gốc. Mô hình quan hệ phục vụ để loại bỏ sự dư thừa bằng cách tách dữ liệu ra thành các bảng có liên quan, vì vậy các khóa ngoại là nền tảng cho mô hình quan hệ. IMO, nếu một mối quan hệ tồn tại, sau đó nó NÊN được thi hành. Nếu bạn chọn không thực thi mối quan hệ như vậy, thì IMO cơ sở dữ liệu của bạn hút :), không duy trì một bản ghi đầy đủ các sự kiện và có thể làm tê liệt ứng dụng của bạn với các giá trị null cuối cùng. 01 mar. 102010-03-01 18:38:56

  0

@Triynko, xin đừng nói quan hệ nếu bạn có nghĩa là mối quan hệ. nó gây nhầm lẫn bởi vì trong mô hình quan hệ, quan hệ là một bộ các bộ chia sẻ cùng loại, không phải là một mối quan hệ. cũng khi bạn nói về loại bỏ sự dư thừa, bạn không nói về mô hình quan hệ, bạn đang nói về chuẩn hóa cơ sở dữ liệu hoặc 3NF. mô hình quan hệ phải tuân theo các quy tắc tối thiểu được định nghĩa trong 1NF. tính toàn vẹn tham chiếu, khóa ngoài, xóa bỏ dự phòng không phải là quy tắc của 1NF do đó chúng không phải là quy tắc đáp ứng các yêu cầu của mô hình quan hệ. hy vọng nó có ý nghĩa bây giờ. 02 mar. 102010-03-02 01:26:08

  0

@ lubos: Mối quan hệ và mối quan hệ giống nhau. Những gì bạn cần nhận ra là một mối quan hệ ràng buộc hai quan hệ rời rạc (bảng) thành một quan hệ logic duy nhất. Nói cách khác, một mối quan hệ liên quan đến hai quan hệ, mà khi bị ràng buộc đúng là tương đương về mặt logic với một quan hệ đơn lẻ. Khi bạn viết một truy vấn JOIN, kết quả là một mối quan hệ SINGLE (bảng). Điều bạn ngụ ý là 'mô hình quan hệ' mô tả một bảng tính cơ bản, và tôi hoàn toàn không đồng ý. 02 mar. 102010-03-02 22:56:28

  0

Từ Wikipedia "Mô hình quan hệ": "Mô hình * quan hệ * của dữ liệu cho phép nhà thiết kế cơ sở dữ liệu tạo ra một đại diện hợp lý, thông tin hợp lý. * lược đồ logic * Lý thuyết * bao gồm một quy trình chuẩn hóa cơ sở dữ liệu * theo đó một thiết kế với các thuộc tính mong muốn nhất định có thể được chọn từ một tập hợp các lựa chọn thay thế tương đương về mặt logic *. " 02 mar. 102010-03-02 22:57:07

  0

... tiếp tục: "Tính nhất quán của một cơ sở dữ liệu quan hệ được thực thi, không phải bởi các quy tắc được xây dựng trong các ứng dụng sử dụng nó, mà là các ràng buộc, được khai báo như một phần của lược đồ logic và được thực thi bởi DBMS cho tất cả các ứng dụng. , các ràng buộc được biểu diễn bằng cách sử dụng các toán tử so sánh quan hệ, trong đó chỉ một, "là tập hợp con" (⊆), về mặt lý thuyết là đủ. Trong thực tế, một số viết tắt hữu ích được mong đợi có sẵn, trong đó quan trọng nhất là khóa ứng cử viên (thực sự, siêu khóa) và các ràng buộc khóa ngoại. " 02 mar. 102010-03-02 22:58:09

  0

Hãy để tôi thuật lại cụm từ "Cái bạn ngụ ý là ..." sau đây (vì việc chỉnh sửa dường như bị tắt): "Cái bạn ngụ ý là .. rằng 'mô hình quan hệ' không bao gồm các ý tưởng đối phó với việc duy trì sự toàn vẹn của mối quan hệ khi nó xảy ra để được phân chia vật lý cho các mục đích bình thường hóa, nhưng tôi nghĩ rằng nó bao gồm điều đó. " 02 mar. 102010-03-02 23:09:48

  0

Lưu ý rằng "quy tắc" của Codd không yêu cầu ràng buộc toàn vẹn tham chiếu được hỗ trợ bởi RDBMS. Quy tắc 10 chỉ định rõ ràng rằng các ràng buộc toàn vẹn nên được thực thi độc lập - nó không nói loại ràng buộc nào mà chúng cần. Trong mọi trường hợp, "quy tắc" không phải là và không bao giờ được định nghĩa là một định nghĩa của mô hình quan hệ. Rõ ràng là một cơ sở dữ liệu có thể quan hệ mà không có một ràng buộc RI duy nhất trong nó và một RDBMS thậm chí có thể không hỗ trợ RI (nó chỉ có thể không có quá nhiều khách hàng sẵn sàng). 31 mar. 112011-03-31 15:19:07

+2

Điều này xuất hiện thường xuyên ở đây. Tôi đổ lỗi cho [Joel Spolsky] (http://en.wikipedia.org/wiki/Joel_Spolsky) :-). Có nhiều câu trả lời hay ở đây; thay vì nhập lại tên của tôi, tôi sẽ chỉ cung cấp cho bạn một liên kết: http://stackoverflow.com/questions/83147/whats-wrong-with-foreign-keys 19 apr. 092009-04-19 15:02:54

95

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.

+45

Nếu bạn cần một chỉ mục tạo một tài khoản, thì đây không phải là một liên kết chính lý do cho FK. (Trong thực tế trong một số trường hợp (ví dụ: chèn nhiều hơn lựa chọn) duy trì FK có thể chậm hơn.) 21 mar. 102010-03-21 17:28:57

+3

Đó là một câu trả lời khủng khiếp FKs genaerally có thể bổ sung thêm chi phí không cải thiện hiệu suất. 13 feb. 152015-02-13 18:42:34

  0

Trong SQL-Server, chúng không được lập chỉ mục theo mặc định trên trọng tài hoặc liên kết giới thiệu. http://www.sqlskills.com/blogs/kimberly/when-did-sql-server-stop-putting-indexes-on-foreign-key-columns/ 27 jun. 162016-06-27 20:26:43

  0

Cũng không phải trong Oracle; bạn phải tự tạo các chỉ mục (trên các cột FK). 10 feb. 182018-02-10 20:17:01


55

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 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 đặt hàng trỏ đến người dùng đó.

+7

Mặc dù điều này có lẽ nên được xử lý trong lớp logic nghiệp vụ. Quyết định có hay không lưu giữ hồ sơ liên quan đến trẻ em, không hoàn toàn giống như việc bảo đảm rằng không có giá trị nào vi phạm mối quan hệ khóa ngoại. 06 oct. 082008-10-06 21:38:42

+4

Vấn đề khác là kiểm toán, nếu việc kiểm toán không được thực hiện ở cấp db, việc cập nhật tầng hoặc xóa sẽ làm mất hiệu lực đường mòn kiểm toán của bạn. 01 sep. 092009-09-01 04:52:11

  0

@Codewerks: Logic nghiệp vụ có thể nằm trong DB. 01 feb. 112011-02-01 19:31:41

+2

@Greg Hewgill Điều này có thể dẫn đến rất nhiều vấn đề. Bạn nên rất cẩn thận với những suy nghĩ như DELETE CASCADE, như trong nhiều trường hợp, bạn sẽ muốn giữ lại các đơn đặt hàng do người dùng tạo khi xóa người dùng. 20 aug. 082008-08-20 20:28:12


41

Tôi không thể tưởng tượng thiết kế 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 của bạn.

Chúng không phải là yêu cầu, nói đúng, nhưng lợi ích là rất lớn.

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

+39

Joel: "Cho đến nay chúng tôi chưa bao giờ gặp sự cố." Cho đến nay, tôi chưa bao giờ lái xe vào một cột đèn. Nhưng tôi vẫn nghĩ đó là một ý tưởng tốt để đeo dây an toàn ;-) 04 nov. 082008-11-04 10:36:18

+2

Có thể bạn chưa bao giờ có vấn đề, nhưng có thể là nó ... Hầu hết các cơ sở dữ liệu sử dụng một quy ước như id_xxx giống hệt ixXXX 05 feb. 092009-02-05 21:54:59

+1

@ Jelel: Quy ước đặt tên thay cho việc thực thi các quy tắc? Cũng có thể làm tốt với loại trong khi bạn đang ở đó. 17 sep. 092009-09-17 20:54:16

+8

@Eric: Bạn đang cầm Fog Creek như một loại avatar về phát triển phần mềm ở đây. Nếu bạn nói "Một công ty ở thành phố New York không có chìa khóa nước ngoài trong db của họ ..." tất cả chúng ta đều nói "Và?" 17 sep. 092009-09-17 20:56:08

+1

@jcollum, tôi đã đưa ra nhận xét đó trong bản beta của Stack Overflow, khi có khá nhiều người ở đây biết Jeff và Joel là ai, và hầu hết có lẽ đang nghe Podcast, vì vậy Fog Creek nằm trên radar của mọi người. 18 sep. 092009-09-18 12:04:23

  0

@jcollum: một số sẽ nói "Và?" trong khi những người khác sẽ nói "WTF?" (Tôi vừa làm), nhưng tôi đoán có nhiều cách để làm một chiếc răng. Sử dụng tốt "avatar", nhân tiện. :) 01 may. 102010-05-01 00:17:29

+3

Eric: FogBugz sử dụng quy ước đặt tên cho khóa ngoài. Ví dụ ixBug được hiểu là một chỉ mục vào khóa chính của bảng Bug. Cho đến nay chúng tôi chưa bao giờ gặp vấn đề gì. - Joel Spolsky 13 feb. 122012-02-13 01:48:13

  0

"Cho đến nay chúng tôi chưa bao giờ gặp sự cố." - Sửa chữa: Bạn chưa bao giờ gặp sự cố mà bạn biết - đó là một lý do tuyệt vời khác để cho phép các công cụ của bạn giúp bạn. 24 feb. 132013-02-24 23:47:50

  0

Để trả lời câu hỏi thực tế của Eric, sự hiểu biết của tôi là phần mềm Fog Creek được lưu trữ trên các máy chủ được kiểm soát bởi Fog Creek, không phải phần mềm thu nhỏ được phát hành vào tự nhiên. Điều này có nghĩa là họ * có thể * đảm bảo rằng cơ sở dữ liệu của họ chỉ được xử lý thông qua phần mềm ứng dụng của họ. Trong bối cảnh này, tôi phỏng đoán rằng có một mô hình đối tượng thực thi các ràng buộc. 11 jun. 132013-06-11 01:28:33


8

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

Tôi nghĩ rằng 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 cha mẹ hiện có v.v. Đây thường được gọi là ràng buộc khóa ngoại - nhưng không bị nhầm lẫn với sự tồn tại chìa khóa nước ngoài ngay từ đầu.


1

Bạn có thể xem các phím nước ngoài là một hạn chế đó,

  • giúp duy trì tính toàn vẹn dữ liệu
  • Hiện cách dữ liệu được liên hệ với nhau (mà có thể giúp trong việc thực thi logic kinh doanh và các quy tắc)
  • Nếu được sử dụng đúng cách, có thể giúp tăng hiệu quả mà dữ liệu được lấy từ các bảng.

6

Tôi nghĩ một số điều đơn lẻ tại một số điểm phải chịu 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ó 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, điều này là tốt.

Tuy nhiên, nếu bạn có khách hàng khác đang viết thư cho cơ sở dữ liệu, thì không có khóa ngoại họ cần thực hiện xác thực của riêng họ. Sau đó, bạn có hai bản sao của mã xác nhận 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ể nói là một tội lỗi hồng y.

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

+2

Nó giống như hành tây. FK là lớp bảo vệ cuối cùng. Trừ khi nó là một cơ sở dữ liệu cục bộ được nhúng, các ứng dụng cố gắng thực hiện tính toàn vẹn tham chiếu luôn luôn là một ý tưởng tồi. 04 oct. 132013-10-04 19:23:08


12

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

Làm một giả thiết như vậy dường như tôi trở thành một ý tưởng vô cùng xấu; trong phần mềm tổng quát là lỗi bất thường.

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

Mặc dù trong một thế giới lý tưởng, các kết nối tự nhiên sẽ sử dụng các mối quan hệ (nghĩa là các ràng buộc FK) thay vì so khớp các tên cột. Điều này sẽ làm cho FK trở nên hữu ích hơn.

+2

Điểm tốt, nó sẽ là tốt đẹp để tham gia hai bảng với "ON [Mối quan hệ]" hoặc một số từ khóa khác và để cho con số db ra những gì cột có liên quan. Có vẻ khá hợp lý thực sự. 17 sep. 092009-09-17 20:58:04


12

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 ra 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 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 dữ liệu tham chiếu toàn vẹn bị vi phạm, mặc dù có ý định tốt nhất!

Các ràng buộc khóa trước ngoại (còn gọi là toàn vẹn tham chiếu khai báo hoặc DRI) đã dành nhiều thời gian để triển khai các mối quan hệ này bằng trình kích hoạt. Thực tế là chúng ta có thể chính thức hoá 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à những ràng buộc. Bạn phải xác định chỉ mục của bạn trên các khóa ngoại riêng biệt (có thể có lợi.)

Chỉnh sửa: Tôi muốn thêm rằng, IMO, việc sử dụng các khóa ngoài để hỗ trợ ON DELETE hoặc ON UPDATE CASCADE không nhất thiết một điêu tôt. Trong thực tế, tôi đã thấy rằng thác trên xóa phải đượ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 mẹ tự nhiên, con cái này có thể được chấp nhận hay là bảng liên quan một tập hợp các giá trị tra cứu. Sử dụng cập nhật cascaded ngụ ý bạn đang cho phép khóa chính của một bảng được sửa đổi. Trong trường hợp đó, tôi có một sự bất đồng triết học chung trong đó khóa chính của một bảng không nên thay đổi. Các khóa phải cố định không đổi.

+2

+1 Đối với các phím không đổi bất cứ khi nào có thể. 30 jul. 092009-07-30 16:04:07


20

Có.

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

ý bạn là gì? 06 sep. 152015-09-06 02:33:19

  0

Trung thực với quan niệm tôi đoán. Nó ngăn cản bạn gian lận với dữ liệu bằng cách thực hiện lập trình nhanh và lame. 08 jan. 172017-01-08 21:09:09


1

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

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

  1. Vẽ Sơ Đồ. Việc tạo sơ đồ cơ sở dữ liệu dễ dàng hơn nhiều nếu có mối quan hệ khóa ngoài được sử dụng chính xác.

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

Vì vậy, tôi đoán là chúng tôi nhận thấy rằng nếu chúng tôi đang thực hiện rất nhiều công việc SQL thủ công (truy vấn xây dựng, truy vấn, blahblahblah) thì không 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.

+1

Tôi làm việc trên các hệ thống không sử dụng chúng. Và tôi rất tiếc thường xuyên. Tôi đã thấy nhiều trường hợp hơn, tôi có thể đếm dữ liệu phi nhạy cảm có thể bị ngăn chặn bởi những ràng buộc thích hợp. 19 apr. 092009-04-19 15:15:25

  0

Và khi làm việc với các khóa ngoại trong dự án hiện tại của chúng tôi trong gần sáu tháng, tôi hoàn toàn đồng ý với nhận xét này. 20 apr. 092009-04-20 13:17:03


4

Chúng không thực sự cần thiết, theo cách mà dây an toàn không cần thiết. Nhưng họ thực sự có thể giúp bạn tiết kiệm từ việc làm một cái gì đó ngu ngốc mà messes lên cơ sở dữ liệu của bạn.

Thật tuyệt vời khi gỡ lỗi lỗi ràng buộc FK hơn là phải tạo lại một lần xóa đã phá vỡ ứng dụng của bạn.


1

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

Trong mã, chúng tôi thường chỉ nhận được ngoại lệ được ném ở đâu đó - nhưng trong SQL, chúng tôi thường chỉ nhận được câu trả lời "sai". Theo lý thuyết, SQL Server có thể sử dụng các ràng buộc như là 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 đã thực sự chứng kiến ​​điều đó.

  0

Các ràng buộc duy nhất cho biết số lượng cardinality cao được sử dụng bởi trình tối ưu hóa trong việc chọn một cơ chế kết nối. 22 dec. 092009-12-22 22:14:03


36

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

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

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

Tại sao bạn cho 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 bằng ngôn ngữ hiện đại?

+2

+1 cho một sự tương tự tốt giữa các mối quan hệ đóng gói và FK/PK. 17 sep. 092009-09-17 20:58:44


3

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

Công cụ yêu thích khóa ngoại. Các khóa ngoại ngăn chặn dữ liệu xấu (có nghĩa là, các hàng mồ côi) có thể không ảnh hưởng đến logic nghiệp vụ hoặc chức năng và do đó không được chú ý và xây dựng. Nó cũng ngăn cản các nhà phát triển không quen thuộc với lược đồ từ việc thực hiện toàn bộ khối công việc mà không nhận ra 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ỡ một thứ gì đó và một ngày nào đó bất ngờ được thêm vào (nghĩ báo cáo ưa thích), bạn có thể ở vị trí mà bạn phải tự dọn sạch dữ liệu xấu đã tích luỹ kể từ khi thành lập của lược đồ mà không cần kiểm tra thực thi cơ sở dữ liệu.

Cần ít thời gian để mã hóa những gì đã có trong đầu khi bạn sắp xếp mọi thứ lại với nhau có thể giúp bạn hoặc một người nào đó phải mất hàng tháng hoặc nhiều năm xuống đường.

Câu hỏi đặt ra:

Có bất kỳ ứng dụng khác cho phím nước ngoài? Am i thiếu cái gì ở đây?

Nó được tải một chút. Chèn ý kiến, thụt đầu dòng hoặc đặt tên biến thay cho "chìa khóa nước ngoài" ... Nếu bạn đã hiểu rõ điều đó một cách hoàn hảo, đó là "không sử dụng" cho bạn.


1

Chìa khóa nước ngoài chưa bao giờ rõ ràng (Bảng tham chiếu KEY NGOÀI) được công bố 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 cột là khóa ngoài.

Giống như với database normalization - bạn phải biết bạn đang làm gì và hậu quả của điều đó (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ông cụ nhận biết lược đồ cơ sở dữ liệu), nhưng tôi cũng sợ sử dụng khóa ngoài như quy tắc chung.

Các công cụ cơ sở dữ liệu khác nhau có thể phục vụ các 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ả đơn đặt hàng và hóa đơn của khách hàng đã xóa bằng BẬT DELETE CASCADE là ví dụ hoàn hảo về giao diện đẹp, nhưng được thiết kế sai, được thiết kế.


8

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


0

Có. ON DELETE [RESTRICT | CASCADE] giữ cho các nhà phát triển khỏi bị mắc kẹt dữ liệu, giữ dữ liệu 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 về cơ sở dữ liệu như các khóa ngoại.

May mắn thay, tôi đã tìm thấy: http://www.redhillonrails.org/foreign_key_associations.html - RedHill trên trình cắm thêm Ruby on Rails tạo khóa ngoài bằng cách sử dụng kiểu convention over configuration. Di chuyển có product_id sẽ tạo khóa ngoài cho số id trong bảng sản phẩm.

Kiểm tra các trình cắm tuyệt vời khác tại RedHill, bao gồm cả di chuyển được bao bọc trong giao dịch.

  0

Liên kết bị hỏng. 10 aug. 132013-08-10 19:38:47


5

Khóa ngoài cho phép người nào đó chưa xem cơ sở dữ liệu của bạn trước đó để xác định mối quan hệ giữa các bảng.

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

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 rà soát qua hàng nghìn dòng mã.


8

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

Giả sử một lập trình viên đang thực sự làm này theo cách đúng rồi, sau đó nào chúng ta thực sự cần các khái niệm về phím nước ngoài?

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

Lỗi trong mã ứng dụng thường không nguy hiểm - bạn xác định lỗi và sửa lỗi, sau đó ứng dụng chạy trơn tru trở lại. Nhưng nếu một lỗi cho phép dữ liệu currupt nhập vào cơ sở dữ liệu, thì bạn bị 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.

Hãy xem xét nếu một lỗi tinh tế trong FogBugz cho phép khóa ngoại tuyến bị hỏng được ghi vào cơ sở dữ liệu. Nó có thể dễ dàng để sửa lỗi và nhanh chóng đẩy sửa chữa cho khách hàng trong một bản phát hành bugfix. Tuy nhiên, làm thế nào nên các dữ liệu tham nhũng trong hàng chục cơ sở dữ liệu được cố định? Đúng mã có thể bẻ khóa đột ngột vì các giả định về tính toàn vẹn của các khóa ngoại không giữ được 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, do đó, chỉ có một nơi mà các 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 với cùng một cơ sở dữ liệu (chưa kể đến những người làm việc trực tiếp với trình bao cơ sở dữ liệu). Không có cách nào để đảm bảo rằng tất cả các ứng dụng đều tuân theo các giả định tương tự không có lỗi, luôn luôn và mãi mãi.

Nếu 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ị thông báo lỗi xấu về một số ràng buộc SQL không thỏa mãn. Đây là nhiều thích hợp hơn để cho phép 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 gây nhầm lẫn.

Ồ, 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 nào không phải để sử dụng các ràng buộc khóa ngoại.


4

Chúng 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ý 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ì cần là một bozo với các đặc quyền thích 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ả thực thi toàn vẹn tham chiếu ứng dụng của bạn bị bỏ qua. Đặt ràng buộc FK ở cấp cơ sở dữ liệu có nghĩa là, chặn bỏ bozo này để vô hiệu hóa ràng buộc FK trước khi đưa ra lệnh của họ, ràng buộc FK sẽ gây ra một câu lệnh chèn/cập nhật/xóa không thành công với lỗi vi phạm toàn vẹn tham chiếu.


5

Theo như tôi biết, 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.

FKS phép DBA để bảo vệ toàn vẹn dữ liệu từ dò dẫm của người dùng khi các lập trình viên không làm như vậy, và đôi khi để bảo vệ chống lại dò dẫm của lập trình viên.

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

Người lập trình chết và dễ đọc. FK là tuyên bố khiến chúng khó khăn hơn để vít lên.

Có cách nào khác để sử dụng 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, FK cung cấp gợi ý đáng tin cậy mạnh mẽ cho các công cụ lập biểu đồ và truy vấn người xây dựng. Điều này được chuyển cho người dùng cuối, những người tuyệt vọng cần những gợi ý đáng tin cậy mạnh mẽ.

  0

Đây là một câu trả lời tuyệt vời. 23 mar. 132013-03-23 13:49:36


7

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

+1

liên kết tốt đẹp ở đó 01 dec. 092009-12-01 23:50:31

+2

liên kết đó thực sự vô cùng hấp dẫn ... tôi thực sự muốn biết thêm chi tiết và tôi hơi sợ sử dụng ebay ngay bây giờ. cho những người khác: nhấp vào câu hỏi thứ 4 để xem những gì anh ta nói về cấu trúc db của họ. toàn bộ cuộc phỏng vấn đáng xem. cũng ... 'unibrow' 23 aug. 132013-08-23 18:52:31


2

Giảm entropy. Giảm khả năng xảy ra tình huống hỗn loạn trong cơ sở dữ liệu. Chúng tôi có một thời gian khó khăn vì nó đang xem xét tất cả các possiblilites như vậy, theo ý kiến ​​của tôi, entropy giảm là chìa khóa để duy trì bất kỳ hệ thống.

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

Tôi nghĩ điều này đáng để cân bằng giữa tốc độ phát triển. Chắc chắn, bạn có thể viết mã nhanh hơn với họ và đây có lẽ 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 chết một số giờ với NHibernate và một số hạn chế chính nước ngoài mà tức giận khi tôi thực hiện một số hoạt động. TUY NHIÊN, tôi biết vấn đề là gì nên nó ít là vấn đề. Tôi đang sử dụng các công cụ bình thường và có các nguồn lực để giúp tôi làm việc xung quanh việc này, thậm chí có thể giúp mọi người!

Phương án thay thế là cho phép một lỗi xâm nhập vào hệ thống (và sẽ có đủ thời gian), nếu khoá ngoại không được đặt và dữ liệu của bạn không phù hợp. 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ờ mất bao lâu để sửa chữa?