Tại sao một chìa khóa nên được làm rõ ràng?

15

Tôi rất mới đối với chủ đề của cơ sở dữ liệu vì vậy điều này nghe có vẻ không biết gì, nhưng tôi tò mò tại sao một khóa nên được làm rõ ràng trong một bảng. Đây có phải là chủ yếu để nói với người dùng rằng giá trị cột đã cho (hy vọng) được đảm bảo là duy nhất trong mỗi hàng không? Sự độc đáo vẫn nên có ngay cả khi nó không được đề cập.

primary-key unique-constraint

— DSaxton
nguồn

Bạn có nghĩa là nếu bạn có một khóa ĐỘC ĐÁO, tại sao lại phải có một cái CHÍNH HÃNG?

— Vérace

1

Tại sao họ lại tuyên bố? Có vẻ như rất hữu ích, nhưng nó thực sự cần thiết phải có một cơ sở dữ liệu có chức năng?

— DSaxton

1

Chúng không cần thiết cho cơ sở dữ liệu của bạn hoạt động nhưng chúng cần để dữ liệu của bạn "hoạt động" tức là nhất quán, vì đó chính xác là cách bạn đang nói với máy chủ cơ sở dữ liệu của mình để giữ thông tin nhất quán.

— Andriy M

Nếu cơ sở dữ liệu biết rằng một trường đã cho là một khóa, thì tác dụng phụ là nó có thể giúp bạn xác định vị trí hàng chứa khóa nhanh hơn nhiều so với việc nó cần xem qua tất cả các hàng trong bảng. Các chỉ mục là một phần rất quan trọng tại sao cơ sở dữ liệu hữu ích.

— Thorbjørn Ravn Andersen

32

Rõ ràng là bạn đang đề xuất rằng CONSTRAINTs trong cơ sở dữ liệu nên được thi hành bởi (các) ứng dụng mà truy cập cơ sở dữ liệu đó?

Có nhiều lý do tại sao đây là một ý tưởng tồi (xấu, xấu ...).

1) Nếu bạn đang xây dựng một công cụ "ràng buộc" của riêng bạn (tức là trong mã ứng dụng của bạn), thì bạn chỉ đang mô phỏng những gì Oracle / SQL Server / MySQL / PostgreQuery / <. Anyever ...> đã chi năm viết. Mã CONSTRAINT của họ đã được kiểm tra trong những năm qua bởi hàng triệu người dùng cuối.

2) Với tất cả sự tôn trọng dành cho bạn và nhóm của bạn, bạn sẽ không làm cho đúng ngay cả trong vài năm - kể từ đây , chỉ riêng mã MySQL đã có giá 40 triệu đô la. Và MySQL là máy chủ rẻ nhất trong số 3 máy chủ ở trên và thậm chí họ không triển khai KIỂM TRA CONSTRAINT. Rõ ràng, có được RI (Toàn vẹn tham chiếu) hoàn toàn đúng là khó khăn.

Tôi thường xuyên sử dụng các diễn đàn của Oracle và tôi không thể nói cho bạn biết số lần mà một số người quản lý / lập trình viên nghèo đã có một dự án thúc đẩy anh ta, nơi thiên tài có công việc của anh ta trước đây có ý tưởng "sáng suốt" về những gì bạn đề xuất .

Jonathan Lewis (ông đã viết một cuốn sách 550 trang về các nguyên tắc cơ bản của trình tối ưu hóa Oracle ) là không. 2 trong số Thảm họa thiết kế của ông trong một cuốn sách khác (" Tales of the Oak Table " - Bàn Oak là một nhóm các chuyên gia của Oracle) là

Chúng tôi sẽ kiểm tra tính toàn vẹn dữ liệu ở cấp ứng dụng thay vì tận dụng các khả năng kiểm tra ràng buộc của Oracle.

3) Ngay cả khi bằng một phép lạ nào đó bạn có thể thực hiện RI một cách chính xác, bạn sẽ phải thực hiện lại hoàn toàn nó hết lần này đến lần khác cho mọi ứng dụng chạm vào cơ sở dữ liệu đó - và nếu dữ liệu của bạn là quan trọng, thì các ứng dụng mới sẽ. Chọn điều này như một mô hình sẽ dẫn bạn và các lập trình viên đồng nghiệp của bạn (không đề cập đến nhân viên hỗ trợ và bán hàng) đến một cuộc sống liên tục chữa cháy và đau khổ.

Bạn có thể đọc thêm về lý do tại sao triển khai CONSTRAINT dữ liệu ở cấp ứng dụng không có gì là điên rồ ở đây , đây và đây .

Để trả lời cụ thể câu hỏi của bạn:

Tại sao họ lại tuyên bố? Nó có vẻ rất hữu ích, nhưng thực sự cần thiết phải có một cơ sở dữ liệu có chức năng

Lý do mà KEYs (hoặc PRIMARY, FOREIGN, UNIQUEhay chỉ là bình thường INDEXes) được khai báo là, trong khi nó là không nghiêm chỉnh cần thiết cho một cơ sở dữ liệu để họ có cho nó hoạt động, nó là hoàn toàn cần thiết cho họ để được khai báo cho nó chức năng tốt .

— Vérace
nguồn

1

Cảm ơn câu trả lời của bạn. Có lẽ tôi sẽ cần phải tìm hiểu thêm để hiểu đầy đủ về nó. (Tôi thực sự không thuộc về một nhóm, tôi chỉ tìm hiểu về cơ sở dữ liệu vì tò mò.)

— DSaxton

2

