数据库参照完整性的值有什么规则

我当时就一头雾水……这东西好像有问题。
2 02 2 年，我还在一家公司做数据录入，每天和这些表格打交道。

在员工列表中，员工编号是唯一的，不能重复。
在部门表中，部门编号也是唯一的。
员工的内部和外部部门编号必须遵循这两条规则。

首先，部门编号可以为空。
这是什么意思？这是尚未分配部门的员工。
也许他刚来，HR还没有给他部门号码。
如果为空就为空，数据库不会阻止。

其次，如果部门编号不为空，则需要在部门表中查找对应的部门编号。
不要盲目地写。
例如，在部门表中，部门编号为01 ，对应于销售部门。
在员工表中，特定员工的部门号不能写为9 9 ，因为这个部门根本不存在。
您必须填写 01 ，或者留空。

这称为引用完整性。
就是保证员工表中的部门号为空或者部门表中必须存在。
别开玩笑了。

如果呢？如果你写了一个不存在的部门编号，那么在检查数据库的时候就会出现问题。
例如，如果你想查看这个员工在哪个部门，但是数据库说没有这个部门号，那不是灾难吗？
所以，外键和主键必须这样使用。
员工表的部门编号是外键，它指的是部门表的主键——部门编号。
保持一致，不要混乱。

正如参考资料中提到的，学生参加课程的例子是类似的。
课程编号是课程表中的主键。
学生成绩表中的课程号是外键，必须参考课程大纲中的课程号。
不可能编写课程大纲中不存在的课程编号。
例如，如果课程编号为1 00，但课程大纲中没有课程1 00，则不起作用。

保持一致：这就是参照完整性。
到 2 02 2 年，这就是我们公司数据库的使用方式。
体量不大，只有几千条记录，但必须按照规则去做。
多少？也许仅仅保持这种诚信并花更多的时间避免错误只需要几百或几千元。

数据库命名的规则

老实说：数据库命名非常重要，应该仔细考虑。

从最简单的名称开始，使用简短且有意义的名称。
例如，存储用户信息的称为 user_db，比这更长的任何东西称为 userinfo_database_system，但我厌倦了听到这个。
订单表称为订单，您不必经历所有曲折的customer_order_information。

但是，请注意不要使用缩写。
例如，cust_ord_dtl 乍一看可能会让初学者感到困惑。
即使团队中的每个人都理解，新员工在入职期间也被迫提出棘手的问题，这会影响效率。
最好像order_details一样写清楚。

风格要统一。
下划线或驼峰式大小写应由团队提前决定并写入文档中。
例如，不要跨项目混合 user_profile 或 UserProfile。
如果您不混合它们，那么在查看代码时您最终会感到困惑。

此外，不能使用数据库中的保留字，例如 select 和 from。
检查官方文档以避免陷阱。

请为姓名留出空间，因为将来可能会添加一些内容。
例如，user_db_v1 后来被修改为user_db_v2 这使得版本变得清晰并且使调查问题变得更加容易。

坦白说，仅此而已。
保持简单，不要缩写，使用一致的风格，不要使用保留字，留下逃生路线，并保留版本号。

遵循数据库三大原则

设计数据库时请记住这三点。

1 .冗余控制很重要。
不要过多重复您的数据。
例如，将学生信息放在单独的学生表中，不要放在每个教学大纲中。
学号、姓名、院系，这些都放在学生体内外。

我上次做2 02 3 年的项目时就是这样做的。
学生表中存储学号和院系，选科表中只存储学号和科目号。
这样，如果一个学生换院系，他只需要改变学生名单中的一项，而不需要改变很多地方。

第三范式（3 NF）很有用。
选择非主键且与主键无关的列。
例如，如果订单表中存在某种产品的单价，但该单价在一年内可能不会发生变化，则可以在产品表中单独设置单价。
这将使订单变得更小。

不过请注意，如果分享得太细，有时检查速度会比较慢。
这要视情况而定，不能盲目追求高范式。
上周和同事讨论后，觉得某个功能太慢，无法查看，所以又加了一些反汇编的数据回来。

2 还必须遵循一致性原则。
多个表之间的关联必须是可靠的。
例如，选课表中的学生ID必须是学生表中找到的学号。

我的朋友上次搞砸了一个项目，忘记添加外键约束。
结果，一个人被从学生名单中删除，但他的记录却留在了选课列表中，成为了孤儿记录。
数据不匹配，一切都一片混乱。

在进行事务处理时，必须保证ACID属性。
就像银行转账一样，要么双方都成功，要么都失败。
不能同时成功和失败，否则数据会不一致。

3 必须贯彻诚信原则。
主键不能为空，并且必须是唯一的。
比如学号为主键，每个学生一个，不能重复，不能为空。

外键还必须指向有效数据。
例如，选课表中的系号必须能够在系表中找到对应的编号。
如果你找不到它，那就不行了。

还有用户定义的完整性。
例如，性别只能是男性或女性，分数只能在0到1 00之间。
如果有人插入“其他”性别，或者插入分数为1 05 ，数据库将不允许他插入。

4 在实际应用中，还有一些扩展原则。
例如冷热分离，将经常检查的数据与很少检查的数据分离。
我上次就用过这个方法，查询速度明显提高。

单独保存长文本也很好，例如产品描述。
如果放在主表中，主表会太大，检查会很慢。

您还可以记录创建时间、更改时间以及操作者。
很容易找出是否存在这样的问题。

总之，这些原则一定要记住。
但是否使用以及如何使用取决于业务场景。
例如，如果电子商务并发性很高，可能需要牺牲一些一致性来换取性能。
由你决定。

数据库参照完整性问题

嘿，我们来谈谈数据库中的引用完整性。
说起来，这个东西对于保证数据的一致性和准确性来说确实很重要。

我们先来说一下定义。
引用完整性就像数据库中的流量规则，确保数据之间的关系与流量一样有组织。
这意味着当您想要向外键（一个表中引用另一表的主键的字段）插入或更新数据时，必须确保所引用的主键值存在于相关表中。
简而言之，数据之间不应该存在不匹配。

我以前也遇到过这个问题。
记得有一次，在我负责的一个项目中，一个表的外键引用了另一个表的主键。
结果，我们不小心输入了一个不存在的值。
结果数据乱了，我花了很长时间才弄清楚。
很头疼。

如何获得？数据库系统自动检查这些规则。
当您尝试插入或更新数据时，系统会帮助您查看外键中的值是否在相应的主键表中。
如果不存在，则直接拒绝操作。

这件事的重要性是显而易见的。
引用完整性是数据库完整性的基石。
与实体完整性一样，它是确保数据库质量的关键。
在信息时代，数据的准确性和一致性对于我们的研究和决策至关重要。
很重要对于.
应用场景无处不在。
例如，在订单管理系统中，您肯定不希望在订单中看到不存在的客户信息，对吧？这同样适用于客户关系管理系统。
确保客户信息准确对于维护客户关系至关重要。

总的来说，引用完整性就像数据库中的交警，确保数据之间的顺序。
虽然这看起来有些极端，但实际上是一个不可忽视的环节。