数据库设计

在文章 《Nebula 架构剖析系列（一）图数据库的存储设计》 中，我们提过分布式图存储的管理由 Meta Service 来统一调度，它记录了所有 partition 的分布情况，以及当前机器的状态。当 DBA 增减机器时，只需要通过 console 输入相应的指令，Meta Service 便能够生成整个 Balance 计划并执行。而之所以没有采用完全自动 Balance 的方式，主要是为了减少数据搬迁对于线上服务的影响，Balance 的时机由用户自己控制。 在本文中我们将着重讲解在存储层如何实现数据和服务的负载平衡。 简单回顾一下， Nebula Graph 的服务可分为 graph，storage，meta。本文主要描述对于存储层（storage）的数据和服务的 balance。这些都是通过 Balance 命令来实现的：Balance 命令有两种，一种需要迁移数据，命令为 BALANCE DATA ；另一种不需要迁移数据，只改变 partition 的 raft-leader 分布（负载均衡），命令为 BALANCE LEADER 。 本文目录 Balance 机制浅析 集群数据迁移 Step 1：准备工作 Step 1.1 查看现有集群状态 Step 1.2 创建图空间 Step 2 加入新实例 Step 3 迁移数据 Step 4 假如要中途停止 balance

欢迎访问我的网站 http://www.wenzhihuai.com/ 。感谢，如果可以，希望能在GitHub上给个star，GitHub地址 https://github.com/Zephery/newblog 。 一、概述 　1.1 缓存介绍 系统的性能指标一般包括响应时间、延迟时间、吞吐量，并发用户数和资源利用率等。在应用运行过程中，我们有可能在一次数据库会话中，执行多次查询条件完全相同的SQL，MyBatis提供了一级缓存的方案优化这部分场景，如果是相同的SQL语句，会优先命中一级缓存，避免直接对数据库进行查询，提高性能。 缓存常用语： 数据不一致性、缓存更新机制、缓存可用性、缓存服务降级、缓存预热、缓存穿透 可查看 Redis实战（一） 使用缓存合理性 1.2 本站缓存架构 从没有使用缓存，到使用mybatis缓存，然后使用了ehcache，再然后是mybatis+redis缓存。 步骤： （1）用户发送一个请求到nginx，nginx对请求进行分发。 （2）请求进入controller，service，service中查询缓存，如果命中，则直接返回结果，否则去调用mybatis。 （3）mybatis的缓存调用步骤：二级缓存->一级缓存->直接查询数据库。 （4）查询数据库的时候，mysql作了主主备份。 二、Mybatis缓存 2.1 mybatis一级缓存

我在 很久之前的一篇文章 中介绍了数据库模型设计中的基本三范式，今天，我来说一说更高级的BC范式和第四范式。 回顾 我用大白话来回顾一下什么是三范式： 第一范式：每个表应该有唯一标识每一行的主键。 第二范式：在复合主键的情况下，非主键部分不应该依赖于部分主键。 第三范式：非主键之间不应该有依赖关系。 这是我们设计数据库的基本规则，但是只有这三个规则并不能完全解决数据的增删改的异常情况，下面就来看看BC范式的例子。 BC范式 BC范式（BCNF）是Boyce-Codd范式的缩写，其定义是：在关系模式中每一个决定因素都包含候选键，也就是说，只要属性或属性组A能够决定任何一个属性B，则A的子集中必须有候选键。BCNF范式排除了任何属性(不光是非主属性，2NF和3NF所限制的都是非主属性)对候选键的传递依赖与部分依赖。 比如我们有一个学生导师表，其中包含字段：学生ID，专业，导师，专业GPA，这其中学生ID和专业是联合主键。 StudentId Major Advisor MajGPA 1 人工智能 Edward 4.0 2 大数据 William 3.8 1 大数据 William 3.7 3 大数据 Joseph 4.0 这个表的设计满足三范式，有主键，不存在主键的部分依赖，不存在非主键的传递依赖。但是这里存在另一个依赖关系，“专业”函数依赖于“导师”

数据库设计中的12个技巧 1.原始单据与实体之间的关系 可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张 原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一 张原始单证对应多个实体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。 明确这种对应关系后，对我们设计录入界面大有好处。 〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情 况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。 2.主键与外键 一般而言，一个实体不能既无主键又无外键。在E—R图中,处于叶子部位的实体,可 以定义主键，也可以不定义主键(因为它无子孙),但必须要有外键(因为它有父亲)。 主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成 以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就 是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为： 主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。 3.基本表的性质 基本表与中间表、临时表不同，因为它具有如下四个特性： (1)原子性。基本表中的字段是不可再分解的。 (2)原始性。基本表中的记录是原始数据（基础数据）的记录。 (3)演绎性

