Вашият дизайн не "изглежда" нищо, защото не можем да четем мислите ви. Дадохте някои аспекти на дизайна, но не и бизнес „сценария“, който той представлява/прилага/описва или как го прави.
SQL NULL, UNIQUE, PKs &FKs са видове ограничения. Ограничението е ограничение за това какви стойности на базата данни могат да се показват. SQL FK казва, че стойностите на подреда за списък с колони в таблица трябва да се показват другаде за списък с колони, чиито колони образуват SQL UNIQUE NOT NULL набор от колони (което PK е случай) в тяхната таблица. Ако вашият дизайн е обект на ограничение и не се подразбира от други наложени ограничения, наложете го. В противен случай недей. За предпочитане декларативно. Повечето SQL СУБД ви позволяват да декларирате само няколко вида евтини за прилагане ограничения. Други трябва да бъдат наложени чрез тригери.
Ограниченията са следствие от критериите за влизане на редове и оставане извън таблици в дадена ситуация (таблицата предикати , „какво означават таблиците“) и какви ситуации могат и не могат да възникнат според вашите бизнес правила. Не знаем какви са, освен ако не ни кажете. Можем да се надяваме да гадаем, използвайки имената на вашите таблици и колони, всяка друга информация, която давате, и здравия разум.
Вие трябва да ни кажете на ни или ограниченията, или предикатите и какви ситуации могат/не могат да възникнат.
Тук вашите таблици използват проста таблица плюс някакъв EAV дизайн, за да записват данните от някаква проста таблица, която не е изрично във вашия дизайн. Както винаги можете избягвайте EAV, като просто използвате DDL, за да поддържате актуална схемата и ограниченията на простата таблица, но вместо това сте избрали статична схема, която изисква по-сложна схема, заявки и ограничения. Ясният израз на ограниченията на EAV обикновено е, че простата таблица, която представляват, има определени ограничения плюс че t_criteria_x са изгледи на нея и/или че е изглед от тях. Но обикновено единствените налични SQL декларации просто ви позволяват да изразите фрагменти от това.
Предполагам че това, което възнамерявате тук, включва, че за всяка таблица t_criteria_x нейната PK стойност трябва да се появи в t_criteria_director със стойност на table_name 't_criteria_x'. Друг начин да се каже това е, че ако добавите към t_criteria_x колона table_name със стойност 't_criteria_x', тогава резултатът трябва да има (id, table_name) подредове, които се появяват като t_criteria_director (criteria_id, table_name) подредове. Ако също Подредовете на t_criteria_director (идентификатор_на_критерия, име_на_таблица) са SQL УНИКАЛНО НЕ NULL, тогава имаме, че този увеличен t_criteria_x има съставен SQL FK (id, table_name), препращащ t_criteria_director (идентификатор_на_критерия, име_на_таблица). Можете да изразите това декларативно, като действително увеличите t_criteria_x с такива (евентуално изчислени/генерирани/изчислени) колони. Но вие вероятно имате и други ограничения, като например няма двойки (constraint_id, table_name) в t_criteria_director, които не са реферирани от някакъв увеличен t_constraint_x.
Извикването на колоната table_name показва ориентирано към реализацията отклонение от EAV, тъй като тази колона е дискриминатор/таг на тип/вариант в смисъл на ER, че типовете обекти, представени от идентификаторите в таблиците t_criteria_x, са "подтипове" на типа обект, представен от t_criteria_director. (Това също е концепция/техника от структури от данни на 3GL запис, използвани за динамично симулиране на въвеждане.) След като цялата стойност на колоната table_name не трябва да бъде име на таблица, тя просто трябва да бъде някаква стойност, която идентифицира подтипа на обекта, и такива субекти не трябва да участват само в една връзка/асоциация на една таблица. (Изследвайте подтипове на SQL/база данни/ER/полиморфизъм/наследяване и анти-модел на проектиране от две/много/множество FK [sic] до две/много/множество таблици.)
Трябва да определите какви са предикатите на таблицата и какви следователно са техните ограничения. За предпочитане е чрез определяне на това какво представлява простата таблица, която заедно представляват и какъв е нейният предикат и какви ограничения на базата данни я използват. След това трябва да решите дали по цена/полза ще модифицирате своя дизайн, за да направите ограниченията декларативни и/или сте или няма да налагате ограничения чрез тригери.
