Dit design "synes" ikke som noget, fordi vi ikke kan læse dine tanker. Du har givet nogle aspekter af et design, men ikke det forretningsscenario, det repræsenterer/implementerer/beskriver, eller hvordan det gør det.
SQL NULL, UNIQUE, PK'er og FK'er er slags begrænsninger. En begrænsning er en begrænsning på, hvilke databaseværdier der kan vises. En SQL FK siger, at underrækkeværdier for en kolonneliste i en tabel skal vises et andet sted for en kolonneliste, hvis kolonner danner et SQL UNIQUE NOT NULL kolonnesæt (som PK er et tilfælde af) i deres tabel. Hvis dit design er underlagt en begrænsning, og det ikke er underforstået af andre håndhævede begrænsninger, skal du håndhæve det. Ellers lad være. Gerne deklarativt. De fleste SQL DBMS'er lader dig kun erklære nogle få slags begrænsninger, der er billige at håndhæve. Andre skal håndhæves via triggere.
Begrænsningerne er en konsekvens af kriterierne for rækker, der går ind i forhold til at holde sig ude af tabeller i en given situation (tabellen prædikater , "hvad tabellerne betyder") og hvilke situationer der kan og ikke kan opstå i henhold til dine forretningsregler. Vi ved ikke, hvad det er, medmindre du fortæller os det. Vi kan håbe på at gætte ved at bruge dine tabel- og kolonnenavne, alle andre oplysninger, du giver, og sund fornuft.
dig skal fortælle os enten begrænsningerne eller prædikaterne &hvilke situationer der kan/ikke kan opstå.
Her bruger dine tabeller en ligetil tabel plus noget EAV-design til at registrere dataene fra en enkelt tabel, der ikke er eksplicit i dit design. Som altid kunne du undgå EAV ved blot at bruge DDL til at holde den enkle tabels skema &begrænsninger opdateret, men i stedet har du valgt et statisk skema, der kræver mere komplekst skema, forespørgsler og begrænsninger. Det ligefremme udtryk for EAV-begrænsningerne er typisk, at den ligefremme tabel, de repræsenterer, har visse begrænsninger plus at t_criteria_x er visninger af den og/eller at den er en visning af dem. Men typisk lader de eneste tilgængelige SQL-erklæringer dig blot udtrykke fragmenter af det.
Jeg gætter at det du har til hensigt her inkluderer, at for hver t_criteria_x-tabel skal dens PK-værdi vises i t_criteria_director med en tabelnavn-værdi 't_criteria_x'. En anden måde at sige dette på er, at hvis du tilføjede en tabelnavn-kolonne til t_criteria_x med værdien 't_criteria_x', så skal resultatet have (id, tabel_navn) underrækker, der vises som t_criteria_director (criteria_id, table_name) underrækker. Hvis også t_criteria_director (criteria_id, table_name) underrækker er SQL UNIQUE NOT NULL, så har vi, at den udvidede t_criteria_x har en sammensat SQL FK (id, table_name), der refererer til t_criteria_director (criteria_id, table_name). Du kan udtrykke dette deklarativt ved faktisk at øge t_criteria_x med sådan en (muligvis beregnet/genereret/beregnet) kolonne. Men du har sikkert også andre begrænsninger, som at der ikke er nogen (constraint_id, table_name) par i t_criteria_director, der ikke refereres til af nogle forstærkede t_constraint_x.
Kaldning af kolonnen tabelnavn viser en implementeringsorienteret bias fra EAV, fordi den kolonne er en type/variant diskriminator/tag i ER-forstand, at typerne af entiteter repræsenteret af id'erne i t_criteria_x-tabellerne er "undertyper" af entitetstypen repræsenteret af t_criteria_director. (Dette er også et koncept/teknik fra 3GL-registreringsdatastrukturer, der bruges til dynamisk simulering af indtastning.) Når alt kommer til alt, behøver kolonneværdien tabelnavn ikke at være et tabelnavn, den skal bare være en værdi, der identificerer entitetsundertypen, og sådanne enheder behøver ikke kun at deltage i ét bords forhold/tilknytning. (Forskning i SQL/database/ER subtyping/polymorfi/arv og design-antimønsteret to/mange/flere FK'er [sic] til to/mange/flere tabeller.)
Du skal bestemme, hvad tabelprædikaterne er, og hvad deres begrænsninger derfor er. Fortrinsvis ved at bestemme, hvad den enkle tabel, de tilsammen repræsenterer, er, og hvad dens prædikat er, og hvilke databasebegrænsninger, der bruger den. Så skal du beslutte, om du pr. cost/benefit vil ændre dit design for at gøre begrænsninger deklarative, og/eller du skal eller ikke vil håndhæve begrænsninger via triggere.