补上周老大的文档

Markdown文档排版规范.md

@@ -0,0 +1,188 @@
+<div align=center><font size=5>众望通科技 研发中心</font></div>
+<div align=center><font size=6>Markdown文档排版规范</font></div>
+
+> <div><font>拟稿：周志尧</font></div>
+> <div><font>版本号： 1.0.0 </font></div>
+> <div><font>发布时间：2020.10.06 </font></div>
+
+[TOC]
+
+## 1 语法规范
+
+推荐使用 [GitHub GFM](https://link.zhihu.com/?target=https%3A//github.github.com/gfm/) 规范
+
+
+
+## 2 排版规范
+
+### 2.1 标题层级
+
+- 文章的顶层标题使用 **二级标题**
+- 每个小节的标题使用 **三级标题**
+- 小节中需要进一步分层组织时，使用 **四级标题**
+- 尽量少用 **五级标题** 和 **六级标题**，考虑用有序列表和无序列表代替
+- 完全不用 **一级标题**
+- 标题的 **序号数字** 和 **标题文字** 之间空一格
+
+
+
+### 2.2 空行
+
+-  不要有多余的空行，不要连续空两行及以上。 
+   
+-  文件末尾空一行，大多数格式检查工具都会检查文件末尾的空行。
+   
+-  正文段落之间用一个空行来分隔，可以显得段落分明、结构不拥挤，如：
+   
+   > Markdown 是一种标记语言。在写作时，你的所有文字都是没有样式的纯文本，在其中插入若干 Markdown 标记后，被标记的文字便有了样式。
+   >
+   > 比如，在你所写的文字中，希望某一行的最终排版呈现一级标题的样式，那就给这行文字加个一级标题的标记；某个地方有两个字需要加粗，那就给这两个字加个粗体标记。
+   
+   
+
+### 2.3 空格
+
+Markdown 中 **半角空格** 的使用很重要，一些情况下能调节文字间距使得排版更加美观：
+
+* 中英文之间需要增加空格
+
+  > 在 LeanCloud 上，数据存储是围绕 `AVObject` 进行的。
+
+* 中文与阿拉伯数字之间需要增加空格
+
+  > 今天出去买菜花了 5000 元。
+
+* 数字与单位之间需要增加空格（例外：度 / 百分比与数字之间不需要增加空格）
+
+  > 我家的光纤入屋宽带有 10 Gbps，SSD 一共有 20 TB。
+  >
+  > 新 MacBook Pro 有 15% 的 CPU 性能提升。
+
+* 链接之间增加空格
+
+  > 访问我们网站的最新动态，请 [点击这里](http://www.chinaweal.com.cn:8090/pms/#/knowledgeBase/index) 进行订阅！
+
+* 加粗、斜体、高亮文本前后加空格
+
+  > 修复了一个 **内存泄露** 问题，该问题由 *someone* 在 `版本 v0.1.1` 中引入。
+
+* 全角标点与其他字符之间不加空格
+
+  > 刚刚买了一部 iPhone，好开心！
+
+- 行内代码的两端各添加一个空格。若行内代码紧邻标点符号，则其与标点之间 **不加** 空格
+
+  > 打开 Linux 虚拟终端，输入 `echo 'Hello World'`。
+
+  
+
+### 2.4 全角和半角
+
+查看百科词条 [全角](https://baike.baidu.com/item/%E5%85%A8%E8%A7%92/9323113) 和 [半形](https://baike.baidu.com/item/%E5%8D%8A%E8%A7%92)。
+
+* 使用全角中文标点
+
+  > 嗨！你知道嘛？今天前台的小妹跟我说「喵」了哎！
+
+* 数字使用半角字符
+
+  > 这个蛋糕只卖 1000 元。
+
+
+
+### 2.5 粗体、斜体
+
+* 粗体
+
+  需要强调某处内容时使用 **粗体**，如：
+
+  > 中文全角标点符号占 **一个** 汉字宽度，英文半角标点占 **半个** 汉字宽度（亦即一个字母宽度）。
+
+* 斜体
+
+  在中文排版中不使用 **斜体**。
+
+  在英文排版中可用斜体表达强调，或表示书名、题目。
+
+
+
+### 2.6 代码
+* 行内代码
+
+  某一行文字中嵌入简短代码时使用 **行内代码**，如：
+
+  > 打开 Linux 虚拟终端，输入 `echo 'Hello World'` 。恭喜，你已经入门 Shell 了 ：）
+
+* 代码块
+
+  展示多行代码时使用 **代码块**，也可用于 XML、JSON、配置项等。尽量在使用代码块时给出语言标识，Markdown 工具会针对该语言高亮显示其中的语言元素。如：
+
+  > \```java
+  > public class Main {
+  >  public static void main(String[] args) {
+  >  System.out.println("Hello World");
+  > }
+  > \```
+
+
+
+### 2.7 图片
+
+Markdown 中使用
+
+> ![图片名称]([https://xx.xx/xx](https://link.zhihu.com/?target=https%3A//xx.xx/xx))
+
+来插入图片，这里的「图片名称」可以任取，但是推荐使用对图片主题具有描述性的文字。
+
+
+
+### 2.8 转义符号
+
+如果不想让 Markdown 标记生效，可以在标记的每个符号前加上反斜杠 \，这样这些符号将按原样显示，不再具有 Markdown 中的特殊意义。
+
+如：
+
+> 不想让引用块标记生效，可以使用 **\>**，将显示为 **>**
+> 不想让二级标题标记生效，可以使用 **\#\#**，将显示为 **##**
+
+
+
+### 2.9 缩进
+- 文章中每个段落的开头 **不要** 缩进。
+- 列表中嵌套列表时，内层列表使用 4 个空格进行缩进。
+- 缩进时使用空格符，不用 Tab 符。
+- 在使用有序列表时，建议同级之间空一行，在上下级不用空行。
+
+
+
+### 2.10 中文标点符号规范
+
+* 标点通用规则
+
+  中文排版时应全文使用中文全角标点，无论内容中是否包含英文词语。
+
+* 省略号
+
+  在中文输入法状态下，可使用「Shift + 6」输入省略号。注意是 6 个点，而非 3 个点，如：
+
+  > 中文里常用的标点有逗号、句号、顿号、冒号……
+
+* 破折号
+
+  在中文输入法状态下，可使用「Shift + -」输入破折号。注意该符号应占两个汉字宽度，如：
+
+  > 破折号，标示语段中某些成分的注释、补充说明或语音、意义的变化。 ——《标点符号用法》
+
+* 波浪线
+
+  在中文输入法状态下，可使用「Shift + `（ESC 键下方）」输入波浪线。可用波浪线表示数值的区间，如：
+
+  > 只要 10～20 分钟你便能掌握这篇文章的要领。
+
+
+
+## 3 工具推荐
+
+编辑器：[Typora](https://typora.io/)，[详细教程](https://sspai.com/post/54912)
+
+Web开发使用插件推荐：[mavonEditor](https://github.com/hinesboy/mavonEditor)

代码开发和版本发布管理规范.md

@@ -0,0 +1,114 @@
+
+
+<div align=center><font size=5>众望通科技 研发中心</font></div>
+<div align=center><font size=6>Git分支与版本发布管理规范</font></div>
+
+> <div><font>拟稿：周志尧</font></div>
+> <div><font>版本号： 1.0.0 </font></div>
+> <div><font>发布时间：2020.10.06 </font></div>
+[TOC]
+
+## GIT分支管理
+
+### 流程管理概述
+
+Git代码管理的流程和规范参考 `Git Flow` 进行设计，详细可以阅读 Vincent Driessen  [A Successful Git Branching Model](http://nvie.com/posts/a-successful-git-branching-model/) 。
+
+### Master分支
+
+master 分支始终代表生产环境的状态，不能直接在上面提交代码。Master分支上的Commit应该Tag，存储正式发布的历史。
+
+![img](https://images.cnblogs.com/cnblogs_com/cnblogsfans/771108/o_git-workflow-release-cycle-1historical.png)
+
+### Develop分支
+
+develop 分支作为功能的集成分支，包含所有的代码提交记录。develop 分支代表针对下一版本的最新交付的代码。开发人员从 develop  分支创建新分支，并开发新功能。功能开发完毕后，将对其进行测试，与 develop 分支合并，在合并了其他功能分支的情况下使用 develop 分支的代码进行测试，然后与 master 分支合并。
+
+
+
+### Feature分支
+每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。以develop分支作为父分支，当功能完成时，合并回develop分支，不能直接合并到master分支。
+
+![img](https:////upload-images.jianshu.io/upload_images/10688548-8f1c46c3455aa2ad.png?imageMogr2/auto-orient/strip|imageView2/2/w/614)
+
+### Release分支
+
+![img](https:////upload-images.jianshu.io/upload_images/10688548-75d87d80cc545cb8.png?imageMogr2/auto-orient/strip|imageView2/2/w/614)
+
+分支名 release-*
+
+Release分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)
+
+发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。
+
+一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上fork一个发布分支。 新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。 另外，这些从新建发布分支以来的做的修改要合并回develop分支。
+ 使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能。 这也打造定义良好的开发阶段（比如，可以很轻松地说，『这周我们要做准备发布版本4.0』，并且在仓库的目录结构中可以实际看到）。
+
+* 常用的分支约定：
+   用于新建发布分支的分支: develop
+   用于合并的分支: master
+   分支命名: release-* 
+
+###  Hotfix分支
+
+分支名 hotfix-*
+
+维护分支或说是热修复（hotfix）分支用于生成快速给产品发布版本（production releases）打补丁，这是唯一可以直接从master分支fork出来的分支。 修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。
+ 为Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。 你可以把维护分支想成是一个直接在master分支上处理的临时发布
+
+hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag
+
+![img](https://images.cnblogs.com/cnblogs_com/cnblogsfans/771108/o_git-workflow-release-cycle-4maintenance.png)
+
+
+
+##  feature功能分支管理
+
+1. **功能划分：**开发负责人对开发需求进行模块划分、工作任务分解，将相对独立的开发功能分配给相应的开发人员，可多个开发协同开发一个功能；
+2. **分支创建：**开发负责人（或开发人员）给相应的开发功能分支命名，可以按功能命名，也可以按照开发人员的姓名命名，如：feature-login；从develop分支拉取创建该分支；# 创建功能分支：git checkout -b feature-login develop
+3. **功能开发**：开发人员在相应的feature分支进行功能开发，每天早晚更新提交feature分支代码；
+4. **分支合并：**开发人员完成功能开发和单元测试后，提交代码后，提交分支合并请求，由项目开发负责人或者Git管理员将相应的feature分支合并到develop分支，合并冲突协同开发人员一起解决；# 开发完成后，合并到develop分支：①git checkout develop ②git merge --no-ff feature-login
+5. **分支删除：**feature分支代码合并回develop之后，将feature分支删除（谁创建谁删除）。# 最后删除分支: git branch -d feature-login
+
+## release预发布分支管理
+
+1. **功能划分：**开发负责人对开发需求进行模块划分、工作任务分解，将相对独立的开发功能分配给相应的开发人员，可多个开发协同开发一个功能；
+
+2. **分支创建：**开发负责人（或开发人员）给相应的开发功能分支命名，可以按功能命名，也可以按照开发人员的姓名命名，如：feature-login；从develop分支拉取创建该分支；# 创建功能分支：git checkout -b feature-login develop
+
+3. **功能开发**：开发人员在相应的feature分支进行功能开发，每天早晚更新提交feature分支代码；
+
+4. **分支合并：**开发人员完成功能开发和单元测试后，提交代码后，提交分支合并请求，由项目开发负责人或者Git管理员将相应的feature分支合并到develop分支，合并冲突协同开发人员一起解决；# 开发完成后，合并到develop分支：①git checkout develop ②git merge --no-ff feature-login
+
+5. **分支删除：**feature分支代码合并回develop之后，将feature分支删除（谁创建谁删除）。# 最后删除分支: git branch -d feature-login
+
+   
+
+## 版本发布流程设计
+
+（工作流发布图）
+
+![img](https://upload-images.jianshu.io/upload_images/10688548-4f2bb2c346ac14bd.png?imageMogr2/auto-orient/strip|imageView2/2/w/419)
+
+
+
+## 补丁规范
+
+### 补丁文件结构
+
+* 工程文件，目录结构遵循约定，与部署环境一致
+
+* auth文件，补丁的授权信息
+
+* version.info文件，补丁的版本信息
+
+* README.txt文件，补丁的描述信息
+
+### 版本号说明
+
+* 
+
+
+### 邮件发布规范
+
+

数据库设计规范_v1.0.4.md

@@ -0,0 +1,288 @@
+<div align=center><font size=5>众望通科技 研发中心</font></div>
+<div align=center><font size=6>数据库设计规范</font></div>
+
+> 拟稿：周志尧
+>
+> <div><font>版本号 1.0.4 </font></div>
+>
+> 1. 修改：修改数据库设计概述、行业规范、数据库命名字母大小写规范的内容描述
+> 2. 新增：新增数据库命名分段命名原则的示例表
+> 3. 去除：去除数据库命名长度受限原则的示例表
+
+
+
+[TOC]
+
+# 数据库设计概述
+
+本设计规范只适用于关系型数据库。
+
+## 数据库选型
+
+#### 推荐选型
+
+* 开源数据库
+
+> PostgreSQL、MySQL
+
+* 商业数据库
+
+> Oracle
+
+* 国产数据库 
+
+> 国家信创产品
+
+#### 不推荐选型
+
+> DB2、Sybase
+
+# 命名规范
+
+## 通用命名规范
+
+##### <font  color= #8470FF>Ø规范</font>：遵循行业规范
+当有相关国家/行业强制性数据结构标准规范存在时，用于存储业务数据的业务表，在表名命名上原则上应该遵从标准规定，其表中相关字段的中文名称（即数据项名称），若标准规范上有规定的应遵循规定。此外，若标准规范上对数据项的类型、长度有规定的，原则上也应当遵循或保证能直接兼容保存和访问。
+
+##### <font  color= #8470FF>Ø规范</font>：字符编码规范
+
+遵循各种数据库推荐的字符编码
+
+| 数据库类型 | 库编码字符集   | 表编码字符集   |
+| ---------- | -------------- | -------------- |
+| Oracle     | simple Chinese | simple Chinese |
+| MySQL      | utf8mb4        | utf8mb4        |
+| PostgreSQL | utf-8          | utf-8          |
+| DB2        | gbk            | gbk            |
+
+##### <font  color= #8470FF>Ø规范</font>：字母大小写规范
+所有数据库对象命名（库、表、字段、视图、索引）字母，遵循各种数据库推荐的大小写规范：
+
+| 数据库类型 | 表名大小写                                               | 字段名大小写                                             | 库名大小写                                    | 视图名大小写                                  | 索引名命名规范                     |
+| ---------- | -------------------------------------------------------- | -------------------------------------------------------- | --------------------------------------------- | --------------------------------------------- | ---------------------------------- |
+| Oracle     | 统一使用大写 | 统一使用大写                  | 统一使用大写 | 统一使用大写 | 统一使用大写 |
+| MySQL      | 统一使用小写 | 统一使用小写 | 统一使用小写 | 统一使用小写 |统一使用小写|
+| PostgreSQL | 统一使用小写           | 统一使用小写                         | 统一使用小写 | 统一使用小写 | 统一使用小写 |
+| DB2        | 统一使用大写 | 统一使用大写 | 统一使用大写 | 统一使用大写 | 统一使用大写 |
+
+##### <font  color= #8470FF>Ø规范</font>：长度受限原则
+
+为保证将来系统跨平台的可移植性，表、视图命名长度不超过30个字符
+
+##### <font  color= #8470FF>Ø规范</font>：字符范围原则
+
+只能使用英文字母、下划线、数字进行命名，首位字符必须是英文字母。
+##### <font  color= #8470FF>Ø规范</font>：分段命名原则
+命名中多个单词间采用下划线分隔，以便阅读同时方便某些工具对数据库对象的映射。如XXX_XXX_XXX，但不限于三段式。
+
+| 数据库类型 | 分段命名原则 | 分段命名示例      |
+| ---------- | ------------ | ----------------- |
+| Oracle     | XXX_XXX_XXX  | FOOD_BR_TASK_LIST |
+| MySQL      | xxx_xxx_xxx  | food_br_task_list |
+| PostgreSQL | xxx_xxx_xxx  | food_br_task_list |
+| DB2        | XXX_XXX_XXX  | FOOD_BR_TASK_LIST |
+
+##### <font  color= #8470FF>Ø规范</font>：勿用保留词
+数据库对象命名，不能直接使用数据库保留关键字，以及Java、JavaScript等常用语言的保留关键字
+
+##### <font  color= #3CB371>Ø建议</font>：同义性原则
+对于同一含义尽量使用相同的单词命名，避免同一单词表示多种含义的情况，以免引起误解
+##### <font  color= #3CB371>Ø建议</font>：命名方式一致原则
+在一个系统、一个项目中尽量采用一致的命名方式，各表之间相同含义的字段，类型定义要完全相同（包括精度、默认值等）；
+##### <font  color= #3CB371>Ø建议</font>：扩展性原则
+各系统或者项目在遵循本规范的基础上，可以根据需要制定更明确的规范细则，以满足项目管理需要。如对模块进行统一命名，然后用于表名的前缀
+
+## 库命名规范
+
+##### <font  color= #8470FF>Ø规范</font>：数据库名称长度
+不超过8个字符
+
+##### <font  color= #3CB371>Ø建议</font>： 库命名
+尽量与项目名称一致
+
+## 表命名规范
+
+##### <font  color= #8470FF>Ø规范</font>: 长度规约
+
+表名长度不能超过30，一般不超过五个英文单词，不推荐中文拼音（特定行业规范与约定表述除外）
+
+##### <font  color= #8470FF>Ø规范</font>: 分段命名规约（待进一步商议）
+
+例如：SYS_MOUDLE_ENTITY
+
+SYS 表示所属的系统，一个简写单词（2-5个字符）
+
+MOUDLE 表示数据库对象模块名或者主题分类，一个简写单词（2-5个字符）
+
+ENTITY 表示业务实体名称，可以根据需要有多个单词组成（1-3个单词，用下划线连接）
+
+##### <font  color= #8470FF>Ø规范</font>: 命名前缀规范（待进一步商议）
+
+> 系统参数表	SYS_
+
+> 用户、权限表	U_
+
+> 系统日志表  LOG_
+
+> 代码表
+
+> 字典表	DT_
+
+> 临时表   TMP_
+
+
+
+## 字段命名规范
+
+##### <font  color= #8470FF>Ø规范</font>：长度规范
+
+字段长度不能超过20
+
+##### <font  color= #8470FF>Ø规范</font>：前缀规范
+
+列名无需使用前缀
+
+##### <font  color= #8470FF>Ø规范</font>：多段式命名（待议）
+
+列名采用多段式命名时，各单词间用下划线分隔
+
+##### <font  color= #3CB371>Ø建议</font>：特定类型字段命名
+
+日期类型字段：推荐以 DATE 结尾的名字命名
+
+时间类型字段：推荐以 TIME 结尾的名字命名
+
+##### <font  color= #3CB371>Ø建议</font>：主键列命名
+
+为 ID 或者以  ID 为后缀进行命名，对于需要在其它表中引用的主键字段以“_ID”后缀方式命名
+
+## 视图命名规范
+
+##### <font  color= #8470FF>Ø规范</font>：前缀规范
+
+视图的命名以V_开头
+##### <font  color= #8470FF>Ø规范</font>：视图其它命名规范
+
+参考表的命名规范
+
+##### <font  color= #3CB371>Ø建议</font>：视图的列名
+
+一般与基表一致，但是根据需要可以与基表的列名不同。
+
+
+
+# 基本设计规范
+
+## 字段设计规范
+
+##### <font  color= #8470FF>Ø规范</font>：主键
+
+主键为带横杆的UUID，主键不表示任何业务含义
+
+##### <font  color= #8470FF>Ø规范</font>：公共字段
+
+ID 编号 VARCHAT(36)
+
+Create_Time 创建时间 TIMESTAMP --默认为系统当前时间
+
+Update_Time 修改时间 TIMESTAMP --默认为系统当前时间
+
+交给持久化框架完成更新，SQL不需要特别编写
+
+##### <font  color= #8470FF>Ø规范</font>：时间类型
+
+一般时间精度使用DATE，保存到秒，例如“2010-11-22 11:22:36”
+
+高精度使用TIMESTAMP，保存小数秒，例如“2010-11-22 11:22:36.000000”
+
+特别说明：PostgreSQL数据库的DATE类型只精确到日期，无法保存时分秒，建议使用TIMESTAMP
+
+##### <font  color= #8470FF>Ø规范</font>：数字、小数类型
+
+不得使用VACHAR等字符串类型来保存，应该使用相应精度的数字、小数类型，确保定义时有默认值
+
+##### <font  color= #8470FF>Ø规范</font>：财务金额类型
+
+财务相关的金额类，必须使用decimal类型，确保定义时有默认值
+
+##### <font  color= #8470FF>Ø规范</font>：大对象字段
+
+ORACLE: 禁止使用CLOB类型保存大文本、图片和文件
+
+MySQL：尽量不要使用TEXT数据类型，varchar类型支持65535字节，满足大多数场景
+
+禁止数据库中存储图片、二进制数据，使用其他方式存储（例如文件系统，数据库只保存其地址信息）
+
+##### <font  color= #8470FF>Ø规范</font>：表示状态的字段（码值）
+
+表示简单状态的字段，字段not null，根据业务要求来设置默认值（例如默认为0）
+
+对于Boolean类型，以1代表是（true）， 0 代表否（false）
+
+
+## 公共规范
+##### <font  color= #8470FF>Ø规范</font>：冗余字段
+
+ 反范式化冗余字段使用规范，考虑具体使用场景，当SQL关连查询比较频繁，或涉及到4张以上表时可考虑采用冗余字段
+
+##### <font  color= #8470FF>Ø规范</font>：注释
+
+所有表和字段都需要添加注释
+
+表示状态的字段，注释中应该注明每一种状态的含义，例如“0：编辑中，1：审核中，2：已完成”
+
+##### <font  color= #8470FF>Ø规范</font>：默认值设置
+
+冗余字段尽可能把所有列定义为NOT NULL，定义时设置默认值
+
+##### <font  color= #8470FF>Ø规范</font>：字段数限制
+
+表的字段数不超过50个
+
+##### <font  color= #3CB371>Ø建议</font>：逻辑删除标识设计
+
+表中应有数据对应逻辑删除标识，用逻辑删除代替物理删除，标识数据是否已删除
+
+##### <font  color= #3CB371>Ø建议</font>：关联字段索引设计原则
+
+对于数据量大的情况下，建议将数据库字段中相关联字段进行索引添加，以提高相关关联查询效率
+
+##### <font  color= #3CB371>Ø建议</font>：复合主键设计原则
+
+对于部分简单的中间关联表，可设置表关联的复合主键，提高储存和索引效率，不建议使用业务相关字段作为复合主键
+
+##### <font  color= #3CB371>Ø建议</font>：分区或分表设计原则
+
+当数据量太大导致影响到查询速度或操作速度的时候，可根据实际情况进行分区或分表进行数据储存
+
+##### <font  color= #3CB371>Ø建议</font>：冷热数据分离
+
+尽量做到冷热数据分离，减小表的宽度
+
+
+
+# 管理规范
+
+##### DDL管理
+
+代码表的方式，PDM的方式
+
+##### 权限管理
+
+分离运维账号、开发账号、系统运行账号
+
+##### 数据字典管理
+
+启动开发时建立数据字典，管理命名中使用的英文单词、英文单词缩写、拼音首字母缩写等，对用于命名的单词进行统一管理
+
+##### 规范管理
+
+DDL定义必须符合本设计规范，通过脚本校验工具（规避关键字、强制规范的校验）
+
+# 基本理论基础
+
+> 数据设计的三个范式 3NF 
+>
+> 1. 表内的每一个记录都只能被表达一次；
+> 2. 表内的每一个记录都应该被唯一的标识（有唯一键）；
+> 3. 表内不应该存储依赖于其他键的非键信息。

新兵作战指南（数据库篇）.md

@@ -1 +0,0 @@
-新兵作战指南（前端篇）.md