資料庫表設計

1. 為什麼要進行資料庫表設計

資料庫表是存放數據的地方，遵循一定規律設計的資料庫表，才能進行數據讀取，方便數據管理。否則就像進入雜亂的倉庫取東西一樣，沒法找到

2. 資料庫表的設計

用戶表：{用戶編號(PK)，用戶名，密碼，用戶類別, 所屬專業號(FK)}
課程表：{課程編號(PK)，課程名，用戶編號(FK) ,學分}
院 系：{院系編號(PK)，院名}
專 業：{專業號(PK)，專業名稱 ,專業簡介 ,總學時,所屬院號(FK)}
參考書：{索書號(PK)，課程編號(FK)，ISBN/ISSN，責任者，出版日期，校圖書館連接地址，電子書連接地址}
專業課程表{專業號,課程編號} 聯合主鍵

3. 資料庫表結構設計，常見的資料庫管理系統

一、數據場景 1、表結構簡介 任何工孫此段具類的東西都是為了解決某個場景下的問題，比如Redis緩存系統熱點數據，ClickHouse解決海量數據的實時分析，MySQL關系型資料庫存儲結構化數據。數據的存儲則需要設計對應的表結構，清楚的表結構，有助於快速開發業務，和理解系統。表結構的設計通常從下面幾個方面考慮：業務場景、設計規范、表結構、欄位屬性、數據管理。
2、用戶場景
例如存儲用戶基礎信息數據，通常都會下面幾個相關表結構：用戶信息表、單點登錄表、狀態管理表、支付賬戶表等。
用戶信息表
存儲用戶三要素相關信息：姓名，手機號，身份證，登錄密碼，郵箱等。
CREATE TABLE `ms_user_center` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用戶ID', `user_name` varchar(20) NOT NULL COMMENT '用戶名', `real_name` varchar(20) DEFAULT NULL COMMENT '真實姓名', `pass_word` varchar(32) NOT NULL COMMENT '密碼', `phone` varchar(20) NOT NULL COMMENT '手機號', `email` varchar(32) DEFAULT NULL COMMENT '郵箱', `head_url` varchar(100) DEFAULT NULL COMMENT '用戶頭像URL', `card_id` varchar(32) DEFAULT NULL COMMENT '身份證號', `user_sex` int(1) DEFAULT '1' COMMENT '用戶性別:0-女,1-男', `create_time` datetime DEFAULT NULL COMMENT '扒猜創建時間', `update_time` datetime DEFAULT NULL COMMENT '更則譽新時間', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶表'; 單點登錄表
用意是在多個業務系統中，用戶登錄一次就可以訪問所有相互信任的業務子系統，是聚合業務平台常用的解決方案。
CREATE TABLE `ms_user_sso` ( `user_id` int(11) NOT NULL COMMENT '用戶ID', `sso_id` varchar(32) NOT NULL COMMENT '單點信息編號ID', `sso_code` varchar(32) NOT NULL COMMENT '單點登錄碼,唯一核心標識', `log_ip` varchar(32) DEFAULT NULL COMMENT '登錄IP地址', `create_time` datetime DEFAULT NULL COMMENT '創建時間', `update_time` datetime DEFAULT NULL COMMENT '更新時間', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶單點登錄表'; 狀態管理表
系統用戶在使用時候可能出現多個狀態，例如賬戶凍結、密碼鎖定等，把狀態聚合到一起，可以更加方便的管理和驗證。
CREATE TABLE `ms_user_status` ( `user_id` int(11) NOT NULL COMMENT '用戶ID', `account_status` int(1) DEFAULT '1' COMMENT '賬戶狀態：0-凍結,1-未凍結', `real_name_status` int(1) DEFAULT '0' COMMENT '實名認證狀態：0-未實名,1-已實名', `pay_pass_status` int(1) DEFAULT '0' COMMENT '支付密碼是否設置：0-未設置,1-設置', `wallet_pass_status` int(1) DEFAULT '0' COMMENT '錢包密碼是否設置：0-未設置,1-設置', `wallet_status` int(1) DEFAULT '1' COMMENT '錢包是否凍結:0-凍結,1-未凍結', `email_status` int(1) DEFAULT '0' COMMENT '郵箱狀態:0-未激活,1-激活', `message_status` int(1) DEFAULT '1' COMMENT '簡訊提醒開啟：0-未開啟,1-開啟', `letter_status` int(1) DEFAULT '1' COMMENT '站內信提醒開啟：0-未開啟,1-開啟', `emailmsg_status` int(1) DEFAULT '0' COMMENT '郵件提醒開啟：0-未開啟,1-開啟', `create_time` datetime DEFAULT NULL COMMENT '創建時間', `update_time` datetime DEFAULT NULL COMMENT '更新時間', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶狀態表'; 支付賬戶表
用戶交易的核心表，存儲用戶相關的賬戶資金信息。
CREATE TABLE `ms_user_wallet` ( `wallet_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '錢包ID', `user_id` int(11) NOT NULL COMMENT '用戶ID', `wallet_pwd` varchar(32) DEFAULT NULL COMMENT '錢包密碼', `total_account` decimal(20,2) DEFAULT '0.00' COMMENT '賬戶總額', `usable_money` decimal(20,2) DEFAULT '0.00' COMMENT '可用余額', `freeze_money` decimal(20,2) DEFAULT '0.00' COMMENT '凍結金額', `freeze_time` datetime DEFAULT NULL COMMENT '凍結時間', `thaw_time` datetime DEFAULT NULL COMMENT '解凍時間', `create_time` datetime DEFAULT NULL COMMENT '創建時間', `update_time` datetime DEFAULT NULL COMMENT '更新時間', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`wallet_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶錢包'; 二、設計規范 1、涉及模塊
通過上面幾個表設計的案例，可以看到表設計關聯到資料庫的各個方面知識：數據類型，索引，編碼，存儲引擎等。表設計是一個很大的命題，不過也遵循一個基本規范：三範式。
2、三範式 基礎概念
一範式

表的列的具有原子性,不可再分解，即列的信息，不能分解,關系型資料庫MySQL、Oracle等自動的滿足。

二範式

每個事實的數據記錄只會出現一次, 不會冗餘, 通常設計一個主鍵來實現。

三範式

要求一個表中不包含已經存在於其它表的非主鍵信息，例如部門和員工的信息，員工表包含部門表的主鍵ID，則可以關聯獲取相關信息，沒必要在員工表保存相關信息。
優缺點對比
範式化設計

範式化結構設計通常更新快，因為冗餘數據較少，表結構輕巧，也更好的寫入內存中。但是查詢起來涉及到關聯，代價非常高，非常損耗查詢性能。

反範式化設計

所有的數據都在一張表中，避免關聯查詢，索引的有效性更高，但是數據的冗餘性極高。
建議結論
上述的兩種設計方式在實際開發中都是不存在的，在實際開發中都是混合使用。比如匯總統計，緩存數據，都會基於反範式化的設計。
三、欄位屬性
合適的欄位類型對於高性能來說非常重要，基本原則如下：簡單的類型佔用資源更少；在可以正確存儲數據的情況下，選最小的數據類型。
1、數據類型選擇 整數類型
TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，根據數據類型範圍合理選擇即可。
實數類型
FLOAT、DOUBLE、DECIMAL，建議資金貨幣相關類型使用高精度DECIMAL存儲，或者把數據成倍擴大為整數，採用BIGINT存儲，不過處理相對麻煩。
字元類型
CHAR、VARCHAR，長度不確定建議採用VARCHAR存儲，不過VARCHAR類型需要額外開銷記錄字元串長度。CHAR適合存儲短字元，或者定長字元串，例如MD5的加密結構。
時間類型
DATETIME、TIMESTAMP，DATETIME保存大范圍的值，精度秒。TIMESTAMP以時間戳的格式，范圍相對較小，效率也相對較高，所以通常情況建議使用。

MySQL的欄位類型有很多種，可以根據數據特性選擇合適的，這里只描述常見的幾種類型。
2、基礎用法操作 數據類型
修改欄位類型
ALTER TABLE ms_user_sso MODIFY state CHAR(1) DEFAULT '0' ; ALTER TABLE ms_user_sso MODIFY state INT(1) DEFAULT '1' COMMENT '狀態：0不可用,1可用';
修改名稱位置
ALTER TABLE ms_user_sso CHANGE log_ip login_ip VARCHAR(32) AFTER update_time ; 索引使用
索引類型：主鍵索引，普通索引，唯一索引，組合索引，全文索引。這里演示普通索引的操作。MySQL的核心模塊，後續詳說。

添加索引
ALTER TABLE ms_user_wallet ADD INDEX user_id_index(user_id) ; CREATE INDEX state_index ON ms_user_wallet(state) ;
查看索引
SHOW INDEX FROM ms_user_wallet;
刪除索引
DROP INDEX state_index ON ms_user_wallet ;
修改索引

不具有真正意義上的修改，可以把原有的索引刪除之後，再次添加索引。
外鍵關聯
用處：外鍵關聯的作用保證多個數據表的數據一致性和完整性，建表時先有主表，後有從表；刪除數據表，需要先刪從表，再刪主表。復雜場景不建議使用，實際開發中用的也不多。

添加外鍵
ALTER TABLE ms_user_wallet ADD CONSTRAINT user_id_out_key FOREIGN KEY(user_id) REFERENCES ms_user_center(id) ;
刪除外鍵
ALTER TABLE ms_user_wallet DROP FOREIGN KEY user_id_out_key ; 四、表結構管理 1、查看結構 DESC ms_user_status ; SHOW CREATE TABLE ms_user_status ; 2、欄位結構 添加欄位 ALTER TABLE ms_user_status ADD `delete_time` datetime DEFAULT NULL COMMENT '刪除時間' ; 刪除欄位 ALTER TABLE ms_user_status DROP COLUMN delete_time ; 3、修改表名 ALTER TABLE ms_user_center RENAME ms_user_info ; 4、存儲引擎 存儲引擎 SELECT VERSION() ; SHOW ENGINES ;
MySQL 5.6 支持的存儲引擎有InnoDB、MyISAM、Memory、Archive、CSV、BLACKHOLE等。一般默認使用InnoDB，支持事務管理。該模塊MySQL核心，後續詳解。
修改引擎
數據量大的場景下，存儲引擎修改是一個難度極大的操作，容易會導致表的特性變動，引起各種後續反應，後續會詳說。
ALTER TABLE ms_user_sso ENGINE = MyISAM ; 5、修改編碼
表字元集默認使用utf8，通用，無亂碼風險，漢字3位元組，英文1位元組，utf8mb4是utf8的超集，有存儲4位元組例如表情符號時使用。
查看編碼 SHOW VARIABLES LIKE 'character%'; 修改編碼 ALTER TABLE ms_user_sso DEFAULT CHARACTER SET utf8mb4; 五、數據管理 1、增刪改查
添加數據
INSERT INTO ms_user_sso ( user_id,sso_id,sso_code,create_time,update_time,login_ip,state ) VALUES ( '1','SSO7637267','SSO78631273612', '2019-12-24 11:56:57','2019-12-24 11:57:01','127.0.0.1','1' );
更新數據
UPDATE ms_user_sso SET user_id = '1',sso_id = 'SSO20191224',sso_code = 'SSO20191224', create_time = '2019-11-24 11:56:57',update_time = '2019-11-24 11:57:01', login_ip = '127.0.0.1',state = '1' WHERE user_id = '1';
查詢數據

一般情況下都是禁止使用 select* 操作。
SELECT user_id,sso_id,sso_code,create_time,update_time,login_ip,state FROM ms_user_sso WHERE user_id = '1';
刪除數據
DELETE FROM ms_user_sso WHERE user_id = '2' ;
不帶where條件，就是刪除全部數據。原則上不允許該操作，優化篇會詳解。TRUNCATE TABLE也是清空表數據，但是佔用的資源相對較少。
2、數據安全 不可逆加密
這類加密演算法，多用來做數據驗證操作，比如常見的密碼驗證。
SELECT MD5('cicada')='' ; SELECT SHA('cicada')=''; SELECT PASSWORD('smile')='*' ; 可逆加密
安全性要求高的系統，需要做三級等保，對數據的安全性極高，數據在存儲時必須加密入庫，取出時候需要解密，這些就需要可逆加密。
SELECT DECODE(ENCODE('123456','key_salt'),'key_salt') ; SELECT AES_DECRYPT(AES_ENCRYPT('cicada','salt123'),'salt123');
上述數據安全的管理，也可以基於應用系統的服務(代碼)層進行處理，相對專業的流程是從數據生成源頭處理，規避數據傳遞過程泄露，造成不必要的風險。

4. 說明在設計資料庫表時你是如何考慮的

資料庫是整個軟體應用的根基，是軟體設計的起點，它起著決定性的質變作用，因此我們必須對資料庫設計高度重視起來，培養設計良好資料庫的習慣，是一個優秀的軟體設計師所必須具備的基本素質條件！ 那麼我們要做到什麼程度才是對的呢？下面就說說資料庫設計的原則： （1）、資料庫設計最起碼要佔用整個項目開發的40%以上的時間

資料庫是需求的直觀反應和表現，因此設計時必須要切實符合用戶的需求，要多次與用戶溝通交流來細化需求，將需求中的要求和每一次的變化都要一一體現在資料庫的設計當中。如果需求不明確，就要分析不確定的因素，設計表時就要事先預留出可變通的欄位，正所謂「有備無患」。 （2）、資料庫設計不僅僅停留於頁面demo的表面 頁面內容所需要的欄位，在資料庫設計中只是一部分，還有系統運轉、模塊交互、中轉數據、表之間的聯系等等所需要的欄位，因此資料庫設計絕對不是簡單的基本數據存儲，還有邏輯數據存儲。 （3）、資料庫設計完成後，項目80%的設計開發在你腦海中就已經完成了 每個欄位的設計都是有他必要的意義的，你在設計每一個欄位的同時，就應該已經想清楚程序中如何去運用這些欄位，多張表的聯系在程序中是如何體現的。換句話說，你完成資料庫設計後，程序中所有的實現思路和實現方式在你的腦海中就已經考慮過了。如果達不到這種程度，那當進入編碼階段後，才發現要運用的技術或實現的方式資料庫無法支持，這時再改動資料庫就會很麻煩，會造成一系列不可預測的問題。 （4）、資料庫設計時就要考慮到效率和優化問題 一開始就要分析哪些表會存儲較多的數據量，對於數據量較大的表的設計往往是粗粒度的，也會冗餘一些必要的欄位，已達到盡量用最少的表、最弱的表關系去存儲海量的數據。並且在設計表時，一般都會對主鍵建立聚集索引，含有大數據量的表更是要建立索引以提供查詢性能。對於含有計算、數據交互、統計這類需求時，還要考慮是否有必要採用存儲過程。 （5）、添加必要的（冗餘）欄位 像「創建時間」、「修改時間」、「備注」、「操作用戶IP」和一些用於其他需求（如統計）的欄位等，在每張表中必須都要有，不是說只有系統中用到的數據才會存到資料庫中，一些冗餘欄位是為了便於日後維護、分析、拓展而添加的，這點是非常重要的，比如黑客攻擊，篡改了數據，我們便就可以根據修改時間和操作用戶IP來查找定位。 （6）、設計合理的表關聯 若多張表之間的關系復雜，建議採用第三張映射表來關聯維護兩張表之間的關系，以降低表之間的直接耦合度。若多張表涉及到大數據量的問題，表結構盡量簡單，關聯也要盡可能避免。 （7）、設計表時不加主外鍵等約束性關聯，系統編碼階段完成後再添加約束性關聯 這樣做的目的是有利於團隊並行開發，減少編碼時所遇到的問題，表之間的關系靠程序來控制。編碼完成後再加關聯並進行測試。不過也有一些公司的做法是乾脆就不加表關聯。 （8）、選擇合適的主鍵生成策略

5. 資料庫表的設計

臘橋悔1、若是一對多或多對一的對象存到資料庫表，原則上應該先觀察對象的基本屬性，然後設計一個數據表保存此對象的輪正基本數據，並在數量關系多的一方，加外鍵描述數據之間的關系；

2、若是多對多對象的資料庫表，原則上也是觀察該對象的基本屬性，然後設計一個表來保存此對象的基本數據，且需要加一個中間表來描述數據的關系；

3、若是一對一的消歲對象的資料庫設計， 除了上述操作，還因為一對一的對象有主從關系，因此可加入自連接表進行設計。

6. 資料庫表結構設計

1.典型地質遺跡基本概況表

包括地理位置、園區范圍、自然條件等組成(表6-2)。

表6-2 基本概版況(JBGK.MDB)資料庫結構表

數據項說明:

地質權公園編號:前3位國別代碼，按行政區劃代碼(GB/T2260－98)填寫，後3位地質遺跡點的順序號。當公園范圍較大，跨國界時，其編號以主景區所在的區域為准進行編號，後6位為順序號，保證地質遺跡編號的唯一性。

地質遺跡分類:為適應現階段地質遺跡的調查，地質公園建設和發展規劃、科學普及的開展，以系統地球科學理論為指導，趙汀(2009)提出了顯性地質遺跡的概念並建立了學科分類系統，並在此基礎上完成了中國國家地質公園地質遺跡分類。

2.景區、景點數據(表6-3，表6-4)

表6-3 景區表結構(JQ.MDB)表

表6-4 景點表結構(JD.MDB)表

景區和景點數據關系(表6-5)為一對多關系。即，一個景區至少有一處以上的景點，任意一個景點只能屬於某一個景區。

7. 資料庫進階：循序漸進講解數據表的十二個設計原則

數據表的設計原則:

( )不應針對整個系統進行資料庫設計 而應該根據系統架構中的組件劃分 針對每個組件所處理的業務進行組件單元的資料庫設計;不同組件間所對應的資料庫表之間的關聯應盡可能減少 如果不同組件間的表需要外鍵關聯也盡量不要創建外鍵關聯 而只是記錄關聯表的一個主鍵 確保組件對應的表之間的獨立性 為系統或表結構的重構提供可能性

( )採用領域模型驅動的方式和自頂向下的思路進行資料庫設計 首先分析系統業務 根據職責定義對象 對象要符合封裝的特性 確保與職責相關的數據項被定義在一個對象之內 這些數據項能夠完整描述該職責 不會出現職責描述缺失 並且一個對象有且只有一項職責 如果一個對象要負責兩個或兩個以上的職責 應進行分拆

( )根據建立的領域模型進行資料庫表的映射 此時應參考資料庫設計第二範式 一個表中的所有非關鍵字屬性都依賴於整個關鍵字 關鍵字可以是一個屬性 也可以是多個屬性的集合 不論那種方式 都應確保關鍵字能夠保證唯一性 在確定關鍵字時 應保證關鍵字不會參與業務且不會出現更新異常 這時 最優解決方案為採用一個自增數值型屬性或一個隨機字元串作為表的關鍵字

( )由於第一點所述的領域模型驅動的方式設計資料庫表結構 領域模型中的每一個對象只有一項職責 所以對象中的數據項不存在傳遞依賴 所以 這種思路的資料庫表結構設計從一開始即滿足第三範式 一個表應滿足第二範式 且屬性間不存在傳遞依賴

( )同樣 由於對象職責的單一性以及對象之間的關系反映的是業務邏輯之間的關系 所以在領域模型中的對象存在主對象和從對象之分 從對象是從 N或困飢N N的角度進一步主對象的業務邏輯 所以從對象及對象關系映射為的表及表關聯關系不存在刪除和插入異常

( )在映射後得出的資料庫表結構中 應再根據第四範式進行進一步修改 確保不存在多值依賴 這時 應根據反向工程的思路反饋給領域模型 如果表結構中存在多值依賴 則證明領域模型中的對象具有至少兩個以上的職責 應根據返李第一條進行設計修正 第四範式 一個表如果滿足BCNF 不應存在多值依賴

( )在經過分析後確認所有的表都滿足二 三 四範式的情況下 表和表之間的關聯盡量採用弱關聯以便於對表欄位和表結構的調整和重構 並且 我認為資料庫中的表是用來持久化一個對象實例在特定時間及特定條件下的狀態的 只是一個存儲介質 所以 表和表之間也不應用強關聯來表述業務(數據間的一致性) 這一職責應由系統的邏輯層來保證 這種方式也確保了系統對於不正確數據(臟數據)的兼容性 當然 從整個系統的角度來說我們還是要盡最大努力確保系統不會產生臟數據 單從另一個角度來說 臟數據的產生在一定程度上也是不可避免的 我們也要保證系統對這種情況的容錯性 這是一個折中的方案

( )應針對所有表的主鍵和外鍵建立索引 有針對性的(針對一些大漏尺遲數據量和常用檢索方式)建立組合屬性的索引 提高檢索效率 雖然建立索引會消耗部分系統資源 但比較起在檢索時搜索整張表中的數據尤其時表中的數據量較大時所帶來的性能影響 以及無索引時的排序操作所帶來的性能影響 這種方式仍然是值得提倡的

( )盡量少採用存儲過程 目前已經有很多技術可以替代存儲過程的功能如 對象/關系映射 等 將數據一致性的保證放在資料庫中 無論對於版本控制 開發和部署 以及資料庫的遷移都會帶來很大的影響 但不可否認 存儲過程具有性能上的優勢 所以 當系統可使用的硬體不會得到提升而性能又是非常重要的質量屬性時 可經過平衡考慮選用存儲過程

( )當處理表間的關聯約束所付出的代價(常常是使用性上的代價)超過了保證不會出現修改 刪除 更改異常所付出的代價 並且數據冗餘也不是主要的問題時 表設計可以不符合四個範式 四個範式確保了不會出現異常 但也可能由此導致過於純潔的設計 使得表結構難於使用 所以在設計時需要進行綜合判斷 但首先確保符合四個範式 然後再進行精化修正是剛剛進入資料庫設計領域時可以採用的最好辦法

( )設計出的表要具有較好的使用性 主要體現在查詢時是否需要關聯多張表且還需使用復雜的SQL技巧

8. 數據表設計考慮哪些問題

OK我來說幾句 下面是資料庫設計過程中我們要注意的問題，和要遵循的原則1. 原始單據和實體的間關系
可以是對、對多、多對多關系在般情況下它們是對關系:即張原始單據對應且只對應個實體在特殊情況下它
們可能是對多或多對關系即張原始單證對應多個實體或多張原始單證對應個實體這里實體可以理解為基本表明
確這種對應關系後對我們設計錄入界面大有好處
〖例1〗:份員工履歷資料在人力資源信息系統中就對應 3個基本表:員工基本情況表、社會關系表、工作簡
歷表這就是「張原始單證對應多個實體」典型例子
2. 主鍵和外鍵
般而言個實體不能既無主鍵又無外鍵在E—R 圖中, 處於葉子部位實體, 可以定義主鍵也可以不定義主鍵(它
無子孫), 但必須要有外鍵(它有父親)
主鍵和外鍵設計在全局資料庫設計中佔有重要地位當全局資料庫設計完成以後有個美國資料庫設計專家說
:「鍵到處都是鍵除了鍵的外什麼也沒有」這就是他資料庫設計經驗的談也反映了他對信息系統核心(數據模型
)高度抽象思想:主鍵是實體高度抽象主鍵和外鍵配對表示實體的間連接
3. 基本表性質
基本表和中間表、臨時表區別它具有如下 4個特性:
(1) 原子性基本表中欄位是不可再分解
(2) 原始性基本表中記錄是原始數據(基礎數據)記錄
(3) 演繹性由基本表和代碼表中數據可以派生出所有輸出數據
(4) 穩定性基本表結構是相對穩定表中記錄是要長期保存
理解基本表性質後在設計資料庫時就能將基本表和中間表、臨時表區分開來
4. 範式標准
基本表及其欄位的間關系, 應盡量滿足第 3範式但是滿足第 3範式資料庫設計往往不是最好設計為了提高數
據庫運行效率常常需要降低範式標准:適當增加冗餘達到以空間換時間目
〖例2〗:有張存放商品基本表如表1所示「金額」這個欄位存在表明該表設計不滿足第 3範式「金額」可以
由「單價」乘以「數量」得到介紹說明「金額」是冗餘欄位但是增加「金額」這個冗餘欄位可以提高查詢統計
速度這就是以空間換時間作法
在Rose 2002中規定列有兩種類型:數據列和計算列「金額」這樣列被稱為「計算列」而「單價」和「數量
」這樣列被稱為「數據列」
表1 商品表表結構
商品名稱 商品型號 單價 數量 金額
電視機 29吋 2,500 40 100,000
5. 通俗地理解 3個範式
通俗地理解 3個範式對於資料庫設計大有好處在資料庫設計中為了更好地應用 3個範式就必須通俗地理 最後說一下 如果項目的表在500個左右的話 數據可以有些冗餘的 這樣可以大大的提高程序的運行效率如果這個項目要有很強的擴展性 請嚴格遵守 第三範式 3NF 其實理論上這么講，在正正開發中我們還是要根據實際情況來取捨的祝你好運！