下面以關系資料庫系統Informix為例，介紹改善用戶查詢計劃的方法。
1．合理使用索引
索引是資料庫中重要的數據結構，它的根本目的就是為了提高查詢效率。現在大多數的資料庫產品都採用IBM最先提出的ISAM索引結構。索引的使用要恰到好處，其使用原則如下：
●在經常進行連接，但是沒有指定為外鍵的列上建立索引，而不經常連接的欄位則由優化器自動生成索引。
●在頻繁進行排序或分組（即進行group by或order by操作）的列上建立索引。
●在條件表達式中經常用到的不同值較多的列上建立檢索，在不同值少的列上不要建立索引。比如在雇員表的「性別」列上只有「男」與「女」兩個不同值，因此就無必要建立索引。如果建立索引不但不會提高查詢效率，反而會嚴重降低更新速度。
●如果待排序的列有多個，可以在這些列上建立復合索引（pound index）。
●使用系統工具。如Informix資料庫有一個tbcheck工具，可以在可疑的索引上進行檢查。在一些資料庫伺服器上，索引可能失效或者因為頻繁操作而使得讀取效率降低，如果一個使用索引的查詢不明不白地慢下來，可以試著用tbcheck工具檢查索引的完整性，必要時進行修復。另外，當資料庫表更新大量數據後，刪除並重建索引可以提高查詢速度。
2．避免或簡化排序
應當簡化或避免對大型表進行重復的排序。當能夠利用索引自動以適當的次序產生輸出時，優化器就避免了排序的步驟。以下是一些影響因素：
●索引中不包括一個或幾個待排序的列；
●group by或order by子句中列的次序與索引的次序不一樣；
●排序的列來自不同的表。
為了避免不必要的排序，就要正確地增建索引，合理地合並資料庫表（盡管有時可能影響表的規范化，但相對於效率的提高是值得的）。如果排序不可避免，那麼應當試圖簡化它，如縮小排序的列的范圍等。
3．消除對大型錶行數據的順序存取
在嵌套查詢中，對表的順序存取對查詢效率可能產生致命的影響。比如採用順序存取策略，一個嵌套3層的查詢，如果每層都查詢1000行，那麼這個查詢就要查詢10億行數據。避免這種情況的主要方法就是對連接的列進行索引。例如，兩個表：學生表（學號、姓名、年齡……）和選課表（學號、課程號、成績）。如果兩個表要做連接，就要在「學號」這個連接欄位上建立索引。
還可以使用並集來避免順序存取。盡管在所有的檢查列上都有索引，但某些形式的where子句強迫優化器使用順序存取。下面的查詢將強迫對orders表執行順序操作：
SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
雖然在customer_num和order_num上建有索引，但是在上面的語句中優化器還是使用順序存取路徑掃描整個表。因為這個語句要檢索的是分離的行的 *** ，所以應該改為如下語句：
SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001
UNION
SELECT ＊ FROM orders WHERE order_num=1008
這樣就能利用索引路徑處理查詢。
4．避免相關子查詢
一個列的標簽同時在主查詢和where子句中的查詢中出現，那麼很可能當主查詢中的列值改變之後，子查詢必須重新查詢一次。查詢嵌套層次越多，效率越低，因此應當盡量避免子查詢。如果子查詢不可避免，那麼要在子查詢中過濾掉盡可能多的行。
5．避免困難的正規表達式
MATCHES和LIKE關鍵字支持通配符匹配，技術上叫正規表達式。但這種匹配特別耗費時間。例如：SELECT ＊ FROM customer WHERE zipcode LIKE 「98_ _ _」
即使在zipcode欄位上建立了索引，在這種情況下也還是採用順序掃描的方式。如果把語句改為SELECT ＊ FROM customer WHERE zipcode >「98000」，在執行查詢時就會利用索引來查詢，顯然會大大提高速度。
另外，還要避免非開始的子串。例如語句：SELECT ＊ FROM customer WHERE zipcode[2，3]>「80」，在where子句中採用了非開始子串，因而這個語句也不會使用索引。
6．使用臨時表加速查詢
把表的一個子集進行排序並創建臨時表，有時能加速查詢。它有助於避免多重排序操作，而且在其他方面還能簡化優化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>「98000」
ORDER BY cust.name
如果這個查詢要被執行多次而不止一次，可以把所有未付款的客戶找出來放在一個臨時文件中，並按客戶的名字進行排序：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
INTO TEMP cust_with_balance
然後以下面的方式在臨時表中查詢：
SELECT ＊ FROM cust_with_balance
WHERE postcode>「98000」
臨時表中的行要比主表中的行少，而且物理順序就是所要求的順序，減少了磁碟I/O，所以查詢工作量可以得到大幅減少。
注意：臨時表創建後不會反映主表的修改。在主表中數據頻繁修改的情況下，注意不要丟失數據。
7．用排序來取代非順序存取
非順序磁碟存取是最慢的操作，表現在磁碟存取臂的來回移動。SQL語句隱藏了這一情況，使得我們在寫應用程序時很容易寫出要求存取大量非順序頁的查詢。
有些時候，用資料庫的排序能力來替代非順序的存取能改進查詢。
實例分析
下面我們舉一個製造公司的例子來說明如何進行查詢優化。製造公司資料庫中包括3個表，模式如下所示：
1．part表
零件號?????零件描述????????其他列
（part_num）?（part_desc）??????（other column）
102，032???Seageat 30G disk?????……
500，049???Novel 10M neork card??……
……
2．vendor表
廠商號??????廠商名??????其他列
（vendor _num）?（vendor_name） （other column）
910，257?????Seageat Corp???……
523，045?????IBM Corp?????……
……
3．parven表
零件號?????廠商號?????零件數量
（part_num）?（vendor_num）?（part_amount）
102，032????910，257????3,450,000
234，423????321，001????4，000，000
……
下面的查詢將在這些表上定期運行，並產生關於所有零件數量的報表：
SELECT part_desc，vendor_name，part_amount
FROM part，vendor，parven
WHERE part.part_num=parven.part_num
AND parven.vendor_num = vendor.vendor_num
ORDER BY part.part_num
如果不建立索引，上述查詢代碼的開銷將十分巨大。為此，我們在零件號和廠商號上建立索引。索引的建立避免了在嵌套中反復掃描。關於表與索引的統計信息如下：
表?????行尺寸???行數量?????每頁行數量???數據頁數量
（table）?(row size)?（Row count）?（Rows/Pages）?（Data Pages）
part????150?????10，000????25???????400
Vendor???150?????1，000???? 25???????40
Parven???13????? 15，000????300?????? 50
索引?????鍵尺寸???每頁鍵數量???頁面數量
（Indexes）?(Key Size)?（Keys/Page)???(Leaf Pages）
part?????4??????500???????20
Vendor????4??????500???????2
Parven????8??????250???????60
看起來是個相對簡單的3表連接，但是其查詢開銷是很大的。通過查看系統表可以看到，在part_num上和vendor_num上有簇索引，因此索引是按照物理順序存放的。parven表沒有特定的存放次序。這些表的大小說明從緩沖頁中非順序存取的成功率很小。此語句的優化查詢規劃是：首先從part中順序讀取400頁，然後再對parven表非順序存取1萬次，每次2頁（一個索引頁、一個數據頁），總計2萬個磁碟頁，最後對vendor表非順序存取1.5萬次，合3萬個磁碟頁。可以看出在這個索引好的連接上花費的磁碟存取為5.04萬次。
建議你直接用Jdbc好了，用batch，這樣是最快的。
打開資料庫
con.Open();
讀取數據
OdbcDataReader reader = cmd.ExecuteReader();
把數據載入到臨時表
dt.Load(reader);
在使用完畢之後，一定要關閉，要不然會出問題
reader.Close();
這個問題是這樣的：
首先你要明確你的插入是正常業務需求么？如果是，那麼只能接受這樣的數據插入量。
其次你說資料庫存不下了 那麼你可以讓你的資料庫上限變大 這個你可以在資料庫裡面設置的 裡面有個資料庫文件屬性 maxsize
最後有個方法可以使用，如果你的歷史數據不會對目前業務造成很大影響 可以考慮歸檔處理 定時將不用的數據移入歷史表 或者另外一個資料庫。
注意平時對資料庫的維護 定期整理索引碎片
時間維度分區表，然後定情按照規則將屬於歷史的分區數據遷移到，歷史庫上，寫個存儲自動維護分區表。
一次性插入大量數據，只能使用循環，
如：游標，while 循環語句
下面介紹While 循環插入數據，
SQL 代碼如下：
IF OBJECT_ID('dbo.Nums') IS NOT NULL
DROP TABLE dbo.Nums;
GO
CREATE TABLE dbo.Nums(n INT NOT NULL PRIMARY KEY);
DECLARE @max AS INT, @rc AS INT;
SET @max = 5000000;
SET @rc = 1;
INSERT INTO Nums VALUES(1);
WHILE @rc * 2 <= @max
BEGIN
INSERT INTO dbo.Nums SELECT n + @rc FROM dbo.Nums;
SET @rc = @rc * 2;
END
INSERT INTO dbo.Nums SELECT n + @rc FROM dbo.Nums WHERE n + @rc <= @max;
--以上函數取自Inside SQL Server 2005: T-SQL Query一書。
INSERT dbo.Sample SELECT n, RAND(CAST(NEWID() AS BINARY(16))) FROM Nums
ini_set('max_execution_time',Ɔ');
$pdo = new PDO("mysql:host=localhost;dbname=test","root","123456");
$sql = "insert into test(name,age,state,created_time) values";
for($i=0; $i<100000; $i++){
$sql .="('zhangsan',21,1,-09-17')";
}
$sql = substr($sql,0,strlen($sql)-1);
var_mp($sql);
if($pdo -> exec($sql)){
echo "插入成功！";
echo $pdo -> lastinsertid();
}
試試吧。10萬條1分鍾多，我覺得還行
就是直接把DataSet 類型作為參數直接傳遞給服務端
WCF默認支持這么做，直接傳Datatable不行。
你看一下 「服務引用設置」中你選的 *** 類型是什麼，我選的是System.Array
字典 *** 類型是默認第一項 System.Collections.Generic.Dictionary
又是一個把自己架在火上烤的需求啊，
如果不考慮傳輸因素，可以調整wcf配置，提升傳遞的容量，如果是對象傳遞可能還要調整對象層次的深度
『貳』 淺談Oracle中大數據量表的管理
簡介
隨著信息業的發展 在企業級資料庫應用中 經常會有一些幾十GB 上百GB的數據表 這些大數據量表的設計 維護及其備份都是資料庫管理中的重點及其難點 本文就從設計 維護及其備份方面探討一下大數據量表的管理
設計
大表時效性
大數據量表的數據量一般來說是跟時間成正比的 時間越久 數據量越大 在設計階段首先要考慮這些大表的時效性
通常情況 在一定的時間區間 數據的訪問頻度比較大 超過這個區間 數據的訪問頻度極小 這個時間區間根據不同的應用類型而不同 通常是幾個月 超過這個時間區間的數據可以認為是歷史數據 數據訪問的可能性不打 在企業應用中 並不是所有的數據都需要保留在生產資料庫中 對於這些歷史數據 可以考慮離線存放 或者是存放在另外的資料庫中 比如數據倉庫等
大表的時效性可以通過在表上加時間戳列來實現
使用分區表
Oracle 以後提供了分區表的功能 分區表可以把一個表的數據從物理和邏輯上分割成小的區域 Oracle支持非常大的分區表 一個對象可以允許多達 個分區 對於大表來說 使用分區表是首選方案 分區表可以改善表的維護 備份 恢復及查詢性能
分區表有 種分區方式
n Range Partitioning
n Hash Partitioning
n Composite Partitioning
n List Partitioning
對於有時效性的大表 可以採用按時間分區的 Range Partitioning表 例如按天分區的分區表
CREATE TABLE Test(
DATATIME DATE NOT NULL
P NUMBER NULL
P NUMBER NULL
P NUMBER NULL
P NUMBER NULL
P NUMBER NULL
P NUMBER NULL
P NUMBER NULL
P NUMBER NULL
CONSTRAINT PK_TEST PRIMARY KEY (datatime p p ) USING INDEX LOCAL TABLESPACE USERINDEX
)
PARTITION BY RANGE (DATATIME)
(PARTITION Test_ VALUES LESS THAN (TO_DATE( YYYY MM DD ))
(PARTITION Test_ VALUES LESS THAN (TO_DATE( YYYY MM DD ))
……
);
對於按時間分區仍然不能滿足性能需求的表 還可以根據應用需求 使用子分區對表進一步細化
應用設計中 要充分利用分區表的特性 對大表的訪問要完全避免全表訪問 縮小訪問范圍 在查詢條件中 盡量使用分區的列
維護
大表的維護工作比較繁瑣 索引的維護 存儲空間的維護 歷史數據的清理等等 使用分區表可以簡化大表的維護工作 但是如果表很多的話 手動的創建 刪除分區也是一件很繁瑣 而且容易出錯的事情
此章節以按天分區的分區表為例討論大表的自動維護
分區表的命名規則
分區表分區的命名應當按照一定的規則命名 以利於自動維護的實現 本例採用按天分區的分區表 分區的命名方式為TABLENAME_YYMMDD 例如 TEST表的 年 月 日的分區命名為TEST _
維護字典
在資料庫中創建維護字典表 存放需要自動維護的分區表的信息 包括表名 schema 表的類型 數據在資料庫中的保留時間等信息
Table Name: H_RETENTION
Column Type Null? Description
tablename Varchar ( ) Not null 表名
schemaname Varchar ( ) Not null Schema
typeid Varchar ( ) Not null 表類型 PARTITION NORMAL …
retention Number( ) Not null 該表的保存天數
自動創建分區
對於按時間分區的分區表 若不能及時創建新的數據分區 會導致數據無法插入到分區表的嚴重後果 資料庫會產生報錯信息ORA : inserted partition key does not map to any partition 插入失敗
創建分區可以手工創建 也可以根據維護字典 通過系統的任務調度來創建分區 通常是在月底創建下個月的分區
自動創建分區實現如下
/**************************************************************************
Program Name:Add_Partition
Description:
創建某個用戶下個月的所有分區
***************************************************************************/
PROCEDURE add_partition (v_schema IN VARCHAR )
IS
CURSOR c_td_table
IS
SELECT tablename
FROM h_retention
WHERE typeid ＝ PARTITION
AND schemaname = UPPER (v_schema)
ORDER BY tablename;
v_cur BINARY_INTEGER;
v_int BINARY_INTEGER;
v_partition VARCHAR ( );
v_date DATE;
v_days NUMBER;
sql_stmt VARCHAR ( ); String used to save sql statement
err_msg VARCHAR ( );
BEGIN
v_date := TRUNC (ADD_MONTHS (SYSDATE ) MM );
v_days :=
TO_NUMBER (TO_CHAR (LAST_DAY (ADD_MONTHS (SYSDATE )) DD ));
v_cur := DBMS_SQL open_cursor;
FOR v_table IN c_td_table
LOOP
v_date := TRUNC (ADD_MONTHS (SYSDATE ) MM );
v_partition := v_table tablename;
FOR i IN v_days
LOOP
BEGIN
sql_stmt :=
ALTER TABLE
|| v_schema
||
|| v_table tablename
|| ADD PARTITION
|| v_partition
|| _
|| TO_CHAR (v_date YYMMDD )
||
|| VALUES LESS THAN (TO_DATE(
|| TO_CHAR (v_date + YYYY MM DD )
|| YYYY MM DD )) ;
DBMS_SQL parse (v_cur sql_stmt DBMS_SQL native);
v_int := DBMS_SQL EXECUTE (v_cur);
EXCEPTION
WHEN OTHERS
THEN
err_msg :=
v_partition
|| : Create
|| TO_CHAR (v_date YYMMDD )
|| partition unsuccessfully! Error Information:
|| SQLERRM;
log_insert (err_msg); You can define your own log_insert function
MIT;
END;
v_date := v_date + ;
END LOOP;
END LOOP;
DBMS_SQL close_cursor (v_cur);
END;
自動刪除過期分區
為了釋放存儲空間並提高大表的性能 要從資料庫中刪除大表中過期的歷史數據 刪除操作可以手工執行 也可以通過系統的任務調度來自動刪除 分區表數據刪除只需要刪除相應的數據分區 與delete相比 有如下好處
u 速度快
u 佔用回滾表空間少
u 產生日誌量少
u 釋放空間
如果有global的索引 刪除分區後需要重建索引
自動刪除分區實現如下
lishixin/Article/program/Oracle/201311/18275
『叄』 Oracle資料庫大數據量表如何優化
要看數據多到何種程度。
比如一個表的筆數只是幾百，如果不需要和其他大表關聯內查詢數據，連索引都不用建。
如果容是幾十萬級別的表，一般正確建索引就可以。
如果是千萬級別的表，不但要正確建索引，而且要定時手工進行收集統計信息維護，不建議系統自動維護，以免影響使用性能。
如果是億以上級別的表，則可考慮按一定條件拆分表資料，將舊資料歸檔，這樣可改善生成表的使用。
資料庫優化的同時，程序也要進行相應優化，程序和數據科學搭配，才能使性能達到最佳。
『肆』 Oracle資料庫大數據量表如何優化
要看數據多到何種程度。
比如一個表的筆數只是幾百，如果不需要和其他大表關聯查詢數據，連索引都不用建。
如果是幾十萬級別的表，一般正確建索引就可以。
如果是千萬級別的表，不但要正確建索引，而且要定時手工進行收集統計信息維護，不建議系統自動維護，以免影響使用性能。
如果是億以上級別的表，則可考慮按一定條件拆分表資拆好租料，將舊資料歸檔，這樣可改旅兆善生成表的使用。
資料庫優化的同時，程序也要襪盯進行相應優化，程序和
數據科學
搭配，才能使性能達到最佳。
『伍』 供應鏈大數據分析
供應鏈大數據分析
供應鏈大數據分析，越來越多的企業採用數據分析來應對供應鏈中斷，並加強供應鏈管理(SCM)，目前有幾項重大中斷正在影響供應鏈。以下分享供應鏈大數據分析，一起來看看。
全面解析大數據給供應鏈帶來的益處
時下，大數據已經完全跨越概念炒作，而成為很多行業業務發展中實實在在應用的重要武器，但是在供應鏈管理領域，大數據技術的應用產業發展則處於起步階段，但是相信伴隨其他行業大數據的快速發展，供應鏈管理中的大數據也會迅速跟上來，那麼人們勢必會問大數據到底能夠為供應鏈帶來哪些益處呢，下面請隨乾元坤和我一同了解大數據給供應鏈帶來的好處。
大數據與供應鏈
1、庫存優化。比如，SAS獨有的功能強大的庫存優化模型可以實現在保持很高的客戶滿意度基礎上，把供應成本降到最低並提高供應鏈的反應速度。
其庫存成本第一年就可下降15%～30%，預測未來的准確性則會上升20%，由此帶來的是其整體營收會上升7%～10%。當然還有一些其他的潛在好處，如提升市場份額等。此外，運用SAS系統，產品質量會得到顯著提升，次品率也會因此減少10%～20%。
2、創造經營效益，從供應鏈渠道，以及生產現場的儀器或感測器網路收集了大量數據。利用大數據對這些資料庫進行更緊密的整合與分析，可以幫助改善庫存管理、銷售與分銷流程的效率，以及對設備的連續監控。製造業要想發展，企業必須了解大數據可以產生的成本效益。對設備進行預測性維護，現在就具備採用大數據技術的條件。製造業將是大數據營業收入的主要來源。
3、B2B電商供應鏈整合。強大的電商將引領上游下游生產計劃-下游銷售對接，這種對接趨勢是上游製造業外包供應鏈管理Supply-Chain，只專注於生產Manufacturing，ProctionChain(R&D)。
物流外包上升到供應鏈外包是一個巨大的飛躍，體現了電商的強大競爭力和整合能力，海量數據支持和跨平台、跨公司的對接成為可能。B-B供應鏈整合具有強大的市場空間，能夠改善我國產業布局、產業鏈優化、優化產能分配、降低庫存、降低供應鏈成本、提高供應鏈效率。
4、物流平台規模發展，B-C商業模式整合已經成為現實，但是物流執行平台的建設是拖後腿的瓶頸。多樣產品的銷售供應鏈的整合有很大的技術難題，如供貨周期、庫存周期、配送時效、物流操作要求等，這樣的物流中心難度很大。
大數據平台建設將驅動整體銷售供應鏈整合;中國的還有的現實問題跨區域物流配送、城鄉差異等，政府的管制是一大難點/疑難雜症，大數據平台有助於政府職能調整到位。
5、產品協同設計，過去大家最關心的是產品設計。可是現在，在產品設計和開發過程中，相關人員相互協同，工廠與製造能力也在同步設計和開發中。當前的壓力在於向市場交付更具競爭力、更高配置、更低價格、更高質量的產品，而同時滿足所有這些要求，是製造和工程企業的下一個重大的價值所在。這也正是大數據的用武之地。
企業如何部署大數據?
要讓數據發揮價值，首先要處理大數據，要能夠共享、集成、存儲和搜索來自眾多源頭的龐大數據。而就供應鏈而言，這意味著要能夠接受來自第三方系統的數據，並加快反饋速度。
其整體影響是增強協同性、加快決策制定和提高透明度，這對所有相關人員都有幫助。傳統供應鏈已經在使用大量的結構化數據，企業部署了先進的供應鏈管理系統，將資源數據，交易數據，供應商數據，質量數據等等存儲起來用於跟蹤供應鏈執行效率，成本，控制產品質量。
大數據給供應鏈帶來的好處
而當前大數據的概念則超出了傳統數據產生、獲取、轉換、應用分析和存儲的概念，出現非結構化數據，數據內容也出現多樣化，大數據部署將面臨新的挑戰。
針對如今所生成、傳輸和存儲的海量信息進行簡單處理所帶來的挑戰。當前，數據量呈爆炸式增長，而隨著M2M(機器對機器的通訊)的應用，此趨勢仍將持續下去。
但是，如若能夠解決這些挑戰，將可以打開嶄新的局面?核心在兩個方面：
1、解決數據的生成問題，即如何利用物聯網技術M2M獲取實時過程數據，虛擬化供應鏈的流程。通過挖掘這些新數據集的潛力，並結合來源廣泛的信息，就可能獲得全新的洞見。如此，企業可以開發全新的流程，並與產品全生命周期的各個方面直接關聯。與之集成的還有報告和分析功能，為流程提供反饋，從而創建一個良性的強化循環。
2、解決數據應用的問題，如何讓供應鏈各個價值轉換過程產生的數據發生商業價值，是發揮數據部署的革命性生產力的根本。大數據在供應鏈的應用已經不是簡單的交易狀態可視，支撐決策庫存水平，傳統ERP結構是無法承擔的。因此企業必須重新做好數據應用的頂層設計，建立強大全面的大數據應用分析模型，才能應對復雜海量的數據如何發揮價值的挑戰。
大數據在供應鏈領域的應用剛剛起步，隨著供應鏈的迅速發展，大數據分析，數據管理，大數據應用，大數據存儲在供應鏈領域蘊含巨大的發展潛力，大數據的投資也只有與供應鏈結合，才能產生可持續、規模化發展的產業
大數據分析對供應鏈有什麼影響
如今，從物流到客戶偏好的各種數據的持續增長正在迅速改變企業的經營方式，並突出了對加強數據管理和分析的強烈需求。大數據分析(指大型和復雜的數據集)的好處是顯而易見的：大數據可以完全改變組織的工作方式，在效率、成本、可見性和客戶滿意度方面產生巨大差異。
大數據來源廣泛：
-如今的技術和社交平台允許企業以評級、評論和博客評論的形式獲得直接的客戶反饋。
-來自移動通信、社交平台和電子商務的數據正在與來自企業系統的數據集成。
-隨著物聯網和機器對機器通信的引入，製造業正在從基於事件的計劃轉變為實時感測。
-不斷發展的感測器技術可提供實時設備和產品狀況數據，從而實現自動維護和過程調整。
數據在數量上、種類上和速度上都有所增長，如果以正確的方式加以利用，可以帶來巨大的價值。
研究顯示，企業已經在推動整個企業供應鏈的生產力，但在供應鏈功能中使用大數據分析在全球企業中並不普遍或協調得很好。受益於大數據分析的公司有三個共同點：它們擁有強大的企業級分析戰略，它們將大數據分析嵌入供應鏈運營，它們擁有合適的人才庫，能夠從大數據中產生可操作的見解。
有必要僱用、培訓和扶持能夠幫助企業從大數據分析中受益的領導者。從人力資本的角度來看，大多數公司的定位尚不足以接受數字化供應鏈轉型。我們分析了各行各業的50多位高級供應鏈高管的個人資料，以了解他們在供應鏈數字化方面的定位。在涉及所謂的「數字防備連續性」方面，各行各業的公司中絕大多數高管都普遍缺乏。
調研機構采訪了各行各業的商界領袖，以探討當今日益數字化的世界對首席供應鏈官的角色以及供應鏈領導者與高級管理人員中其他高管人員之間互動的影響。通過這些訪談，我們發現了供應鏈領導者應具備的四個關鍵特徵，以便能夠從大數據分析中獲得收益：
1、對數據和系統技術有深刻的了解。當今的企業可以通過數據分析和通過數字方式收集數據來深入了解客戶行為。盡管不需要首席供應鏈官成為信息技術（IT）專家，但他們應該對數據收集、技術和分析有足夠的了解，以引導對話並為高級領導者及其供應鏈團隊提供數字化願景。
供應鏈領導者應認識到如何實施和利用相關平台和流程以及數據來自何處，並應表現出對來自各種渠道的數據范圍和規模的扎實理解。重要的是，領導者必須准備好對數據採取明智的行動。
2、具有影響力的協作方法。如果首席供應鏈官在孤島工作，將無法從大數據分析中獲得收益。在內部，供應鏈領導者必須能夠與首席技術官進行溝通和協作，以幫助確定適合組織的技術和政策；
與首席數據官一起了解如何最佳地捕獲和使用數據；與首席營銷官一起，評估供應鏈如何能夠更專注於客戶和需求驅動，並與首席執行官具體溝通更廣泛的創造價值的機會。最終，供應鏈執行官將需要能夠與內部利益相關者和外部供應商建立橋梁。
3、跨職能經驗。如今的供應鏈管理人員具有跨部門的經驗，並且能夠理解和與來自多個業務部門的人員進行交流。重要的是，首席供應鏈官員還必須具有銷售、財務或技術方面的知識。
4、發展新技能和培訓他人的能力。當今的首席供應鏈官必須緊跟最新技術，以確保組織適當地吸收數字技能和分析人才。企業犯的最大錯誤之一是在沒有適當准備組織的情況下實施大數據分析項目。建立內部計劃以確保在整個供應鏈中採用技能至關重要。
要從整個供應鏈或整個組織的大數據分析中獲取所有好處，不僅需要技術和IT。從首席執行官和執行委員會開始，企業必須准備好支持一種全新的思維方式，培養一種對創新和技術開放的文化，並願意挑戰關於供應鏈管理方式的慣例。
大數據分析對供應鏈有什麼影響、中琛魔方大數據分析平台(www、zcmorefun、com)表示由於供應網路上數十億的連接設備提供關於服務需求、位置和庫存分布的實時信息，甚至實現預期的需求，理解和接受大數據的執行領導層、數字顛覆和這些趨勢的人力資本方面對未來企業的優勢至關重要。
"以零售門店為中心"的供應鏈分析框架
一、目的
本文旨在介紹「以零售門店為中心」的供應鏈管理，簡要介紹此框架下供應鏈管理的具體內容及行業痛點。
二、供應鏈是什麼？
供應鏈
所謂供應鏈，是指由涉及將產品或服務提供給最終消費者的整個活動過程的上游、中游和下游企業所構成的網路。包括從原材料采購開始，歷經供應商、製造商、分銷商、零售商，直至最終消費者的整個運作過程。
供應鏈管理
供應鏈管理，指的是圍繞核心企業，對供應鏈中的物流、信息流、資金流以及貿易夥伴關系等進行組織、計劃、協調、控制和優化的一系列現代化管理。
它將企業內部經營所有的業務單元如訂單、采購、庫存、計劃、生產、質量、運輸、市場、銷售、服務等以及相應的財務活動、人事管理均納入一條供應鏈內進行統籌管理。
在傳統零售或者傳統行業中，供應鏈主要局限在供應鏈的後端，即采購、生產、物流等職能，與消費者、銷售渠道的協同整合嚴重不足，導致牛鞭效應、孤島現象、的出現，讓供應鏈的反應總是很滯後。
三、「以零售門店為中心」的供應鏈管理
供應鏈網路
「以零售門店為中心」的'供應鏈網路（見下圖），即以滿足門店銷售及運營核心、銷售利潤最大化的供應鏈管理。
在此分析框架上，核心目標是最大條件滿足消費者需求，即管理缺貨、減少缺貨，管理滯銷、處理滯銷。此框架下供應鏈管理的內容為：門店補貨、門店調撥、缺貨管理管理、滯銷管理、促銷管理等。
供應鏈管理
需求預測
需求預測是所有供應鏈規劃的基礎；供應鏈中所有的流程都是根據對顧客需求的預測來進行的。因此，供應鏈管理的首要工作是對未來顧客的需求進行預測。
1、預測需要考慮的影響因素
需求預測需要考慮的重要影響因素：
歷史需求
產品補貨提前期
節假日
廣告或其他營銷活動的力度
競爭對手採取的行動
價格及促銷計劃
經濟狀況
2、預測方法
定性預測法
主要依賴於人的主觀判斷。當可供參考的歷史數據很少或專家擁有影響預測的需求市場信息時，採用定性預測方法最合適。
時間序列預測法
運用歷史需求數據對未來需求進行預測，它尤其適用於每年基本需求模式變化不大的場景。
因果關系預測法
假定需求預測與某些環境因素(經濟狀況、稅率等)調度相關，因果關系預測法可以找到這些環境因素與需求的關聯性，通過預測這些外界因素的變化來預測未來需求。
模擬法
通過模擬消費者的選擇來預測需求。如價格促銷將會帶來什麼樣的影響？競爭對手在附近開設一家新店會帶來什麼樣的影響？
門店補貨
1、什麼時候補貨？
什麼時候補貨？它是時間與頻次的問題，即補貨的觸發點問題。
通常有兩種策略：
策略一、設置庫存閥值，若庫存低於閥值則補貨。通過連續檢查的方法，判斷某個時刻是否需要補貨。
策略二、設置固定的補貨周期，零售門店通常按周來設置補貨頻次，即一周設置多次補貨頻次，並固定在某幾天，如某門店在周一、周三、周五補貨。
連鎖零售企業一般採用第二種策略，主要是因為零售企業經營的SKU數量眾多；另一方面，策略一的物流及倉庫排班及排車不確定高，不適合物流及倉庫的管理及運營。
本文的供應鏈鏈管理以策略二為基礎，並依此展開分析及研究。
2、補什麼商品？
季節性的品類調整
門店必須根據季節的變化，對商品陳列位置、商品結構、店鋪氛圍進行調整。一般來講，門店應該每年進行兩次大的調整，即：每年3-4月份針對春夏季的調整，每年國慶節過後的10-11月份期間的針對秋冬季節的調整; 每個季度針對本季度特殊季節、節日的變化進行的小調整，或臨時調整。
調整商品結構
商品結構必須根據季節變化進行調整。季節變化對商品結構的影響是非常大的，必須在季節變化到來之前，及時調整品類結構，壓縮過季商品品類，擴大應季商品的品類。
調整陳列位置和陳列資源
門店的陳列位置、陳列資源，對商品銷售產出的貢獻非常巨大，不同的陳列位置商品銷售會有幾倍甚至幾十倍的差距。門店的重點陳列位置、陳列資源必須隨季節變化而調整。一是季節商品是產生銷售貢獻*大的商品，二是季節商品是*能體現門店經營特色的商品，三是季節商品是*能提示消費者購物的商品。
重大節慶的品類調整
在快時尚、輕奢的品類中，很容易出現春節、婦女節(女王節)、情人節、開學季、聖誕節、雙十一等的節慶影響，表現出銷量井噴。零售企業需要根據節慶來完善豐富的品類結構，滿足顧客在特定節慶時期的消費需求。
市場變化導致的品類調整
禁配策略
地理環境因素，如西北地區處於內陸、遠離海洋，夏天不適合配沙灘遊玩類用品。風俗、宗教類因素，穆斯林地區禁止配送豬肉類食品。
新品策略
若零售公司准備投放一批新品，零售門店則需要為新品調整貨架，增加新品的曝光度，引導消費者產生首次購買、重復購買。
3、補多少量？
補貨量 = 需求量 – 門店庫存
計算門店需求時以需求預測為基礎，同時考慮下述影響需求及供給的約束條件：
倉庫容量
門店貨架容量
過去需求
產品補貨提前期
廣告計劃或其他營銷活動的力度
價格促銷計劃
競爭企業採取的行動
4、缺貨場景的庫存分配策略
策略一：增加相似商品的補貨庫存 相似商品：功能、顏色、功效相似的商品。
策略二：增加其他暢銷品的庫存 根據商品的銷售量排名，根據一定的分配策略來補貨。
缺貨管理
連鎖零售企業商品缺貨狀況會引發消費者的各種反應， 最終導致零售企業的銷售損失，48%的人會購買同一品種的替代品，15％的消費者不再購買，31％的顧客會到另一家店購買時再實施消費行為，顧客的轉店率是37％。
1、缺貨原因及應對策略
倉庫缺貨
渠道單一。單純地依靠某一個供應商或過分依賴某些材料部件，一旦某個供應環節中斷，將影響整個供應鏈的正常運作。缺乏預見能力。由於缺乏對供應鏈上的可預測性，不具有對供應商的供應能力和不確定性的前向洞察力，常常會面臨種種不確定因素影響所帶來的庫存短缺。應對措施：替代商品
補貨量不足
某商品銷售出現顯著增長，且明顯大於預期、門店庫存不足，但補貨不及時。應對措施：門店調撥 在零售行業中，線上線下競爭如此激烈，誰能快速解決各個商圈內門店之間、商圈之間超密集的調撥需求，實現高效調撥、把握銷售機會，實現銷售業績的新突破。
滯銷管理
1、滯銷危害
在陳列空間上，滯銷商品大量陳列占據了門店的貨架空間，迫使其他暢銷品的陳列空間不夠，新上市商品無法正常上貨。
滯銷商品佔用大量的資金，使得零售門店的流動資金日益萎縮，嚴重的會影響到正常商品采購、甚至導致門店倒閉。
對於顧客來說，滯銷商品大量陳列在貨架上，這樣既影響了顧客挑選自己需要的商品，浪費了消費者的注意力，甚至導致顧客無法找到正常的商品，損失了門店應該獲取的利潤。
從門店商圈來看，門店大量商品長期不做銷售周轉，消費可能會對門店失去信息，減少或改變原本的購物需求，轉向其他門店進行消費。
2、滯銷原因
季節因素
部分商品因地區差異存在明顯的季節之分，該部分商品由於季末沒有做特殊處理，導致在庫時間高於規定的天數，形成滯銷，體現在換季時門店任務按正常時段的銷售量作為補貨的依據產生。
補貨模型不合理因素
行業中大多數公司會把門店庫存管理權交給店長，由於公司的高速發展，門店會不斷地有新店長上任，店長庫存管理概念模糊，在補貨時大多憑借個人經驗確定補貨數量，容易導致部分補貨量較大的商品滯銷。
價格因素滯銷
部分商品會因為價格不合理而導致滯銷，一種是低價格商品，由於門店所處的商圈消費水平較高，價格低廉的老葯滯銷；另一種則是因為門店商品售價明顯高於競爭對手的售價導致滯銷。
陳列因素
與海量商品相比，門店的貨架資源永遠都是稀缺的，部分企業會給予部分商品特殊待遇，不能公平合理地分配貨架資源，導致部分商品因陳列位置差、曝光率低，從而導致滯銷。
淘汰商品不順暢
商品都會存在生命周期，特別是一些廣告商品，然而大多數公司更新商品都比較被動，不會主動去優化商品，會導致商品因同質化嚴重而引起滯銷。
批量采購決策失誤
供應鏈上游對市場需求及銷售情況沒有準確把握，商品采購數量過多，從而導致滯銷。
突發因素
某些突發因素導致消費行為發生重大變化。如」非洲豬瘟」導致豬肉類食品無法銷售出去，從而導致滯銷。
痛點
供應鏈上游滯銷引發的風險轉稼
在零售連鎖供應鏈網路中，供應鏈上游由於產品開發、采購失誤等決策失誤導致的庫存積壓，上游往往會將庫存風險轉稼到供應鏈末端(零售門店)，從而佔用零售門店大量的流動資金及貨架資源。
市場快速變化，難以准確預測和判斷供貨情況。
門店端某款產品突然爆發，致使供應鏈上下游倉庫出現大面積缺貨，此種情況供應鏈無法快速反應或供應周期過長，從而導致銷售機會的浪費。
預期范圍內、延遲或產能不足，導致銷售機會的損失。
某些品類由於供應鏈上游(采購、供應商)等原因，如產能不足或機器故障等原因導致交付延遲，從而導致銷售機會的浪費。
市場競爭加劇，線下實體店客流下滑
總結
供應鏈末端(零售門店)缺乏足夠或針對性的應對措施
供應鏈上下游協同是解決」零售門店」問題的重要方向
科學、精準的貨架管理將是提升門店銷售、實現供應鏈價值的重要方向
四、供應鏈的發展趨勢
全渠道趨勢
移動互聯網的迅猛發展催生了O2O、C2B、P2P等新業態，全球傳統產業開始受沖擊，受互聯網思維與互聯網、大數據、雲計算等技術深度影響出現變革，全球傳統行業將互聯網化，擁抱O2O全渠道零售大時代。
供應鏈日趨可視化
在運營中對商品廣泛使用了電子標簽，將線上線下數據同步，如SKU同步、庫存同步、價格同步、促銷同步；實現線上下單，線下有貨，後台統一促銷和價格。
供應鏈可視化以後，未來所有業務職能包括銷售、市場、財務、研發、采購和物流等進行有機的集成和協同就有了可能，可以對消費者需求、門店或網上庫存、銷售趨勢、物流信息、原產地信息等進行可視化展示，實現供應鏈敏捷和迅速反應。
新時代下的供應鏈可視化未來將持續向消費者、SKU、店員延伸，通過可視化集成平台，戰略計劃與業務緊密鏈接，需求與供應的平衡，訂單履行策略的實施，庫存與服務水平的調整等具體策略將得到高效的執行。
供應鏈預測智能化
在新零售的業態中，大量零售運營數據包括消費者、商品、銷售、庫存、訂單等在不同的應用場景中海量產生，結合在不同業務場景和業務目標，如商品品類管理、銷售預測、動態定價、促銷安排、自動補貨、安全庫存設定、倉店和店店之間的調撥、供應計劃排程、物流計劃制定等，再匹配上合適的演算法，即可對這些應用場景進行數字建模，邏輯簡單來說就是「獲取數據—分析數據—建立模型—預測未來—支持決策」。
本質上說，智能演算法是一項預測科技，而預測的目的不是為預測而預測，而是用來指導人類的各項行為決策，以免人在決策時因為未知和不確定而焦慮。
當全新的供應鏈體系，能夠實時顯示運營動態，如貨齡、售罄率、缺貨率、暢售滯銷佔比、退貨率、訂單滿足率、庫存周轉率、目標完成比率等，同時又能相互鏈接和協同，那麼將很容易形成通用運營決策建議，如智能選品、智能定價、自動預測、自動促銷、自動補貨和下單等。
在此基礎之上，供應鏈管理人員所做的事情就是搜集信息、判斷需求、和客戶溝通、協同各種資源、尋找創新機會等。
『陸』 如何提高SQL Server大數據條件下的查詢速度
1.關於索引優化
建索引的選擇必須結合SQL查詢、修改、刪除語句的需要，一般的說法是在WHERE里經常出現的欄位建索引。如果在WHERE經常是幾個欄位一起出現而且是用AND連接的，那就應該建這幾個欄位一起的聯合索引，而且次序也需要考慮，一般是最常出現的放前面，重復率低的放前面。
SQL Server提供了一種簡化並自動維護資料庫的工具。這個稱之為資料庫維護計劃向導（Database Maintenance Plan Wizard ，DMPW）的工具也包括了對索引的優化。如果你運行這個向導，你會看到關於資料庫中關於索引的統計量，這些統計量作為日誌工作並定時更新，這樣就減輕了手工重建索引或者DBCC INDEXDEFRAG所帶來的工作量。如果你不想自動定期刷新索引統計量，你還可以在DMPW中選擇重新組織數據和數據頁，這將停止舊有索引並按特定的填充因子重建索引。
2.
改善硬體（雙CPU，Raid 5，增加內存）
tempdb這個臨時資料庫，它對性能的影響較大。tempdb和其他資料庫一樣可以增大，可以縮小。當數據文件需要增長的時候，通常不能保持剩餘部分的連續性。這時文件就會產生碎片，這種碎片會造成性能下降。這種碎片屬於外來性碎片。要阻止在tempdb中產生外來性碎片，必須保證有足夠的硬碟空間。一般將tempdb的容量放到平均使用容量。而你也應該允許tempdb自動增長，比如你有個一個超大的join操作，它建立了一個超過tempdb容量的時候，該查詢將失敗。你還要設置一個合理的單位增長量。因為如果你設得太小，將會產生許多外來性碎片，反而會佔用更多資源。sqlserver調優最有效的做法之一，就是把爭奪資源的操作獨立出去。tempdb就是一個需要獨立出去的部分而tempdb和其他系統庫一樣是公用的，是存取最可能頻繁的庫，所有處理臨時表、子查詢、GROUP BY、排序、DISTINCT、連接等等。它最適合放到一個具有快速讀寫能力的設備上。比如RAID0卷或RAID0+1卷上。
查詢語句一定要使用存儲過程；
3、查詢盡量使用TOP子句
4.將表按一定的約束分成子表,(如按分類)創建約束,在用Like 時,先用分類 and like , 應該可能解決問題. 而且效果立稈見影!(你要確定SQL會認識你建的分區視圖).我一個表有上百萬的記錄(700兆),用分區視圖後,查詢速度基本跟10萬行一樣.
如果還是太慢,還可以考濾分布式分區視圖!這總可以解決問題了吧!
關鍵在於你能否把大表按某種約束分解成子表.
『柒』 大數據量高並發訪問資料庫結構的設計
大數據量高並發訪問資料庫結構的設計
如果不能設計一個合理的資料庫模型，不僅會增加客戶端和伺服器段程序的編程和維護的難度，而且將會影響系統實際運行的性能。所以，在一個系統開始實施之前，完備的資料庫模型的設計是必須的。
在一個系統分析、設計階段，因為數據量較小，負荷較低。我們往往只注意到功能的實現，而很難注意到性能的薄弱之處，等到系統投入實際運行一段時間後，才發現系統的性能在降低，這時再來考慮提高系統性能則要花費更多的人力物力，而整個系統也不可避免的形成了一個打補丁工程。
所以在考慮整個系統的流程的時候，我們必須要考慮，在高並發大數據量的訪問情況下，我們的系統會不會出現極端的情況。（例如：對外統計系統在7月16日出現的數據異常的情況，並發大數據量的的訪問造成，資料庫的響應時間不能跟上數據刷新的速度造成。具體情況是：在日期臨界時（00：00：00），判斷資料庫中是否有當前日期的記錄，沒有則插入一條當前日期的記錄。在低並發訪問的情況下，不會發生問題，但是當日期臨界時的訪問量相當大的時候，在做這一判斷的時候，會出現多次條件成立，則資料庫里會被插入多條當前日期的記錄，從而造成數據錯誤。），資料庫的模型確定下來之後，我們有必要做一個系統內數據流向圖，分析可能出現的瓶頸。
為了保證資料庫的一致性和完整性，在邏輯設計的時候往往會設計過多的表間關聯，盡可能的降低數據的冗餘。（例如用戶表的地區，我們可以把地區另外存放到一個地區表中）如果數據冗餘低，數據的完整性容易得到保證，提高了數據吞吐速度，保證了數據的完整性，清楚地表達數據元素之間的關系。而對於多表之間的關聯查詢（尤其是大數據表）時，其性能將會降低，同時也提高了客戶端程序的編程難度，因此，物理設計需折衷考慮，根據業務規則，確定對關聯表的數據量大小、數據項的訪問頻度，對此類數據表頻繁的關聯查詢應適當提高數據冗餘設計但增加了表間連接查詢的操作，也使得程序的變得復雜，為了提高系統的響應時間，合理的數據冗餘也是必要的。設計人員在設計階段應根據系統操作的類型、頻度加以均衡考慮。
另外，最好不要用自增屬性欄位作為主鍵與子表關聯。不便於系統的遷移和數據恢復。對外統計系統映射關系丟失（******************）。
原來的表格必須可以通過由它分離出去的表格重新構建。使用這個規定的好處是，你可以確保不會在分離的表格中引入多餘的列，所有你創建的表格結構都與它們的實際需要一樣大。應用這條規定是一個好習慣，不過除非你要處理一個非常大型的數據，否則你將不需要用到它。（例如一個通行證系統，我可以將USERID，USERNAME，USERPASSWORD，單獨出來作個表，再把USERID作為其他表的外鍵）
表的設計具體注意的問題：
1、數據行的長度不要超過8020位元組，如果超過這個長度的話在物理頁中這條數據會佔用兩行從而造成存儲碎片，降低查詢效率。
2、能夠用數字類型的欄位盡量選擇數字類型而不用字元串類型的（電話號碼），這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接回逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。
3、對於不可變字元類型char和可變字元類型varchar都是8000位元組,char查詢快，但是耗存儲空間，varchar查詢相對慢一些但是節省存儲空間。在設計欄位的時候可以靈活選擇，例如用戶名、密碼等長度變化不大的欄位可以選擇CHAR，對於評論等長度變化大的欄位可以選擇VARCHAR。
4、欄位的長度在最大限度的滿足可能的需要的前提下，應該盡可能的設得短一些，這樣可以提高查詢的效率，而且在建立索引的時候也可以減少資源的消耗。
5、基本表及其欄位之間的關系, 應盡量滿足第三範式。但是，滿足第三範式的資料庫設計，往往不是最好的設計。為了提高資料庫的運行效率，常常需要降低範式標准：適當增加冗餘，達到以空間換時間的目的。
6、若兩個實體之間存在多對多的關系，則應消除這種關系。消除的辦法是，在兩者之間增加第三個實體。這樣，原來一個多對多的關系，現在變為兩個一對多的關系。要將原來兩個實體的屬性合理地分配到三個實體中去。這里的第三個實體，實質上是一個較復雜的關系，它對應一張基本表。一般來講，資料庫設計工具不能識別多對多的關系，但能處理多對多的關系。
7、主鍵PK的取值方法，PK是供程序員使用的表間連接工具，可以是一無物理意義的數字串, 由程序自動加1來實現。也可以是有物理意義的欄位名或欄位名的組合。不過前者比後者好。當PK是欄位名的組合時，建議欄位的個數不要太多，多了不但索引佔用空間大，而且速度也慢。
8、主鍵與外鍵在多表中的重復出現, 不屬於數據冗餘，這個概念必須清楚，事實上有許多人還不清楚。非鍵欄位的重復出現, 才是數據冗餘！而且是一種低級冗餘，即重復性的冗餘。高級冗餘不是欄位的重復出現，而是欄位的派生出現。
〖例4〗：商品中的「單價、數量、金額」三個欄位，「金額」就是由「單價」乘以「數量」派生出來的，它就是冗餘，而且是一種高級冗餘。冗餘的目的是為了提高處理速度。只有低級冗餘才會增加數據的不一致性，因為同一數據，可能從不同時間、地點、角色上多次錄入。因此，我們提倡高級冗餘(派生性冗餘)，反對低級冗餘(重復性冗餘)。
9、中間表是存放統計數據的表，它是為數據倉庫、輸出報表或查詢結果而設計的，有時它沒有主鍵與外鍵(數據倉庫除外)。臨時表是程序員個人設計的，存放臨時記錄，為個人所用。基表和中間表由DBA維護，臨時表由程序員自己用程序自動維護。
10、防止資料庫設計打補丁的方法是「三少原則」
(1) 一個資料庫中表的個數越少越好。只有表的個數少了，才能說明系統的E--R圖少而精，去掉了重復的多餘的實體，形成了對客觀世界的高度抽象，進行了系統的數據集成，防止了打補丁式的設計；
(2) 一個表中組合主鍵的欄位個數越少越好。因為主鍵的作用，一是建主鍵索引，二是做為子表的外鍵，所以組合主鍵的欄位個數少了，不僅節省了運行時間，而且節省了索引存儲空間；
(3) 一個表中的欄位個數越少越好。只有欄位的個數少了，才能說明在系統中不存在數據重復，且很少有數據冗餘，更重要的是督促讀者學會「列變行」，這樣就防止了將子表中的欄位拉入到主表中去，在主表中留下許多空餘的欄位。所謂「列變行」，就是將主表中的一部分內容拉出去，另外單獨建一個子表。這個方法很簡單，有的人就是不習慣、不採納、不執行。
資料庫設計的實用原則是：在數據冗餘和處理速度之間找到合適的平衡點。「三少」是一個整體概念，綜合觀點，不能孤立某一個原則。該原則是相對的，不是絕對的。「三多」原則肯定是錯誤的。試想：若覆蓋系統同樣的功能，一百個實體(共一千個屬性) 的E--R圖，肯定比二百個實體(共二千個屬性)的E--R圖，要好得多。
提倡「三少」原則，是叫讀者學會利用資料庫設計技術進行系統的數據集成。數據集成的步驟是將文件系統集成為應用資料庫，將應用資料庫集成為主題資料庫，將主題資料庫集成為全局綜合資料庫。集成的程度越高，數據共享性就越強，信息孤島現象就越少，整個企業信息系統的全局E—R圖中實體的個數、主鍵的個數、屬性的個數就會越少。
提倡「三少」原則的目的，是防止讀者利用打補丁技術，不斷地對資料庫進行增刪改，使企業資料庫變成了隨意設計資料庫表的「垃圾堆」，或資料庫表的「大雜院」，最後造成資料庫中的基本表、代碼表、中間表、臨時表雜亂無章，不計其數，導致企事業單位的信息系統無法維護而癱瘓。
「三多」原則任何人都可以做到，該原則是「打補丁方法」設計資料庫的歪理學說。「三少」原則是少而精的原則，它要求有較高的資料庫設計技巧與藝術，不是任何人都能做到的，因為該原則是杜絕用「打補丁方法」設計資料庫的理論依據。
11、在給定的系統硬體和系統軟體條件下，提高資料庫系統的運行效率的辦法是：
(1) 在資料庫物理設計時，降低範式，增加冗餘, 少用觸發器, 多用存儲過程。
(2) 當計算非常復雜、而且記錄條數非常巨大時(例如一千萬條)，復雜計算要先在資料庫外面，以文件系統方式用編程語言計算處理完成之後，最後才入庫追加到表中去。
(3) 發現某個表的記錄太多，例如超過一千萬條，則要對該表進行水平分割。水平分割的做法是，以該表主鍵PK的某個值為界線，將該表的記錄水平分割為兩個表。若發現某個表的欄位太多，例如超過八十個，則垂直分割該表，將原來的一個表分解為兩個表。
(4) 對資料庫管理系統DBMS進行系統優化，即優化各種系統參數，如緩沖區個數。
(5) 在使用面向數據的SQL語言進行程序設計時，盡量採取優化演算法。
總之，要提高資料庫的運行效率，必須從資料庫系統級優化、資料庫設計級優化、程序實現級優化，這三個層次上同時下功夫。
主鍵設計：
1、不建議用多個欄位做主鍵，單個表還可以，但是關聯關系就會有問題，主鍵自增是高性能的。
2、一般情況下，如果有兩個外鍵，不建議採用兩個外鍵作為聯合住建，另建一個欄位作為主鍵。除非這條記錄沒有邏輯刪除標志，且該表永遠只有一條此聯合主鍵的記錄。
3、一般而言，一個實體不能既無主鍵又無外鍵。在E—R 圖中, 處於葉子部位的實體, 可以定義主鍵，也可以不定義主鍵(因為它無子孫), 但必須要有外鍵(因為它有父親)。
主鍵與外鍵的設計，在全局資料庫的設計中，佔有重要地位。當全局資料庫的設計完成以後，有個美國資料庫設計專家說：「鍵，到處都是鍵，除了鍵之外，什麼也沒有」，這就是他的資料庫設計經驗之談，也反映了他對信息系統核心(數據模型)的高度抽象思想。因為：主鍵是實體的高度抽象，主鍵與、外鍵的配對，表示實體之間的連接。
『捌』 Oracle資料庫大數據量表如何優化
要看數據多到何種程度。
比如一個表的筆數只是幾百，如果不需要和其他
大表
關聯查詢數據，連
索引
都不用建。
如果是幾十萬級別的表，一般正確建索引就可以。
如果是千萬級別的表，不但要正確建索引，而且要定時手工進行收集
統計信息
維護，不建議系統自動維護，以免影響
使用性能
。
如果是億以上級別的表，則可考慮按一定條件拆分表
資料
，將舊資料歸檔，這樣可改善生成表的使用。
資料庫優化的同時，
程序
也要進行相應優化，程序和
數據科學
搭配，才能使性能達到最佳。