关系型数据库的特点 关系型数据库设计原则与步骤

说实话，我第一次接触关系数据库是在学习期间。
当时我正在设计一门使用MySQL的课程。
我直接像Excel一样画出数据表有行有列，立马就明白了。
这个模型真的很强大。
它将复杂世界中的事物变成桌子，这让每个人都高兴。

有趣的是，在设计数据表时，首先要定义字段。
比如之前做项目的时候，有同学坚持要保存身份证号。
原来是身份证号长度不一样，字段设计崩了。
这就是标准化的优点。
数据被分解成小块并存储在不同的表中。
虽然查询时需要连接表，但数据本身非常干净。
我记得使用 SQL 编写一个带有 JOIN 的查询，并且能够获取所有相关数据。
这比直接在文件中搜索要好得多。

但是说到SQL，它真的很棒，CRUD操作是如此简单。
但我在索引方面也遇到了问题。
在早期的项目中，没有索引，并且在检查数百个数据时陷入困境。
后来我加了几个字CREATE INDEX，结果几秒钟就出来了。
这让我意识到索引是性能加速器，但如果使用不当，它们可能会成为一种负担。

ACID 规则是另一个重要点。
我曾经做过事务处理，发现没有遵循这四个原则。
结果，数据要么丢失，要么损坏。
例如，有一个不使用原子性的支付系统。
扣款成功，但是压痕失败，直接炸客户。
修改之后才稳定下来。

但是，关系数据库也有明显的缺点，特别是在可扩展性方面。
我参与了一个电子商务项目。
用户数量增加后，数据库崩溃了。
老板想加机器来分散压力，但发现把表和数据库拆分成关系型数据库特别有问题，而且不像NoSQL那么灵活。
如今，许多大型制造商都使用分布式解决方案，并将关系数据库划分为小部分。

成本确实不低，像Oracle、SQL Server一样要花钱才能使用。
尽管免费MySQL被广泛使用，但它的高级功能很少且性能有限。
曾经有一段时间，项目预算很紧张，我几乎被要求改用 PostgreSQL。
幸运的是，我最终取得了胜利。

在设计阶段，我更喜欢从用户的需求出发，先画一个ER图或者类似的东西，清楚地列出实体和属性。
然后我们必须继续考虑数据完整性。
例如，地址字段不能为空，用户名不能重复。
如果没有这些限制，数据很容易混乱。
减少冗余尤为重要。
我见过人们在相同的产品价格上省了数百次，而清理数据最终变得很累人。

整个生命周期的管理也非常关键。
从设计到运营，每一步都不能含糊。
我更新过一次系统，无法备份数据。
结果，所有数据都丢失了。
我能够进去这几天实在是睡不着觉。
因此，数据库维护不仅仅是一个形式，而必须是一个实际的事情。

关系数据库虽然不是万能的，但它仍然是结构化数据的领导者。
现在很多新系统都要处理这个问题，所以掌握设计原理和SQL知识是有意义的。

数据库设计的基本原则是什么？

上周我看到了这个数据库设计原理。

1 .基本设计原则
1 ．层次清晰、布局合理 数据库必须是分层的。
卷必须正确分区。
逻辑和物理必须分开。
这非常有效。
也适合后期修改。

2 确保安全机制 数据必须是分层的。
通过用户角色控制权限。
底层数据必须加密。
运输、储存和使用必须安全。
防止他人随意更改。

3 很有组织性 使用标准表格。
就像关系模型一样。
表和字段必须统一。
这减少了重复。
查询速度很快。
以后改进的话会更好。

2 基本设计原则
1 ．个性化设计原则 实体关系必须清晰。
例如用户和命令。
使用外键进行通信。
不要混淆它。
易于维护。
数据是一致的。
系统也更加稳定。

2 独特的命名原则 字段名和表名必须有规则。
例如，使用下划线。
不要将用户与客户混淆。
用户表称为user_info。
这样代码就更少了。
发展迅速。
调试也很容易。

3 双向使用原则

事务使用原则：操作必须是原子的。
比如银行转账。
要么两者都做。
或者什么也不做。
半途而废。


索引函数原理：需要建立索引。
聚集索引适合范围查询。
非聚集索引适合细粒度的搜索。
不要添加太多。
否则写入数据会很慢。

3 扩展原理 设计时留出空间。
如果数据很多，可以分表。
或者分库。
当新功能到来时。
无需更改旧代码。