Thiết kế của bạn không "có vẻ" gì vì chúng tôi không thể đọc được suy nghĩ của bạn. Bạn đã đưa ra một số khía cạnh của thiết kế nhưng không đưa ra "kịch bản" kinh doanh mà nó đại diện / triển khai / mô tả hoặc cách nó thực hiện như vậy.
SQL NULL, UNIQUE, PK &FK là các loại ràng buộc. Ràng buộc là một giới hạn về những giá trị cơ sở dữ liệu nào có thể xuất hiện. SQL FK cho biết các giá trị con cho danh sách cột trong bảng phải xuất hiện ở nơi khác đối với danh sách cột có các cột tạo thành tập hợp cột SQL UNIQUE NOT NULL (mà PK là trường hợp của) trong bảng của chúng. Nếu thiết kế của bạn phải tuân theo một ràng buộc và nó không được ngụ ý bởi các ràng buộc thực thi khác, hãy thực thi nó. Nếu không thì đừng. Tốt hơn là khai báo. Hầu hết các DBMS SQL chỉ cho phép bạn khai báo một số loại ràng buộc rẻ tiền để thực thi. Những người khác phải được thực thi thông qua trình kích hoạt.
Các ràng buộc là hệ quả của tiêu chí cho các hàng đi vào so với không đứng ngoài bảng trong một tình huống nhất định (bảng vị từ , "ý nghĩa của các bảng") và những tình huống nào có thể &không thể phát sinh theo quy tắc kinh doanh của bạn. Chúng tôi không biết đó là gì trừ khi bạn cho chúng tôi biết. Chúng tôi có thể hy vọng đoán được bằng cách sử dụng tên bảng và cột của bạn, bất kỳ thông tin nào khác mà bạn cung cấp và thông thường.
Bạn phải nói với chúng tôi các ràng buộc hoặc các vị từ &những tình huống nào có thể / không thể phát sinh.
Ở đây các bảng của bạn đang sử dụng một bảng đơn giản cộng với một số thiết kế EAV để ghi lại dữ liệu của một bảng đơn giản nào đó không rõ ràng trong thiết kế của bạn. Như mọi khi bạn có thể tránh EAV bằng cách chỉ sử dụng DDL để giữ cho lược đồ &ràng buộc của bảng đơn giản được cập nhật, nhưng thay vào đó bạn đã chọn một lược đồ tĩnh yêu cầu lược đồ, truy vấn &ràng buộc phức tạp hơn. Biểu hiện đơn giản của các ràng buộc EAV thường là bảng đơn giản mà chúng đại diện có một số ràng buộc nhất định cộng với t_criteria_x là các khung nhìn của nó và / hoặc đó là một khung nhìn của chúng. Nhưng thông thường, các khai báo SQL duy nhất có sẵn chỉ cho phép bạn thể hiện các đoạn của điều đó.
Tôi đoán rằng những gì bạn dự định ở đây bao gồm rằng đối với mỗi bảng t_criteria_x, giá trị PK của nó phải xuất hiện trong t_criteria_director với giá trị tên_bảng 't_criteria_x'. Một cách khác để đặt điều này là nếu bạn đã thêm vào t_criteria_x một cột tên_bảng có giá trị 't_criteria_x' thì kết quả phải có (id, table_name) xuất hiện dưới dạng tiểu phân t_criteria_director (tiêu chí_id, table_name). Nếu cũng t_criteria_director (criteria_id, table_name) SQL UNIQUE NOT NULL thì chúng ta có t_criteria_x tăng cường đó có một SQL FK tổng hợp (id, table_name) tham chiếu đến t_criteria_director (criteria_id, table_name). Bạn có thể diễn đạt điều này một cách khai báo bằng cách thực sự tăng thêm t_criteria_x bằng các cột (có thể được tính toán / tạo / tính toán) như vậy. Nhưng có thể bạn cũng có những ràng buộc khác, chẳng hạn như không có bất kỳ cặp (bind_id, table_name) nào trong t_criteria_director không được tham chiếu bởi một số t_constraint_x tăng cường.
Việc gọi tên cột table_name cho thấy thiên vị hướng triển khai từ EAV vì cột đó là dấu phân biệt loại / biến thể / thẻ theo nghĩa ER, các loại thực thể được đại diện bởi id trong bảng t_criteria_x là "kiểu con" của loại thực thể được đại diện bởi t_criteria_director. (Đây cũng là một khái niệm / kỹ thuật từ cấu trúc dữ liệu bản ghi 3GL được sử dụng để nhập mô phỏng động.) Sau cùng, giá trị cột tên_bảng không nhất thiết phải là tên bảng, nó chỉ phải là một số giá trị xác định kiểu con thực thể, và các thực thể như vậy không phải chỉ tham gia vào mối quan hệ / liên kết của một bảng. (Nghiên cứu kiểu con SQL / cơ sở dữ liệu / ER / đa hình / kế thừa và thiết kế chống mẫu hai / nhiều / nhiều FK [sic] thành hai / nhiều / nhiều bảng.)
Bạn phải xác định các vị từ trong bảng là gì và các ràng buộc của chúng do đó là gì. Tốt hơn là thông qua việc xác định bảng đơn giản mà chúng đại diện chung là gì &vị từ của nó là gì và các ràng buộc cơ sở dữ liệu đang sử dụng nó. Sau đó, bạn phải quyết định xem bạn có định sửa đổi thiết kế của mình theo chi phí / lợi ích hay không để khai báo các ràng buộc và / hoặc bạn sẽ hoặc không thực thi các ràng buộc thông qua trình kích hoạt.
