外检约束,当前各公司的规范不一。例如很多公司为了未来的业务可拆分,系统性能,规定表不能创建外检约束。在应用层使用逻辑进行数据的校验。
但是有些场景下,我们又觉得创建外检约束更奈斯。所以这里还是写下:
-- 定义外键约束:
CREATE TABLE 从表名
(
字段 字段类型
....
CONSTRAINT 外键约束名称
FOREIGN KEY (字段名) REFERENCES 主表名 (字段名称)
);
ALTER TABLE 从表名 ADD CONSTRAINT 约束名 FOREIGN KEY 字段名 REFERENCES 主表名 (字段名);
实际的使用,我在网上随便找了一个例子供大家参考:
第一步,创建一个基表
CREATE TABLE demo.importhead (
listnumber INT PRIMARY KEY,
supplierid INT,
stocknumber INT,
importtype INT,
importquantity DECIMAL(10 , 3 ),
importvalue DECIMAL(10 , 2 ),
recorder INT,
recordingdate DATETIME
);
第二步,创建一个详细表,以listnumber作为外键关联
CREATE TABLE demo.importdetails
(
listnumber INT,
itemnumber INT,
quantity DECIMAL(10,3),
importprice DECIMAL(10,2),
importvalue DECIMAL(10,2),
-- 定义外键约束,指出外键字段和参照的主表字段
CONSTRAINT fk_importdetails_importhead
FOREIGN KEY (listnumber) REFERENCES importhead (listnumber)
);
最终查看,我们就用到 MySQL 自带的、用于存储系统信息的数据库:information_schema
这里我将在sqlyog工具里面查询的结果展示下:
具体的SQL我也粘贴出来:
SELECT constraint_name, -- 表示外键约束名称
table_name, -- 表示外键约束所属数据表的名称
column_name, -- 表示外键约束的字段名称
referenced_table_name, -- 表示外键约束所参照的数据表名称
referenced_column_name -- 表示外键约束所参照的字段名称
FROM information_schema.KEY_COLUMN_USAGE
WHERE constraint_name = 'fk_importdetails_importhead';
通过查询,我们可以看到,外键约束所在的表是“importdetails”,外键字段是“listnumber”,参照的主表是“importhead”,参照的主表字段是“listnumber”。这样,通过定义外键约束,我们已经建立起了 2 个表之间的关联关系。
实际使用中,不能一概而论,外键约束是一把双刃剑。
我所见的金融系统中,为了避免各个业务系统,随意增加财务系统对接的银行。往往财务系统,创建一张银行列表的基表,各个业务系统只能从该基表的银行中取值,不然无法进行送盘处理。这时,各个业务系统往往会增加银行字段的外检,来加以校验,因为金融系统真的太复杂了。单靠应用层的逻辑校验远远不够。