Đọc một vài cuốn sách (Ngày, Garcia-Molina ...) và quay lại với chúng tôi nếu bạn có câu hỏi cụ thể (câu hỏi quá rộng được coi là lạc đề ở đây). ps Chào mừng bạn đến với diễn đàn :-)

— Vérace 10/07/2015

Mặc dù tôi sẽ không bao giờ đề nghị bạn không đặt ràng buộc vào cơ sở dữ liệu (Bạn phải luôn có khóa chính và khóa ngoại ở mức tối thiểu), bạn có thể tránh # 3 bằng cách sử dụng tất cả các ứng dụng từ dịch vụ chia sẻ (kiến trúc hướng dịch vụ ). (Dù sao, đó có lẽ là điều bạn nên cân nhắc cho nhiều người tiêu dùng, vì thực hiện mọi kiểm tra tính toàn vẹn cuối cùng mà bạn cần trong cơ sở dữ liệu cũng có thể gặp ác mộng. Hãy nghĩ rằng kích hoạt ở mọi nơi thực hiện kiểm tra trên các bảng và hàng mọi lúc.)

— jpmc26

10

Khi bạn tạo khóa trong cơ sở dữ liệu, công cụ DBMS sẽ thực thi một ràng buộc duy nhất đối với các thuộc tính khóa. Điều này phục vụ ít nhất ba mục đích liên quan:

Tính toàn vẹn dữ liệu: dữ liệu trùng lặp không thể được nhập vào các thuộc tính chính. Do đó, bất kỳ sự phụ thuộc vào các phím được đảm bảo.
Nhận dạng: người dùng có thể dựa vào các khóa như một phương tiện để xác định và cập nhật dữ liệu chính xác.
Tối ưu hóa: thông tin (siêu dữ liệu) về thuộc tính nào là duy nhất có sẵn cho trình tối ưu hóa truy vấn DBMS. Thông tin này cho phép trình tối ưu hóa đơn giản hóa việc thực hiện truy vấn theo một số cách nhất định để các truy vấn sẽ thực thi nhanh hơn.

— nvogel
nguồn

8

Tôi sẽ thêm một khía cạnh cho các câu trả lời xuất sắc hiện có: Tài liệu. Thông thường, điều quan trọng là phải xem loại khóa nào bạn có thể sử dụng để xác định một thực thể. Bất kỳ sự kết hợp của các cột duy nhất là một khóa ứng cử viên.

Khóa chính có xu hướng là một khái niệm đặc biệt hữu ích trong thực tế.

Cho dù bạn có thi hành khóa hay không (có lẽ bạn nên) tài liệu đó có giá trị theo đúng nghĩa của nó.

— boot4life
nguồn

1

Sơ đồ cơ sở dữ liệu! Điều đầu tiên tôi luôn làm khi được yêu cầu nói điều gì đó có ý nghĩa về phần mềm mà tôi không quen thuộc là xem nó có sử dụng cơ sở dữ liệu quan hệ hay không và nếu có, hãy thử tạo sơ đồ cơ sở dữ liệu. Điều đó sẽ cho tôi một ý tưởng tuyệt vời về thông tin mà ứng dụng làm việc với. Thật không may, 90% cơ sở dữ liệu tôi đã thấy không khai báo khóa ngoại, vì vậy các sơ đồ chỉ là tập hợp các bảng. Khấu trừ các khóa ngoại cấp cấp ứng dụng ngầm đòi hỏi phải phỏng đoán và điều chỉnh.

— rebierpost

1

@reinierpost Tôi hoàn toàn đồng ý. Dữ liệu là đối tượng có giá trị nhất để ghi lại và giữ sạch vì nó tồn tại mãi mãi. Mã có thể thay đổi; nó có xu hướng thoáng qua hơn.

— boot4life 11/07/2015

@reinierpost - Được tư vấn cho một công ty cung cấp phần mềm cho toàn bộ cơ sở hạ tầng đường sắt của một quốc gia lớn ở châu Âu (lớn - nghĩ hàng tỷ vật dụng) và tôi nói, "Hum, tôi sẽ chỉ chạy một truy vấn để kiểm tra các FOREIGN KEYđịnh nghĩa để có được cảm nhận hệ thống ". Truy vấn của tôi trả về zip !!! Chắc chắn rằng SQL của tôi đã sai, tôi đã đề cập điều này với một trong những lập trình viên cao cấp. Với niềm tự hào (không kém), anh tuyên bố (như thể anh đang trình bày một đứa con trai mới chào đời) rằng hệ thống không có bất kỳ FK nào vì "tất cả các tìm kiếm đều trên PRIMARY KEYs" - (không liên quan). <Doh ...> a la Homer Simpson!

— Vérace

5

Một lý do khác khiến bạn nên sử dụng CONSTRAINT thay vì một số mã bên trong ứng dụng:

Điều gì xảy ra nếu nhà phát triển / dba sử dụng câu lệnh chèn / cập nhật / xóa để sửa đổi dữ liệu trực tiếp trong DB? Trong trường hợp này, tất cả tính toàn vẹn tham chiếu dựa trên ứng dụng của bạn sẽ là vô ích. Tôi biết, một số nhà phát triển thích khả năng sửa đổi dữ liệu trực tiếp mà không phải bận tâm đến RI vì họ biết họ làm gì - ít nhất là nhiều lần nhất (nhưng không phải lúc nào cũng vậy)

PS: Tất nhiên bạn có thể tạo ra các kích hoạt, nhưng chúng thường rất chậm (so với CONSTRAINTS).

— Thomas Franz
nguồn