Các bảng quan hệ có thực sự cần thiết không?

Question

Bảng quan hệ chủ yếu chứa hai cột: IDTABLE1 và IDTABLE2.

Điều duy nhất dường như thay đổi giữa các bảng quan hệ là tên của hai cột đó và tên bảng.

Nó sẽ là tốt hơn nếu chúng ta tạo ra một bảng Relationships và trong bảng này, chúng tôi đặt 3 cột:
TABLE_NAME, IDTABLE1, IDTABLE2, và sau đó sử dụng bảng này cho tất cả các mối quan hệ?

Đây có phải là giải pháp tốt/được chấp nhận trong phát triển ứng dụng web/máy tính để bàn không? Điều gì sẽ là nhược điểm của điều này?

Lưu ý:
Cảm ơn tất cả các bạn đã phản hồi. Tôi đánh giá cao nó.
Nhưng, tôi nghĩ rằng bạn đang dùng nó một chút quá xa ... Mỗi giải pháp hoạt động cho đến một điểm.
Khi lưu trữ dữ liệu tệp văn bản đơn giản là tốt cho đến điểm nhất định, hơn excel là tốt hơn, hơn MS Access, hơn SQL Server, ...
Thành thật mà nói, tôi chưa thấy bất kỳ đối số nào nêu rõ lý do giải pháp này xấu cho các dự án nhỏ (với kích thước DB vài GB).

Answer 1

Ý tưởng tồi.

Làm cách nào bạn thực thi các khóa ngoại nếu IDTABLE1 có thể chứa id s từ bất kỳ bảng nào?

Để đạt được hiệu suất có thể chấp nhận khi kết nối mà không cần tải IO không cần thiết để đưa vào các hàng không liên quan, bạn sẽ cần một chỉ mục tổng hợp với cột hàng đầu TABLE_NAME về cơ bản kết thúc phân vùng bảng thành các phần.

Rõ ràng ngay cả khi phân đoạn giả này xảy ra, bạn vẫn sẽ lãng phí nhiều không gian trong bảng/chỉ mục, chỉ cần lặp lại tên bảng cho mỗi hàng.

Answer 2

Nó sẽ là một con quái vật của một bảng; nó cũng sẽ rườm rà. Hiệu suất-khôn ngoan, chẳng hạn một bảng sẽ không là một ý tưởng tuyệt vời. Ngoài ra, các khóa ngoại không thể thêm vào bảng như vậy. Tôi thực sự không thể nhìn thấy rất nhiều lợi thế cho một giải pháp như vậy.

Answer 3

Không phải là một NẾU lớn khi bạn chỉ lưu trữ 2 trường ID? Nếu tôi có một bảng StudentCourse (hoặc tốt hơn Enrollment) có StudentID & CourseID, nhưng sẽ không EnrollmentDate đi trong bảng này cũng vì không phải tất cả học sinh ghi danh vào ngày đầu tiên của lớp. Có vẻ như một ý tưởng tồi để thêm cột này vào một bảng đã cồng kềnh, nơi hầu hết các bản ghi sẽ là rỗng.

Lợi ích của một bảng có thể là yêu cầu ứng dụng có khả năng cho phép người dùng/quản trị tạo mối quan hệ này với dữ liệu (Tương tự như có bảng tra cứu đơn hoặc bảng danh sách tham chiếu) và tránh phải tạo mới để giải quyết các Tài liệu tham khảo do người dùng tạo. Cần truy vấn động cũng có thể có lợi. Một ứng dụng yêu cầu các yêu cầu cấu trúc dữ liệu động như vậy có thể phù hợp hơn với một cơ sở dữ liệu schemaless hoặc nosql.