1.原始单据与实体之间的关系 可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。 〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。 2.主键与外键 一般而言，一个实体不能既无主键又无外键。在E—R图中,处于叶子部位的实体,可以定义主键，也可以不定义主键(因为它无子孙),但必须要有外键(因为它有父亲)。 主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。 3.基本表的性质 基本表与中间表、临时表不同，因为它具有如下四个特性： (1)原子性。基本表中的字段是不可再分解的。 (2)原始性。基本表中的记录是原始数据（基础数据）的记录。 (3)演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。 (4

参照http://blog.sina.com.cn/s/blog_735fb3b40100svet.html 数据库设计的过程(六个阶段) 　 1. 需求分析阶段 　　　准确了解与分析用户需求（包括数据与处理） 　　　是整个设计过程的基础，是最困难、最耗费时间的一步 　　2. 概念结构设计阶段 　　　是整个数据库设计的关键 　　　通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS 数据库 管理 系统 (Database Management System) 的概念模型 　　3. 逻辑结构设计阶段 　　　将概念结构转换为某个DBMS所支持的数据模型 　　　对其进行优化 　　4. 数据库物理设计阶段 　　　为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法） 　　5. 数据库实施阶段 　　　运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果 　　　建立数据库，编制与调试应用程序，组织数据入库，并进行试运行 　　6. 数据库运行和维护阶段 　　　数据库应用系统经过试运行后即可投入正式运行。 　　　在数据库系统运行过程中必须不断地对其进行评价、调整与修改 　　设计特点: 　　　在设计过程中把数据库的设计和对数据库中数据处理的设计紧密结合起来将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计

1. 原始单据与实体之间的关系 　可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。 　　〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。 　2. 主键与外键 　一般而言，一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。 　　主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。 　3. 基本表的性质 　　基本表与中间表、临时表不同，因为它具有如下四个特性： 　　 (1) 原子性。基本表中的字段是不可再分解的。 　　 (2) 原始性。基本表中的记录是原始数据（基础数据）的记录。 　　 (3) 演绎性

1.范式说明 1.1 第一范式（1NF）无重复的列 　　所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能同时有多个值， 即实体中的某个属性不能有多个值或者不能有重复的属性 。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。 　　在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。 在当前的任何关系数据库管理系统（DBMS）中，不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。 举例1： 比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。 UserInfo(ID,Name,Age,LinkTel,Province,City,Address)

0.参考文献： http://www.cnblogs.com/xwdreamer/archive/2012/05/17/2506039.html 1.范式说明 1.1 第一范式（1NF）无重复的列 　　所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能同时有多个值， 即实体中的某个属性不能有多个值或者不能有重复的属性 。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。 　　在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。 在当前的任何关系数据库管理系统（DBMS）中，不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。 举例1： 一张学生表Student(stuNo,stuName,age,age,sex)是不符合第一范式的，因为有重复列age属性。去除重复列age以后的Student(stuNo,stuName,age,sex)是符合第一范式的。 1.2 第二范式（2NF）属性完全依赖于主键 [ 消除部分子函数依赖 ] 　　第二范式

文章目录 一、效果预览 二、源码下载 三、预备知识 四、文件结构 五、数据库设计 六、部分代码展示 1、数据库增删改查 2、JSON数据解析 3、ashx的使用 一、效果预览 音乐网站视频效果预览 二、源码下载 源码已经上传到了我的 GitHub ，感兴趣的朋友请点击下方连接到达页面clone下载，感觉还行的话求 star 点我前往连接 三、预备知识 四、文件结构 五、数据库设计 下面是数据库的三张表： use db_music go create table tb_musicInfo ( id int primary key , musicType int , speciaName varchar ( 500 ) , musicName varchar ( 500 ) , lyricPath varchar ( 500 ) , singerName varchar ( 500 ) , auditionSum int , downSum int , fileSize char ( 10 ) , imgs varchar ( 500 ) , country varchar ( 500 ) , addtime datetime , zhuanji varchar ( 500 ) , zjimg varchar ( 500 ) , style varchar ( 200 ) , )