① 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) ,並單擊工具欄中的"啟動服務"按鈕把服務狀態改為啟動;