① sql的四个组成部分，到底是怎么分的
(1)数据定义语言，即SQL DDL，用于定义SQL模式、基本表、视图、索引等结构。
(2)数据操纵语言，即SQL DML。数据操纵分成数据查询和数据更新两类。
(3)数据查询语言，即SQL DQL。
(4)数据控制语言，即SQL DCL，这一部分包括对基本表和视图的授权、完整性规则的描述、事务控制等内容。
结构化查询语言是高级的非过程化编程语言，允许用户在高层数据结构上工作。它不要求用户指定对数据的存放方法，也不需要用户了解具体的数据存放方式，所以具有完全不同底层结构的不同数据库系统, 可以使用相同的结构化查询语言作为数据输入与管理的接口。结构化查询语言语句可以嵌套，这使它具有极大的灵活性和强大的功能。
(1)SQL应用重构扩展阅读：
SQL可以独立完成数据库生命周期中的全部活动，包括定义关系模式、录入数据、建立数据库、査询、更新、维护、数据库重构、数据库安全性控制等一系列操作，这就为数据库应用系统开发提供了良好的环境，在数据库投入运行后，还可根据需要随时逐步修改模式，且不影响数据库的运行，从而使系统具有良好的可扩充性。
② SQL语言应用
1，为仓库表增加“面积”字段，类型是int型，必须大于等于100
2.为供应商表插入一条信息，内容是供应商号＝“S3”，供应商名＝“洪昌公司”，地址＝“北京”
3.在供应商表中查询符合条件为地址是北京，供应商号为（查询订购单表，返回职工号为E1的所有供应商号）
4.语句才一半，显示：仓库表的仓库号，仓库表的城市，职工表中职工数量并且重命名为职工人数
③ 慢sql治理经典案例分享
作者 | 如期
来源 | 阿里技术公众号
菜鸟供应链金融慢sql治理已经有一段时间，自己负责的应用持续很长时间没有慢sql告警，现阶段在推进组内其他成员治理应用慢sql。这里把治理过程中的一些实践拿出来分享下。
在分页查询治理的文章里已经介绍过我们系统旧的分页查询逻辑，上面的查询sql明显就是分页查询获取总记录数，通过XXX_rules表的分页查询接口溯源，找到发起调用的页面是我们小二后台的一个操作商家准入的页面，页面打开后直接调用分页查询接口，除了分页参数，不传入其他任何查询参数，导致扫描全表。
灵魂拷问：为什么要扫描全表？全表数据展示到页面，花里胡哨的数据有用吗？
调研：和经常使用这个页面的运营聊后了解到，打开页面查询出的全表数据对运营是没有用的，他们根本不看这些数据。运营的操作习惯是拿到商家id，在页面查询框中输入商家id，查到商家数据后进行操作。
由此优化方案就很明朗了：打开页面时不直接查询全量数据，等运营输入商家id后，将商家id作为参数进行查询。XXX_rules表中，商家id这一常用查询条件设置为索引，再结合分页查询优化，全表扫描慢sql得以解决。
优化后的小二后台页面如下：
打开页面时未查询任何数据，查询条件商家账户为必填项。
优化后的sql为:
执行EXPLAIN得到结果如下：
可以看到命中了索引，扫描行数为3，查询速度明显提高。
扫描全表治理简单来说就是加入查询条件，命中索引，去除全表扫描查询，虽然有些粗暴，但并不是没有道理。实际业务场景中，很少有要扫描全表获取全部数据的情况，限制调用上游必须传入查询条件，且该查询条件能命中索引，能很大程度上避免慢sql。
另外，再引申下，XXX_rules初始的用意是准入表，记录金融货主维度的准入情况，最多也就几千条数据，但是很多同事将这张表理解为规则表，写入很多业务相关规则，导致这个表膨胀到一百多万条数据，表不clean了。这就涉及到数据表的设计使用，明确表的使用规范，不乱写入数据，能给后期维护带来很大的便利。
除了时间、操作人字段，XXX_rules表就rule_name、rule_value、status、proct_code四个字段，表的索引对这四个字段做各种排列组合。存在如下问题：
1、rule_name离散度不高，放在索引首位不合适；
2、前三个索引重合度很高；
显然是对索引的命中规则不够了解。XXX_rules表很多业务有定时任务对其写入删除，索引多、混乱，对性能有很大的影响。
高性能的索引有哪些，再来回顾下：
1、独立的列：索引列不能是表达式的一部分；
2、选择区分度高的列作为索引；
3、选择合适的索引列顺序：将选择性高的索引列放在最前列；
4、覆盖索引：查询的列均在索引中，不需要回查聚簇索引；
5、使用索引扫描来做排序;
6、在遵守最左前缀的原则下，尽量扩展索引，而不是创建索引。
但凡记得第3和6规则，也不至于把索引建成这样。
对索引进行整合如下：
系统中有很多任务拉取整个产品下的准入记录，然后进行处理，所以将区分度较高的proct_code放在索引首位，然后添加rule_name、status字段到索引里，进一步过滤数据，减少扫描行数，避免慢sql。针对常用的rule_value查询条件，可以命中UK，因此不用单独建立索引。
很多业务逻辑中，需要拉取满足某个条件的记录列表，查询的sql语句带有order by，记录比较多的情况，排序代价往往很大，但是查询出来的记录是否有序对业务逻辑没有影响，比如分页治理里讨论的count语句，只需要统计条数，order by对条数没有影响，再比如查出记录列表后，不依赖记录的顺序遍历列表处理数据，这时候order by多此一举。
查询sql无limit语句，且业务处理逻辑不依赖于order by后列表记录的顺序，则去除查询sql中的order by语句。
业务中有很多定时任务，扫描某个表中某个产品下所有数据，对数据进行处理，比如：
三个查询条件都是区分度不高的列，查出的数据有27W条，加索引意义也不大。
实际业务量没那么大，顶多几千条数据，表里的数据是从上游同步过来的，最好的办法是让上游精简数据，但是由于业务太久远，找上游的人维护难度太大，因此只能想其他的办法。
这个定时任务目的是拉出XXX_rules表的某些产品下的数据，和另一张表数据对比，更新有差异的数据。每天凌晨处理，对时效性没有很高的要求，因此，能不能转移任务处理的地方，不在本应用机器上实时处理那么多条数据？
数据是离线任务odps同步过来的，首先想到的就是dataWork数据处理平台。
建立数据对比任务，将定时任务做的数据对比逻辑放到dataWork上用sql实现，每天差异数据最多几百条，且结果集含有区分度很高的列，将差异数据写入odps表，再将数据回流到idb。
新建定时任务，通过回流回来的差异数据中区分度高的列作为查询条件查询XXX_rules，更新XXX_rules，解决了慢sql问题。
这个方法的前提是对数据实效性要求不高，且离线产出的结果集很小。
explain上述查询语句，得到结果如下：
XXX_white_list表有将biz_id作为索引，这里查询XXX_white_list表有传入biz_id作为查询条件，为啥explain结果里type为ALL，即扫描全表？索引失效了？索引失效有哪些情况？
索引失效场景
1、OR查询左右有未命中索引的；
2、复合索引不满足最左匹配原则；
3、Like以%开头；
4、需要类型转换；
5、where中索引列有运算；
6、where中索引列使用了函数；
7、如果mysql觉得全表扫描更快时（数据少时）
上述查询语句第8行，customer_id为XXX_level_report表字段，未命中XXX_white_list表索引，导致索引失效。
这个语句用condition、枚举、join花里胡哨的代码拼接起来的，改起来好麻烦，而且看起来“OR customer_id LIKE CONCAT(t.biz_id, '@%')”这句不能直接删掉。最后重构了该部分的查询语句，去除or查询，解决了慢sql。
④ sql具有数据哪几个四种主要功能
sql具有数据的定义、查询、更新 、控制四种主要功能。
sql是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系数据库系统；同时也是数据库脚本文件的扩展名。
结构化查询语言是高级的非过程化编程语言，允许用户在高层数据结构上工作。它不要求用户指定对数据的存放方法，也不需要用户了解具体的数据存放方式。
所以具有完全不同底层结构的不同数据库系统, 可以使用相同的结构化查询语言作为数据输入与管理的接口。结构化查询语言语句可以嵌套，这使它具有极大的灵活性和强大的功能。
(4)SQL应用重构扩展阅读：
语言特点
1、一体化：SQL集数据定义DDL、数据操纵DML和数据控制DCL于一体，可以完成数据库中的全部工作。
2、使用方式灵活：它具有两种使用方式，即可以直接以命令方式交互使用；也可以嵌入使用，嵌入到C、C++、FORTRAN、COBOL、JAVA等主语言中使用。
3、非过程化：只提操作要求，不必描述操作步骤，也不需要导航。使用时只需要告诉计算机“做什么”，而不需要告诉它“怎么做”。
4、语言简洁，语法简单，好学好用：在ANSI标准中，只包含了94个英文单词，核心功能只用6个动词，语法接近英语口语。
应用
结构化查询语言SQL（STRUCTURED QUERY LANGUAGE）是最重要的关系数据库操作语言，并且它的影响已经超出数据库领域，得到其他领域的重视和采用，如人工智能领域的数据检索，第四代软件开发工具中嵌入SQL的语言等。
⑤ SQL数据库的应用领域、现状、发展前景
SQL数据库是具有数据操纵和数据定义等多种功能的数据库语言，这种语言具有交互性特点，能为用户提供极大的便利，数据库管理系统应充分利用SQL语言提高计算机应用系统的工作质量与效率。
一、SQL数据库的应用领域
1、多媒体数据库
这种数据库主要存储与多媒体有关的数据，如语音、图像和视频数据。多媒体数据最大的特点是数据连续、数据量大、存储空间大。
2、移动数据库
这种数据库是在笔记本电脑、掌上电脑等移动计算机系统上开发的。数据库的最大特点是通过无线数字通信网络传输。移动数据库可以随时随地获取和访问数据，为一些业务应用和一些突发事件带来了极大的便利。
3、空间数据库
目前，这种数据库发展迅速。它主要包括地理信息数据库（也称为GIS）和计算机辅助设计（CAD）数据库。其中，地理信息数据库一般存储与地图相关的信息数据；CAD数据库一般存储机械、集成电路、电子设备设计图纸等设计信息的空间数据库。
4、信息检索系统
信息检索是根据用户输入的信息从数据库中查找相关文档或信息，并将信息反馈给用户。信息检索领域与数据库领域同步发展。它是一个典型的联机文档管理系统或联机图书目录。
5、分布式信息检索
这种数据库是随着Internet的发展而产生的。它广泛应用于Internet和远程计算机网络系统中。特别是随着电子商务的发展，这种数据库的发展更为迅速。许多网络用户（如个人、公司或企业等）将信息存储在自己的计算机中。
6、专家决策系统
专家决策系统也是数据库应用的一部分。因为越来越多的数据可以在网上获得，特别是通过这些数据，企业可以对企业的发展做出更好的决策，从而使企业能够更好地经营。随着人工智能的发展，专家决策系统的应用越来越广泛。
二、SQL数据库现状
1、自主研发
国内自主研发关系型数据库的企业、单位基本上都是发源于上世纪90年代的，而且都是以大学、科研机构为主。到今天，有代表性的厂商有：达梦–由华中理工冯玉才教授创办，完全自主研发。以Oracle为参照、追赶对象。
2、引进源代码
引进数据库源代码发展国产数据库，如今，经济发展，而且IBM也愿意迎合国人对于国产化的诉求，将搁置多年的Informix源代码拿出来，发挥余热。2015年以来，与IBM签订源代码授权的公司有华胜天成、南大通用（Gbase8t）和星瑞格。这三个公司成为以引进Informix源代码发展国产数据库的代表。
三、SQL数据库发展前景
1、产品形成系列化
一方面，Web和数据仓库等应用的兴起，数据的绝对量在以惊人的速度迅速膨胀；另一方面，移动和嵌入式应用快速增长。针对市场的不同需求，数据库正在朝系列化方向发展。
2、智能化集成化
SQL数据库技术的广泛使用为企业和组织收集并积累了大量的数据。数据丰富知识贫乏的现实直接导致了联机分析处理（OLAP）和数据挖掘（DataMining）等技术的出现，促使数据库向智能化方向发展。
3、支持各种互联网应用
SQL数据库管理系统是网络经济的重要基础设施之一。支持Internet（甚至于MobileInternet）数据库应用已经成为数据库系统的重要方面。例如，Oracle公司从8版起全面支持互联网应用，是互联网数据库的代表。
(5)SQL应用重构扩展阅读：
SQL包括了所有对数据库的操作，主要是由4个部分组成：
1、数据定义：又称为“DDL语言”，定义数据库的逻辑结构，包括定义数据库、基本表、视图和索引4部分。
2、数据操纵：又称为“DML语言”，包括插入、删除和更新三种操作。
3、数据查询：又称为“DQL语言”，包括数据查询操作。
4、数据控制：又称为“DCL语言”，对用户访问数据的控制有基本表和视图的授权及回收。
5、事务控制：又称为“TCL语言”，包括事务的提交与回滚。
参考资料来源：网络-SQL数据库
⑥ MySQL SQL的基础应用
SQL 基础应用及information_schema
1.SQL（结构化查询语句）介绍
SQL标准：SQL 92 SQL99
5.7版本后启用SQL_Mode 严格模式
2.SQL作用
SQL 用来管理和操作MySQL内部的对象
SQL对象：
库：库名，库属性
表：表名，表属性，列名，记录，数据类型，列属性和约束
3.SQL语句的类型
DDL：数据定义语言 data definition language
DCL：数据控制语言 data control language
DML：数据操作语言 data manipulation language
DQL：数据查询语言 data query language
4.数据类型
4.1 作用：
控制数据的规范性，让数据有具体含义，在列上进行控制
4.2.种类
4.2.1 字符串
char(32)
定长长度为32的字符串。存储数据时，一次性提供32字符长度的存储空间，存不满，用空格填充。
varchar(32)：
可变长度的字符串类型。存数据时，首先进行字符串长度判断，按需分配存储空间
会单独占用一个字节来记录此次的字符长度
超过255之后，需要两个字节长度记录字符长度。
面试题：
1. char 和varchar的区别？
（1） 255 65535
（2） 定长（固定存储空间） 变长（按需）
2. char和varchar 如何选择？
（1） char类型，固定长度的字符串行，比如手机号，身份证号，银行卡号，性别等
（2） varchar类型，不确定长度的字符串，可以使用。
3. enum 枚举类型
enum('bj','sh','sz','cq','hb',......)
数据行较多时，会影响到索引的应用
注意：数字类禁止使用enum类型
4.2.2 数字
1. tinyint
2. int
4.2.3 时间
1. timestamp
2. datetime
4.2.4 二进制
5. 表属性
存储引擎 ：engine = InnoDB
字符集 ：charset = utf8mb4
utf8 中文 三个字节长度
utf8mb4 中文 四个字节长度 才是真正的utf8
支持emoji字符
排序规则（校对规则） collation
针对英文字符串大小写问题
6. 列的属性和约束
6.1 主键： primary key (PK)
说明：
唯一
非空
数字列，整数列，无关列，自增的.
聚集索引列？
是一种约束，也是一种索引类型，在一张表中只能有一个主键。
6.2 非空： Not NULL
说明：
我们建议，对于普通列来讲，尽量设置not null
默认值 default ： 数字列的默认值使用0 ,字符串类型，设置为一个nil null
6.3 唯一：unique
不能重复
6.4 自增 auto_increment
针对数字列，自动生成顺序值
6.5 无符号 unsigned
针对数字列
6.6 注释 comment
7. SQL语句应用
7.1 DDL：数据定义语言
7.1.1 库
（1）建库
mysql> create database oldguo charset utf8mb4;
mysql> show databases;
mysql> show create database oldguo;
（2）改库
mysql> alter database oldguo1 charset utf8mb4;
（3）删库
mysql> drop database oldguo1;
7.1.2 表
（0）建表建库规范：
1、库名和表名是小写字母
为啥？
开发和生产平台可能会出现问题。
2、不能以数字开头
3、不支持- 支持_
4、内部函数名不能使用
5、名字和业务功能有关（his,jf,yz,oss,erp,crm...）
（1）建表
create table oldguo (
ID int not null primary key AUTO_INCREMENT comment '学号',
name varchar(255) not null comment '姓名',
age tinyint unsigned not null default 0 comment '年龄',
gender enum('m','f','n') NOT null default 'n' comment '性别'
)charset=utf8mb4 engine=innodb;
（2）改表
1. 改表结构
-- 例子：
-- 在上表中添加一个手机号列15801332370.（重点*****）
-- alter table oldguo add telnum char(11) not null unique comment '手机号';
-- 练习：
-- 添加一个状态列
ALTER TABLE oldguo ADD state TINYINT UNSIGNED NOT NULL DEFAULT 1 COMMENT '状态列';
-- 查看列的信息
DESC oldguo;
-- 删除state列(不代表生产操作)
ALTER TABLE oldguo DROP state;
-- online-DDL : pt-osc (自己研究下***)
-- 在name后添加 qq 列 varchar(255)
ALTER TABLE oldguo ADD qq VARCHAR(255) NOT NULL UNIQUE COMMENT 'qq' AFTER NAME;
-- 练习 在name 之前添加wechat列
ALTER TABLE oldguo ADD wechat VARCHAR(255) NOT NULL UNIQUE COMMENT '微信' AFTER ID;
-- 在首列上添加 学号列：sid(linux58_00001)
ALTER TABLE oldguo ADD sid VARCHAR(255) NOT NULL UNIQUE COMMENT '学生号' FIRST;
-- 修改name数据类型的属性
ALTER TABLE oldguo MODIFY NAME VARCHAR(128) NOT NULL ;
DESC oldguo;
-- 将gender 改为 gg 数据类型改为 CHAR 类型
ALTER TABLE oldguo CHANGE gender gg CHAR(1) NOT NULL DEFAULT 'n' ;
DESC oldguo;
7.2 DML 数据操作语言
7.2.1 INSERT
--- 最简单的方法插入数据
DESC oldguo;
INSERT INTO oldguo VALUES(1,'oldguo','22654481',18);
--- 最规范的方法插入数据(重点记忆)
INSERT INTO oldguo(NAME,qq,age) VALUES ('oldboy','74110',49);
--- 查看表数据（不代表生产操作）
SELECT * FROM oldguo;
7.2.2 UPDATE (注意谨慎操作！！！！)
UPDATE oldguo SET qq='123456' WHERE id=5 ;
7.2.3 DELETE (注意谨慎操作！！！！)
DELETE FROM oldguo WHERE id=5;
7.2.4 生产需求：将一个大表全部数据清空
DELETE FROM oldguo;
TRUNCATE TABLE oldguo;
DELETE 和 TRUNCATE 区别
1. DELETE 逻辑逐行删除，不会降低自增长的起始值。
效率很低，碎片较多，会影响到性能
2. TRUNCATE ，属于物理删除，将表段中的区进行清空，不会产生碎片。性能较高。
7.2.5 生产需求：使用update替代delete，进行伪删除
1. 添加状态列state (0代表存在，1代表删除)
ALTER TABLE oldguo ADD state TINYINT NOT NULL DEFAULT 0 ;
2. 使用update模拟delete
DELETE FROM oldguo WHERE id=6;
替换为
UPDATE oldguo SET state=1 WHERE id=6;
SELECT * FROM oldguo ;
3. 业务语句修改
SELECT * FROM oldguo ;
改为
SELECT * FROM oldguo WHERE state=0;
⑦ sql数据库设计
一、数据库设计过程
数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。
数据库设计中需求分析阶段综合各个用户的应用需求（现实世界的需求），在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式（信息世界模型），用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图（VIEW）形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。
1. 需求分析阶段
需求收集和分析，结果得到数据字典描述的数据需求（和数据流图描述的处理需求）。
需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。
需求分析的方法：调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。
常用的调查方法有： 跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法（Structured Analysis，简称SA方法）从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。
数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典（Data Dictionary，简称DD）来描述。
数据字典是各类数据描述的集合，它是关于数据库中数据的描述，即元数据，而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键)。
数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度，
取值范围，取值含义，与其他数据项的逻辑关系｝
数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝
数据流描述＝｛数据流名，说明，数据流来源，数据流去向，
组成:｛数据结构｝，平均流量，高峰期流量｝
数据存储描述＝｛数据存储名，说明，编号，流入的数据流，流出的数据流，
组成:｛数据结构｝，数据量，存取方式｝
处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝,
处理:｛简要说明｝｝
2. 概念结构设计阶段
通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。
概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。
概念模型特点：
(1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。
(2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。
概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术，用于建立系统信息模型。
使用IDEF1X方法创建E-R模型的步骤如下所示:
2.1 第零步——初始化工程
这个阶段的任务是从目的描述和范围描述开始，确定建模目标，开发建模计划，组织建模队伍，收集源材料，制定约束和规范。收集源材料是这阶段的重点。通过调查和观察结果，业务流程，原有系统的输入输出，各种报表，收集原始数据，形成了基本数据资料表。
2.2 第一步——定义实体
实体集成员都有一个共同的特征和属性集，可以从收集的源材料——基本数据资料表中直接或间接标识出大部分实体。根据源材料名字表中表示物的术语以及具有“代码”结尾的术语，如客户代码、代理商代码、产品代码等将其名词部分代表的实体标识出来，从而初步找出潜在的实体，形成初步实体表。
2.3 第二步——定义联系
IDEF1X模型中只允许二元联系，n元联系必须定义为n个二元联系。根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系（强制的或可选的）还是非确定关系、分类关系。如果子实体的每个实例都需要通过和父实体的关系来标识，则为标识关系，否则为非标识关系。非标识关系中，如果每个子实体的实例都与而且只与一个父实体关联，则为强制的，否则为非强制的。如果父实体与子实体代表的是同一现实对象，那么它们为分类关系。
2.4 第三步——定义码
通过引入交叉实体除去上一阶段产生的非确定关系，然后从非交叉实体和独立实体开始标识侯选码属性，以便唯一识别每个实体的实例，再从侯选码中确定主码。为了确定主码和关系的有效性，通过非空规则和非多值规则来保证，即一个实体实例的一个属性不能是空值，也不能在同一个时刻有一个以上的值。找出误认的确定关系，将实体进一步分解，最后构造出IDEF1X模型的键基视图（KB图）。
2.5 第四步——定义属性
从源数据表中抽取说明性的名词开发出属性表，确定属性的所有者。定义非主码属性，检查属性的非空及非多值规则。此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主码属性必须依赖于主码、整个主码、仅仅是主码。以此得到了至少符合关系理论第三范式的改进的IDEF1X模型的全属性视图。
2.6 第五步——定义其他对象和规则
定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。定义触发器、存储过程、视图、角色、同义词、序列等对象信息。
3. 逻辑结构设计阶段
将概念结构转换为某个DBMS所支持的数据模型（例如关系模型），并对其进行优化。设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS。
将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式,这种转换一般遵循如下原则：
1）一个实体型转换为一个关系模式。实体的属性就是关系的属性。实体的码就是关系的码。
2）一个m:n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。
3）一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
4）一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
5）三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。
6）同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。
7）具有相同码的关系模式可合并。
为了进一步提高数据库应用系统的性能，通常以规范化理论为指导，还应该适当地修改、调整数据模型的结构，这就是数据模型的优化。确定数据依赖。消除冗余的联系。确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分解。一般来说将关系分解为3NF的标准，即：
表内的每一个值都只能被表达一次。
•?表内的每一行都应该被唯一的标识（有唯一键）。
表内不应该存储依赖于其他键的非键信息。
4. 数据库物理设计阶段
为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。
5. 数据库实施阶段
运用DBMS提供的数据语言（例如SQL）及其宿主语言（例如C），根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。 数据库实施主要包括以下工作：用DDL定义数据库结构、组织数据入库 、编制与调试应用程序、数据库试运行
6. 数据库运行和维护阶段
数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。包括：数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。
建模工具的使用
为加快数据库设计速度，目前有很多数据库辅助工具（CASE工具），如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的Oracle Designer等。
ERwin主要用来建立数据库的概念模型和物理模型。它能用图形化的方式，描述出实体、联系及实体的属性。ERwin支持IDEF1X方法。通过使用ERwin建模工具自动生成、更改和分析IDEF1X模型，不仅能得到优秀的业务功能和数据需求模型，而且可以实现从IDEF1X模型到数据库物理设计的转变。ERwin工具绘制的模型对应于逻辑模型和物理模型两种。在逻辑模型中，IDEF1X工具箱可以方便地用图形化的方式构建和绘制实体联系及实体的属性。在物理模型中，ERwin可以定义对应的表、列，并可针对各种数据库管理系统自动转换为适当的类型。
设计人员可根据需要选用相应的数据库设计建模工具。例如需求分析完成之后，设计人员可以使用Erwin画ER图，将ER图转换为关系数据模型，生成数据库结构；画数据流图，生成应用程序。
二、数据库设计技巧
1. 设计数据库之前（需求分析阶段）
1) 理解客户需求，询问用户如何看待未来需求变化。让客户解释其需求，而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中。
2) 了解企业业务可以在以后的开发阶段节约大量的时间。
3) 重视输入输出。
在定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。
举例：假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。
4) 创建数据字典和ER 图表
ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。
5) 定义标准的对象命名规范
数据库各种对象的命名必须规范。
2. 表和字段的设计（数据库逻辑设计）
表设计原则
1) 标准化和规范化
数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF 标准的数据库的表设计原则是：“One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。
举例：某个存放客户及其有关定单的3NF 数据库就可能有两个表：Customer 和Order。Order 表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向Customer 表里包含该客户信息的那一行。
事实上，为了效率的缘故，对表不进行标准化有时也是必要的。
2) 数据驱动
采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。
举例，假如用户界面要访问外部数据源（文件、XML 文档、其他数据库等），不妨把相应的连接和路径信息存储在用户界面支持表里。还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状态等），那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。
3) 考虑各种变化
在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。
举例，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存储客户信息时，在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。
字段设计原则
4) 每个表中都应该添加的3 个有用的字段
•?dRecordCreationDate，在VB 下默认是Now()，而在SQL Server 下默认为GETDATE()
•?sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT USER
•?nRecordVersion，记录的版本标记；有助于准确说明记录中出现null 数据或者丢失数据的原因
5) 对地址和电话采用多个字段
描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。
6) 使用角色实体定义属于某类别的列
在需要对属于特定类别或者具有特定角色的事物做定义时，可以用角色实体来创建特定的时间关联关系，从而可以实现自我文档化。
举例：用PERSON 实体和PERSON_TYPE 实体来描述人员。比方说，当John Smith, Engineer 提升为John Smith, Director 乃至最后爬到John Smith, cio 的高位，而所有你要做的不过是改变两个表PERSON 和PERSON_TYPE 之间关系的键值，同时增加一个日期/时间字段来知道变化是何时发生的。这样，你的PERSON_TYPE 表就包含了所有PERSON 的可能类型，比如Associate、Engineer、Director、CIO 或者CEO 等。还有个替代办法就是改变PERSON 记录来反映新头衔的变化，不过这样一来在时间上无法跟踪个人所处位置的具体时间。
7) 选择数字类型和文本类型尽量充足
在SQL 中使用smallint 和tinyint 类型要特别小心。比如，假如想看看月销售总额，总额字段类型是smallint，那么，如果总额超过了$32,767 就不能进行计算操作了。
而ID 类型的文本字段，比如客户ID 或定单号等等都应该设置得比一般想象更大。假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。
8) 增加删除标记字段
在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行；最好采用清除数据程序而且要仔细维护索引整体性。
3. 选择键和索引（数据库逻辑设计）
键选择原则：
1) 键设计4 原则
•?为关联字段创建外键。
•?所有的键都必须唯一。
•?避免使用复合键。
•?外键总是关联唯一的键字段。
2) 使用系统生成的主键
设计数据库的时候采用系统生成的键作为主键，那么实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点：当拥有一致的键结构时，找到逻辑缺陷很容易。
3) 不要用用户的键(不让主键具有可更新性)
在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。
4) 可选键有时可做主键
把可选键进一步用做主键，可以拥有建立强大索引的能力。
索引使用原则：
索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。
1) 逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列采用非成组索引。考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。
2) 大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。
3) 不要索引memo/note 字段，不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。
4) 不要索引常用的小型表
不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。
4. 数据完整性设计（数据库逻辑设计）
1) 完整性实现机制：
实体完整性：主键
参照完整性：
父表中删除数据：级联删除；受限删除；置空值
父表中插入数据：受限插入；递归插入
父表中更新数据：级联更新；受限更新；置空值
DBMS对参照完整性可以有两种方法实现：外键实现机制（约束规则）和触发器实现机制
用户定义完整性：
NOT NULL；CHECK；触发器
2) 用约束而非商务规则强制数据完整性
采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。
3) 强制指示完整性
在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。
4) 使用查找控制数据完整性
控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。
5) 采用视图
为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。
5. 其他设计技巧
1) 避免使用触发器
触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。
2) 使用常用英语（或者其他任何语言）而不要使用编码
在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码，可以在编码旁附上用户知道的英语。
3) 保存常用信息
让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复（对Access）、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。
4) 包含版本机制
在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。
5) 编制文档
对所有的快捷方式、命名规范、限制和函数都要编制文档。
采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。
对数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当过了一年多时间后再回过头来做第2 个版本，犯错的机会将大大减少。
6) 测试、测试、反复测试
建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。
7) 检查设计
在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。
三、数据库命名规范
1. 实体（表）的命名
1) 表以名词或名词短语命名，确定表名是采用复数还是单数形式，此外给表的别名定义简单规则（比方说，如果表名是一个单词，别名就取单词的前4 个字母；如果表名是两个单词，就各取两个单词的前两个字母组成4 个字母长的别名；如果表的名字由3 个单词组成，从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成4 字母长的别名，其余依次类推）
对工作用表来说，表名可以加上前缀WORK_ 后面附上采用该表的应用程序的名字。在命名过程当中，根据语义拼凑缩写即可。注意，由于ORCLE会将字段名称统一成大写或者小写中的一种，所以要求加上下划线。
举例：
定义的缩写 Sales: Sal 销售；
Order: Ord 订单；
Detail: Dtl 明细；
则销售订单明细表命名为：Sal_Ord_Dtl;
2) 如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用完整的单词。
举例：
定义的缩写 Material Ma 物品；
物品表名为：Material, 而不是 Ma.
但是字段物品编码则是：Ma_ID;而不是Material_ID
3) 所有的存储值列表的表前面加上前缀Z
目的是将这些值列表类排序在数据库最后。
4) 所有的冗余类的命名(主要是累计表)前面加上前缀X
冗余类是为了提高数据库效率，非规范化数据库的时候加入的字段或者表
5) 关联类通过用下划线连接两个基本类之后，再加前缀R的方式命名,后面按照字母顺序罗列两个表名或者表名的缩写。
关联表用于保存多对多关系。
如果被关联的表名大于10个字母，必须将原来的表名的进行缩写。如果没有其他原因，建议都使用缩写。
举例：表Object与自身存在多对多的关系,则保存多对多关系的表命名为：R_Object；
表 Depart和Employee;存在多对多的关系；则关联表命名为R_Dept_Emp
2. 属性（列）的命名
1) 采用有意义的列名，表内的列要针对键采用一整套设计规则。每一个表都将有一个自动ID作为主健,逻辑上的主健作为第一组候选主健来定义,如果是数据库自动生成的编码，统一命名为：ID;如果是自定义的逻辑上的编码则用缩写加“ID”的方法命名。如果键是数字类型，你可以用_NO 作为后缀；如果是字符类型则可以采用_CODE 后缀。对列名应该采用标准的前缀和后缀。
举例：销售订单的编号字段命名：Sal_Ord_ID；如果还存在一个数据库生成的自动编号，则命名为：ID。
2) 所有的属性加上有关类型的后缀，注意，如果还需要其它的后缀，都放在类型后缀之前。
注: 数据类型是文本的字段，类型后缀TX可以不写。有些类型比较明显的字段，可以不写类型后缀。
3) 采用前缀命名
给每个表的列名都采用统一的前缀，那么在编写SQL表达式的时候会得到大大的简化。这样做也确实有缺点，比如破坏了自动表连接工具的作用，后者把公共列名同某些数据库联系起来。
3. 视图的命名
1) 视图以V作为前缀，其他命名规则和表的命名类似；
2) 命名应尽量体现各视图的功能。
4. 触发器的命名
触发器以TR作为前缀，触发器名为相应的表名加上后缀，Insert触发器加'_I'，Delete触发器加'_D'，Update触发器加'_U'，如：TR_Customer_I，TR_Customer_D，TR_Customer_U。
5. 存储过程名
存储过程应以'UP_'开头，和系统的存储过程区分，后续部分主要以动宾形式构成，并用下划线分割各个组成部分。如增加代理商的帐户的存储过程为'UP_Ins_Agent_Account'。
6. 变量名
变量名采用小写，若属于词组形式，用下划线分隔每个单词，如@my_err_no。
7. 命名中其他注意事项
1) 以上命名都不得超过30个字符的系统限制。变量名的长度限制为29（不包括标识字符@）。
2) 数据对象、变量的命名都采用英文字符，禁止使用中文命名。绝对不要在对象名的字符之间留空格。
3) 小心保留词，要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突
5) 保持字段名和类型的一致性，在命名字段并为其指定数据类型的时候一定要保证一致性。假如数据类型在一个表里是整数，那在另一个表里可就别变成字符型了。
⑧ SQL有哪些特点
SQL特点：
1、真正的客户机/服务器体系结构。
2、图形化用户界面，使系统管理和数据库管理更加直观、简单。
3、丰富的编程接口工具，为用户进行程序设计提供了更大的选择余地。
4、SQL Server与Windows NT完全集成，利用了NT的许多功能，如发送和接受消息，管理登录安全性等。SQL Server也可以很好地与Microsoft BackOffice产品集成。
5、具有很好的伸缩性，可跨越从运行Windows 95/98的小型电脑到运行Windows 2000的大型多处理器等多种平台使用。
6、对Web技术的支持，使用户能够很容易地将数据库中的数据发布到Web页面上。
7、SQL Server提供数据仓库功能，这个功能只在Oracle和其他更昂贵的DBMS中才有。
(8)SQL应用重构扩展阅读：
SQL可以独立完成数据库生命周期中的全部活动，包括定义关系模式、录入数据、建立数据库、査询、更新、维护、数据库重构、数据库安全性控制等一系列操作。
这就为数据库应用系统开发提供了良好的环境，在数据库投入运行后，还可根据需要随时逐步修改模式，且不影响数据库的运行，从而使系统具有良好的可扩充性。
作为嵌入式语言，SQL语句能够嵌入到高级语言程序中，供程序员设计程序时使用。而在两种不同的使用方式下，SQL的语法结构基本上是一致的。这种以统一的语法结构提供两种不同的操作方式，为用户提供了极大的灵活性与方便性。
⑨ NewSQL分布式数据库发展策略讨论
作者 石默研
本文对新一代NewSQL分布式数据库发展策略中的普遍困扰进行讨论，包括云原生（Cloud Native）与本地部署(On Premise)、HTAP进展方向、分布式与单机需求等分布式数据库商业与技术发展中难以决策的问题。
1. 困扰
分布式NewSQL数据库近年来蓬勃兴起，其原因显而易见：切中了业务与数据量不断增长的用户对关系型数据库RDBMS需求，这在传统RDBMS到大数据的发展阶段中，有相当一段时间是空白。同时，随着互联网技术的不断发展与普及，用云计算模式满足IT需求似乎已经成为未来 社会 产业互联网发展的明确趋势，也就是说，有一种共识：不久的将来，绝大多数产业的IT服务是从公共的、行业的或者私有的、混合的云计算中心提供的。这一共识又带来了云原生（Cloud Native）概念与技术的兴起，而分布式NewSQL数据库自然也应该是云原生的，这决定了其相当多的产品设计决策应以符合这一趋势为原则。然而，在当今的现实中，满足业务与数据量不断增长的RDBMS需求的用户，与云原生的用户，除了互联网企业外，大多数情况下，并不重合，需要On-Premise部署的用户仍然占有很大比重，这就带来了第一个困扰：云原生（Cloud Native）与本地部署(On Premise)对产品发展要求的矛盾。
另一个困扰，是关于HTAP，即交易与分析混合负载。HTAP是当今非常火的一个概念与技术，在交易库上直接进行分析，而不再是将“数据从交易库搬下来，挪到另一个数据库中去”这样的繁琐过程。可以毫不夸张的说： 历史 上规模性企业IT复杂度的相当一部分，都来自于“搬数据”，这导致了数据采集、实时采集、全增量合并、数据传输、数据加载、数据建模、数据质量、数据标准、企业级元数据管理等繁杂多样的技术环节的产生，导致了企业数据分布、数据流向、数据模型、主数据、基础数据平台、ODS/数据仓库/数据集市、数据治理等复杂的数据架构设计优化领域，导致了由于多系统大规模数据搬迁而带来的如数据交换平台之类的复杂调度工程......。咋眼一看，感觉该企业的数据技术好厉害，相关各领域的技术产品好丰富，技术人员的相关技能也好受欢迎。但如果在交易库就能直接满足分析需求而不影响生产效能的话，这些复杂高级的技术环节不都成了“自己给自己造了一座山，还说自己爬的好辛苦”？然而，现实却是，问题并不这么简单，除了在交易库中进行分析会影响业务效能外，还有很多原因导致这一现象产生：交易库并不需要存储那么长的 历史 数据，而分析往往是需要建立在大量 历史 数据之上的；交易库的模型往往并不适合分析需求，多数情况下需要重要建模，如非常流行且价值不菲的各行业数仓主题模型；用于交易的OLTP数据库与用于分析的OLAP数据库，其技术体系完全不同；以及大型企业已固化的内部业务结构并没有留给交易/分析整合可实施的可行空间......等等。由于， 历史 积累的企业级数据体系相当复杂，HTAP的发明者迄今为止都没有系统表达完全替代数据分析需求、自顶而下重构企业数据体系的架构级策略，而是将产品重点定位在技术优化层面：在交易库上直接完成实时统计分析，满足高并发需求且不影响业务效能；或者是为实时分析统计/查询而建设的数据服务中间平台。然而，即使是暂时没有这种策略性的意向，在面向AP的产品具体研发中，又会发现明确的界限确实不好把握，随着一个个具体功能的不断完善，似乎假以时日，技术上也不是没有完全替代纯OLAP平台的可能性。那么，HTAP究竟如何定位呢？
再者就是规模化的分布式需求，与小规模的单机数据库需求（这里指逻辑上的单机）之间的矛盾：分布式数据库，自然而然是要应对规模化的数据管理需求的，长尾的小规模需求当然不应在产品设计考虑之列，同时，大炮轰苍蝇经常还打不好；然而，分布式NewSQL数据库又应该是云原生的，如果把云原生的业务含义理解为“全自助”，它应该以支持什么样的需求为主呢？现实看来，小规模长尾业务对云原生数据库的需求最起码应该是占据相当大的比重的。显而易见，如果是大规模的数据管理需求，即使是部署在云上，DBPaaS的“全自助”是其核心需求吗？这种规模化的业务，如果是云上的On-Premise又需要做出哪些方面的改变？从互联网与云计算发展的 历史 来看，“云自助”，其最核心的商业动机当然包括给用户侧的运维带来了方便，但更重要的可能是给云服务运营商应对海量长尾客户的安装与运维带来了极大的成本优势。这正如银行的小微及个人消费贷款都要走互联网线上模式，而重客、大客甚至中小企业信贷仍然是以线下为主的策略一样，本质是成本问题，而不是客户方便性问题。于是，矛盾显而易见：分布式是面向规模客户的，起码是中、大型客户，而云原生却有可能、最起码相当一段时间内是要以长尾客户为主要服务对象的。
以上困扰实质上，都涉及到了NewSQL分布式数据库的产品发展策略问题。
2. 讨论
问题是客观而又普遍的，但分析与应对策略往往包含主观因素：人们的一个决定与决策，很多情况下并不由严格推理而来，而是心中已经有一个答案，再来找理由支持它。这里的讨论或许也并不能例外。
首先，来看看Cloud Native与On Premise。云原生本应是数据库即服务，然而目前真正有规模化数据增长需求的NewSQL应用相当多的情况下却是付费On Premise与免费On Premise区别，很多互联网企业的应用也可能只是部署在云基础设施上而已，真正的云原生更多是一些实验性、尝试性的需求。但云原生数据库在公有云、行业云以及大型私有云上已经逐渐在形成一种意识上的共识，其商业前景不可限量。也就是说，未来的数字化转型进程中，产业互联网的数据库部署，会逐渐向云基础设施迁移，长在云上。它可能是公有云，也可能是行业云，也可能是私有云，它们都是被定义为云原生NewSQL数据库的市场范围。当然，肯定还会有相当一部分数据库长在云下，这也不用纠结，将其排除在云原生市场战略目标之外即可，就是说，不需要考虑这部分客户需求对产品规划的影响，因为前一部分的份额已经足够大了。这样看来，以云原生为目标进行产品规划的逻辑没有问题，不过，还是要明确一点：长在云上的数据库是不是一定符合我们对“云原生”的既有理解？这里认为，即使未来，在云上形成了产业互联网数据库市场的主体，需要“全自助”的数据库即服务可能也是以面向长尾客户最为迫切、必不可少并且是核心本质，而对中大型以上的需求，“全自助”的意义相对有限，同时比较而言商业模式的转变或者更关键些。那么，如果是以“长在云上”为市场目标，似乎可以将其定义为“广义的云原生”，同时，只要是“长在云上”，那么“云原生”概念中高弹性、高可用、低成本、快速迭代、存算分离等技术优势也都能方便获得。而对“云原生”策略中“云原生”一词的理解不同，对产品规划决策的影响也应该有所不同：一是目前被认为是On Premise的客户需求，或许也就是未来“云原生”主体市场的需求；二是NewSQL数据库关于云原生服务的产品策划，对用户侧“自助”水平的决策或许可以更灵活实用。高水平自助确实可以减轻客户对IT的依赖程度，但这里认为，云原生与用户自行在云上购买资源进行On-Premise部署相比，最关键的价值在于商业模式的改变，能自助多少，不一定是最重要的，因为成为云服务商后，运营运维的工作只会更多，责任可能会更大，甚至有时连IaaS的运维也需要PaaS服务商兜底。但从一个个客户的本地服务，变成集中化云服务，就已经是本质性的模式转变了。总之，需要就事论事，回到原点，仔细分析后决策，而不是用概念教条的判断，因为概念本身的定义并不见得准确对应实际的业务需求。
再来看看HTAP，对这个问题，正如在其它文章中表达过的一样，本文的观点较为明确。一是随着计算能力与架构的升级，从技术上讲，AP与TP的界限会越来越模糊；另外特别是在云原生的新世界里，数据库的这一特性又犹为重要，因为云原生的重要作用之一就是要让客户尽量摆脱对IT运维的依赖，将越来越多的精力集中到自己的业务发展上来；同时端到端的能力提升对云原生商业模式的贯彻也至关重要（需要仔细分析下目前DBPaaS的技术要求是否完全符合这一原点的、本质性的动力），过去与纯OLAP数据库的优势比较纠结在这里也可以得到正面支持；再者，既然架构上已经走向了AP，就很难做到在产品规划上时刻厘清纯AP与混合负载的需求后，再将前者排除在外。于是，以“混合负载满足部分AP需求”应该是由于投入与阶段性市场策略导致的阶段性产品规划，而长远来讲，以一套技术架构满足大多数需求，应该是云原生NewSQL数据库的追求。
接下来，就是关于规模化分布式与小规模单机需求的矛盾了。现在看来，经过上面的讨论，这一点已经不是什么问题了：因为“长在云上”、从分散服务向集中服务的商业模式转变就是指广义的云原生，而不一定要以小微的、迫切需要全自助的长尾为主流，那么，云原生NewSQL数据库仍然应以规模化分布式为其主体的需求方向，而小规模单机则暂时可以不做为重点来考虑。
最后指出一点，希望也能引发进一步的思考：我们所批判的主机，也声称自己是分布式架构，暂且不论其是否客观，但在现实中主机需要被替代的核心问题并不是有没有分布式，而是：一、扩展不灵活带来成本问题：“我只需要扩展一个节点，你却让我再买一台主机”；二、不自主可控；三、往往是软硬件结合的设计策略，包括内存、网络、存储与IO上的软硬融合设计，而这一点，是否需要云原生数据库从广义的定义出发进行学习参考，也是需要进一步讨论的。
⑩ sql 应用程序无法启动 因为应用程序的并行配制不正确，怎么办啊！用重装吗
(1)开始->程序->Microsoft SQL Server 2005->SQL Server 2005外围应用配置器,在打开的界面单击"服务的连接的外围应用配置器",在打开的界面中找到Database Engine,单击"服务",在右侧查看是否已启动,如果没有启动可单击"启动",并确保"启动类型"为自动,不要为手动,否则下次开机时又要手动启动;
(2)可打开:开始->程序->Microsoft SQL Server 2005->配置工具->SQL Server Configuration Manager,选中SQL Server 2005服务中SQL Server(MSSQLSERVER) ,并单击工具栏中的"启动服务"按钮把服务状态改为启动;