标签:主键 高效 spatial 数据库 时间 没有 sql 含义 包含
之前在学习后端开发的时候,在数据库这一块,有关建表与查询效率等方面一直存有疑问,但因为做的项目都很小,不太需要考虑效率与规范,所以想着能实现功能就行。因此最近打算深入了解一些建表的规范以及如何提高查询效率。
命名规范的话,之前倒是都有注意,大致总结为以下几点:
PS:在数据库表字段命名时;不建议使用数据库关键字,如:name,time ,datetime password 等
这一块我之前很少了解,这里着重总结一下。参考了深入浅出数据库索引原理这篇博客,讲的比较形象。
创建索引是很简单的,有如下语法
CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name [USING index_type] ON table_name (index_col_name,...)
如果不指定索引类型,则默认是普通索引。[]内为可选项。以及删除索引的操作如下
DROP INDEX index_name ON talbe_name
ALTER TABLE table_name DROP INDEX index_name
上下两条语句是等价的。
添加索引的目的是为了提高查询效率,但并不是无脑添加的,不恰当的添加索引还可能降低效率。在这方面参考了这篇博客Mysql创建索引。简单来说,添加索引有以下一些建议:对常用于条件查询的字段,查询中排序的字段,查询中与其他表关联的字段添加索引。对于记录数较少的表,需要频繁插入、更改的表不建议建立索引。因为索引本身也要占据空间,以及每次修改操作需要修改索引,有一定时间开销。
这个地方参考了数据库的三大范式和五大约束、数据库设计三大范式等博客文章
第一范式(1NF):数据表中的每一列(字段),必须是不可拆分的最小单元,也就是确保每一列的原子性。
第二范式(2NF):满足1NF后要求表中的所有列,都必需依赖于主键,而不能有 任何一列与主键没有关系(一个表只描述一件事情)。否则就需要拆成两张表。
第三范式(3NF):满足2NF后,要求:表中的每一列都要与主键直接相关,而不是间接相关(表中的每一列只能依赖于主键)。这里可能不太好理解,举个例子:订单表中需要有客户相关信息,在分离出客户表之后,订单表中只需要有一个用户ID即可,而不能有其他的客户信息,因为其他的用户信息是直接关联于用户ID,而不是关联于订单ID。
以上的定义讲的比较书面,简单地可以这样总结:
①第1范式:每个表中列都是不可拆分的最小单元
②第2范式:一张表只描述一件事情,即所有列都与主键有关
③第3范式:用外键做表的关联,除此之外不要储存其他表的信息
原则上数据库的设计要遵守以上三大范式,但这只是一般设计数据库的基本理念,可以建立冗余较小、结构合理的数据库。如果有特殊情况,当然要特殊对待,数据库设计最重要的是看需求跟性能,需求>性能>表结构。所以不能一味的去追求范式建立数据库。
比较针对地对数据库的使用进行了一次粗略学习,了解了一些数据库的规范和特点。不过对于目前而言,在项目用户量较小的情况下,这些用于提高效率或减少冗余的知识可能用处不大,但尽早了解总是有益的。
标签:主键 高效 spatial 数据库 时间 没有 sql 含义 包含
原文地址:https://www.cnblogs.com/orangee/p/9750716.html