Tại sao tôi không nên có một bảng cho nhiều mối quan hệ?


12

Giả sử tôi có nhiều mối quan hệ trong cơ sở dữ liệu của mình, ví dụ Cửa hàng, Nhân viên và Bán hàng và tôi muốn kết nối các cặp với mối quan hệ nhị phân đơn giản. Cá nhân tôi sẽ tạo các bảng có tên Employee_Store và Employee_Sale với một khóa tự nhiên bao gồm các khóa ngoại.

Bây giờ, đồng nghiệp của tôi khăng khăng tạo một bảng cho nhiều mối quan hệ. Đối với ví dụ trên, có thể có một bảng gọi là EmployeeLinks:

EmployeeLinks(
    IdLink int PK, 
    IdEmployee int FK null,
    IdStore int FK null,
    IdSale int FK null,
    LinkType int not null
)

Xin hãy giúp tôi với những lý do tốt tại sao đây không phải là một ý tưởng tốt. Tôi có lập luận của riêng tôi nhưng tôi muốn giữ riêng tư và nghe ý kiến ​​khách quan của bạn.

BIÊN TẬP:

Ban đầu bảng trên sẽ không có khóa chính (!). Bởi vì các khóa ngoại cho phép null một khóa thay thế là lựa chọn duy nhất.


3
Nó giống như OTLT hoặc EAV nhưng tệ hơn vì nó sinh sôi nảy nở hơn là các hàng!
onedaywhen

Câu trả lời:


13

Đồng nghiệp của bạn đề xuất gì làm khóa chính cho bảng liên kết này?
Tất nhiên các cột khóa chính không thể là NULL: bảng trên không có giá trị.

Không có bất kỳ mã định danh hàng tự nhiên nào (đó là PK là gì) trong ví dụ trên (cột IDENTITY không phải là khóa chính), do đó, nó không thành công trong bất kỳ quy trình mô hình hóa nào . Thậm chí đừng nghĩ đến việc tạo bảng mà không có mô hình nào đó (ERD, ORM, IDEF1X, bất cứ điều gì)

Bạn cũng cần các ràng buộc KIỂM TRA để đảm bảo bạn không có liên kết 3 chiều.

Cuối cùng, bạn đang đi lạc vào lãnh thổ dạng bình thường thứ 4 và thứ 5 nhưng vì những lý do sai lầm.

Tôi không thể tìm thấy bất kỳ ví dụ nào trên internet: điều đó cho thấy điều này thật ngu ngốc


4
+1 choI can't find any examples on the internet: that shows how stupid this is
JNK

Tôi đã làm cho nó rõ ràng hơn về khóa chính. Ngoài ra, rõ ràng đồng nghiệp của tôi đã thực sự bắt gặp thiết kế như vậy trước đây hoặc lâu hơn tôi đã nói
Tomasz Pluskiewicz

@Tomasz Pluskiewicz: Khóa thay thế không phải là khóa chính! Nó được chọn để bổ sung cho khóa tự nhiên tại thời điểm thực hiện. Xem dba.stackexchange.com/a/13779/630 Ngoài ra, đồng nghiệp của bạn sẽ cho chúng tôi xem một bài viết có thẩm quyền thể hiện kỹ thuật này. Tôi đã nhìn thấy những đống rác hoàn chỉnh trong thời gian của mình, nhưng tôi không lặp lại chúng ...
gbn

12

Lý do thực tế đầu tiên tôi có thể nghĩ đến là hiệu suất.

Trong mô hình "truyền thống", bạn có thể có một chỉ mục duy nhất trên Idemployee, Idstorehoặc bất kỳ trường nào và có hiệu suất tuyệt vời khi tra cứu. Nó cũng dễ dàng để duy trì cho chèn. Các chỉ mục duy nhất giúp bạn hợp nhất tham gia thường xuyên hơn, có thể tạo ra rất nhiều JOINtốc độ nhanh chóng.

Trong mô hình ví dụ của bạn, để có hiệu suất tốt, bạn sẽ cần phải có một chỉ mục trường duy nhất trên mỗi trường FK trong bảng ở mức tối thiểu, lý tưởng là chỉ số bao trùm trên tất cả các kết hợp sẽ được tham chiếu, nghĩa là:

  • Nhân viên / Cửa hàng
  • Nhân viên / Bán hàng

Tôi không chắc linktype là gì nhưng nếu bạn tham khảo nó, có lẽ nó nên được lập chỉ mục.

Các chỉ mục này sẽ cần được duy trì cho mỗi hàng trong bảng, cho dù trường đó có được điền hay không. Bạn có thể thêm một bộ lọc nhưng điều đó cũng sẽ trở nên khó khăn với rất nhiều kết hợp.

Nó cũng sẽ làm phức tạp logic của bạn. Bạn sẽ cần phải tra cứu nhân viên, tìm một hàng có giá trị cửa hàng trống và cập nhật; hoặc, chỉ cần chèn một hàng mới cho mỗi liên kết mới, loại này đánh bại mục đích hợp nhất các trường.

Về cơ bản, bạn sẽ sử dụng dung lượng đĩa THÊM, có các chỉ mục THÊM để duy trì và làm phức tạp logic của bạn mà không có lý do. "Lợi ích" duy nhất là ít bàn hơn để giải quyết.


Cột LinkType là một cái gì đó của một phân biệt đối xử. Chỉ cần nói cặp nào một hàng thực sự liên quan. Chỉ cần thêm vào các chi tiết nếu bạn hỏi tôi.
Tomasz Pluskiewicz

@TomaszPluskiewicz Tôi nghĩ cách tốt nhất để cho anh ấy thấy lý do tại sao nó hấp dẫn là xây dựng một bộ dữ liệu mẫu với cả hai loại bảng trong đó và chạy một số truy vấn. Mô hình của anh ấy sẽ chậm hơn nhiều so với mô hình truyền thống
JNK

4

Đặt nhiều mối quan hệ vào một bảng có thể hữu ích nếu các mối quan hệ đó có cùng thuộc tính và / hoặc nếu bạn muốn tổng hợp dữ liệu qua nhiều mối quan hệ.

Nó là cần thiết nếu các loại mối quan hệ được xác định bởi người dùng trong thời gian chạy. Tuy nhiên điều này hiếm khi thực sự là trường hợp.

Trong ví dụ của bạn, các mối quan hệ không chia sẻ thuộc tính, các mối quan hệ thậm chí tham chiếu hai bảng khác nhau. Điều này làm cho nó khó thực thi các ràng buộc và thiết kế cũng ít trực quan hơn.

Tôi sẽ chỉ chọn thiết kế đó nếu tạo bảng theo nghĩa đen là tốn tiền.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.