pk 与fk mysql_mysql – 有没有办法在以下场景中维护数据库关系(pk / fk)

你的设计并不“看似”任何东西,因为我们无法读懂你的想法.您已经给出了设计的某些方面,但没有给出它代表/实现/描述的业务“场景”或者它是如何实现的.

SQL NULL,UNIQUE,PKs& FK是各种约束.约束是对可以出现的数据库值的限制. SQL FK表示表中列列表的子行值必须出现在列表列表的其他地方,列列表的列中形成了SQL UNIQUE NOT NULL列集(其中PK是一个例子).如果您的设计受到约束并且其他强制约束不暗示,则强制执行.否则不要.最好以声明方式.大多数SQL DBMS只允许您声明一些廉价的强制约束.其他必须通过触发器强制执行.

约束是在给定情况下进入vs退出表的行的标准的结果(表谓词,“表格的含义”)以及什么情况可以&根据您的业务规则不能出现.除非你告诉我们,否则我们不知道那是什么.我们希望能够使用您的桌子和列名,您提供的任何其他信息&常识.

你必须告诉我们约束或谓词&什么情况可以/不会出现.

在这里,您的表格使用简单的表格和一些EAV设计来记录您设计中未明确表达的一些简单表格的数据.一如既往,你可以通过使用DDL来保持简单的表的架构和放大器来避免EAV.约束是最新的,但你选择了一个静态模式,需要更复杂的模式,查询和限制. EAV约束的直接表达通常是它们表示的直接表具有某些约束加上t_criteria_x是它的视图和/或它是它们的视图.但通常只有可用的SQL声明才能表达它的碎片.

我猜你在这里打算包括每个t_criteria_x表,它的PK值必须出现在t_criteria_director中,其table_name值为“t_criteria_x”.另一种方法是,如果向t_criteria_x添加值为“t_criteria_x”的table_name列,则结果必须具有(id,table_name)子行,并显示为t_criteria_director(criteria_id,table_name)子行.如果t_criteria_director(criteria_id,table_name)子行也是SQL UNIQUE NOT NULL,那么我们已经知道扩充的t_criteria_x具有引用t_criteria_director(criteria_id,table_name)的复合SQL FK(id,table_name).您可以通过实际通过这样的(可能计算/生成/计算)列来增加t_criteria_x来声明性地表达这一点.但是您可能还有其他约束,例如t_criteria_director中没有任何(constraint_id,table_name)对未被某些扩充t_constraint_x引用.

调用列table_name显示来自EAV的面向实现的偏差,因为该列是ER意义上的类型/变体鉴别器/标签,即t_criteria_x表中的id表示的实体类型是实体类型的“子类型”由t_criteria_director表示. (这也是用于动态模拟类型的3GL记录数据结构的概念/技术.)在所有table_name列值不必是表名之后,它只需要是标识实体子类型的某个值,并且这些实体不必只参与一个表的关系/关联. (研究SQL /数据库/ ER子类型/多态/继承和设计反模式两个/多个/多个FK [原文如此]到两个/多个/多个表.)

您必须确定表谓词是什么以及它们的约束因此.优选地,通过确定它们共同表示的简单表是什么&它的谓词是什么以及数据库约束使用它的是什么.然后,您必须决定每个成本/收益是否要修改您的设计以使约束声明和/或您是否要通过触发器强制执行约束.