❶ 資料庫表結構設計，常見的資料庫管理系統
一、數據場景 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');
上述數據安全的管理，也可以基於應用系統的服務(代碼)層進行處理，相對專業的流程是從數據生成源頭處理，規避數據傳遞過程泄露，造成不必要的風險。
❷ 求一篇基於web的資料庫設計社會實踐調查報告
《基於web的資料庫設計實踐》
The Database Design Based On WEB Used In Remote Concurrent Design
Abstract: the paper analyses the database characteristics used in the remote concurrent proct design system based on Internet, deeply researches the database structure, interface and the method of the data safety.
Keywords: Internet, remote concurrent design, database based on Web
近年來，隨著Web技術的蓬勃發展，人們已不滿足於只在瀏覽器上獲取靜態的信息，想要通過它發表意見、查詢數據。隨著電子商務的普及人們開始參與一些網路商務活動，這就迫切需要實現Web與資料庫的互連[1]。產品異地並行設計對數據的要求有一定的特殊性，主要有（1）產品數據多種多樣。產品設計，特別是機械產品設計常常是大型而又復雜，在異地通過不同的設計小組，按不同的分工設計同一產品，所要管理和通訊的數據類型隨著分工的不同而有不同的表現形式，如常規的數字組成的數據集，以圖形、圖象形式表達的產品模型數據，以文字形式描述設計的文檔，還有圖表、公式等形式，復雜多樣。（2）產品數據交換頻繁，流量大。產品設計是一個協同工作的創造性集體智慧凝聚的過程，要使設計順利進行，分布在異地的不同設計小組之間就要經常性地進行數據交換，並且有些形式表達的產品數據是較大的文件。（3）產品數據的一致性要求高。分工合作的不同設計小組之間的設計任務是彼此關聯，互相依賴的。如果其中一個數據改變了，相關聯的數據必須跟著改變，在Web資料庫設計時必須考慮數據的一致性問題。（4）產品數據的並發性訪問頻繁。由於異地產品設計的特殊屬性，數據的並發性訪問非常頻繁。所以，進行基於Internet的產品異地並行設計的Web資料庫設計與一般的電子商務不同，要充分考慮以上屬性。本文結合我們近期開發的機械產品異地並行設計系統（RCDS, Remote Concurrent Design System），綜合比較了多種當今流行的網路數據存取技術，設計出可靠安全的資料庫系統。
1 Web資料庫連接方案
1.1資料庫連接方案選擇
RDO、DAO和ADO是比較常見的Web資料庫訪問技術。
DAO (Data Access Objects) 數據訪問對象是第一個面向對象的介面，它含有 Microsoft Jet 資料庫引擎（由 Microsoft Access 所使用），並允許 Visual Basic 開發者通過 ODBC 象連接到其他資料庫一樣，直接訪問到 Access 表。DAO 最適用於單系統應用程序或小范圍本地分布使用，對大范圍的異地並行設計顯得功能不夠強大。
RDO (Remote Data Objects) 遠程數據對象是一個到 ODBC 的、面向對象的數據訪問介面，它同易於使用的 DAO style組合在一起，提供了一個介面，形式上展示出所有 ODBC 的底層功能和靈活性。RDO 在訪問 Jet 或 ISAM 資料庫方面有一定的限制，而且它只能通過現存的 ODBC 驅動程序來訪問關系資料庫。但是，RDO 已被證明是許多 SQL Server、Oracle
以及其他大型關系資料庫開發者經常選用的最佳介面。RDO 提供了用來訪問存儲過程和復雜結果集的更多和更復雜的對象、屬性，以及方法。對異地並行設計Web資料庫來說也不是十分理想。
ADO（ActiveX Data Objects）為ActiveX組件中資料庫訪問組件，ASP就是通過它實現對資料庫的訪問。ADO 是 DAO、RDO 的後繼產物。ADO 2.0在功能上與 RDO 更相似，而且一般來說，在這兩種模型之間有一種相似的映射關系。ADO 「擴展」了 DAO 和 RDO 所使用的對象模型，這意味著它包含較少的對象、更多的屬性、方法（和參數），以及事件。例如，ADO 沒有與 rdoEngine 和 rdoEnvironment 對象相等同的對象，可以包含 ODBC 驅動程序管理器和 hEnv 介面。盡管事實上介面可能是通過 ODBC OLE DB 服務提供程序實現的，但目前也不能從 ADO 中創建 ODBC 數據源。ADO 是為 Microsoft最新和最強大的數據訪問範例 OLE DB 而設計的，是一個便於使用的應用程序層介面。OLE DB 為任何數據源提供了高性能的訪問，這些數據源包括關系和非關系資料庫、電子郵件和文件系統、文本和圖形、自定義業務對象等等。ADO 在關鍵的 Internet 方案中使用最少的網路流量，並且在前端和數據源之間使用最少的層數，所有這些都是為了提供輕量、高性能的介面。同時 ADO 使用了與 DAO和 RDO相似的約定和特性，簡化的語義使它更易於學習。
ADO最早是在IIS中引入的，主要用於ASP，用ADO可以使伺服器端的腳本通過ODBC存取和操縱資料庫伺服器的數據。使用ADO的對象可以建立和管理資料庫的連接，從資料庫伺服器請求和獲取數據，執行更新、刪除、添加數據、獲取ODBC的錯誤信息等。ADO是ASP方案中最具吸引力的資料庫連接控制項，它為用戶提供了連接任何兼容ODBC的資料庫以及創建全功能資料庫應用程序的能力。
ADO具有簡單易用、高速、佔用資源少等的優點。不同於DAO和RDO，ADO有著更高的執行效率。ADO 對象模型如圖1a所示。每個 Connection、Command、Recordset 和 Field 對象都有 Properties 集合，如圖1b所示。
a) b)
圖1 ADO對象模型及屬性
應該說，ADO是微軟的下一代資料庫連接技術，用來全面取代RDO和DAO的數據訪問工具。從發展趨勢來看，ADO今後將逐步替代老的DAO特別是RDO數據訪問介面，成為新的遠程數據訪問方法。所以，選擇ADO作為產品異地並行設計的Web資料庫介面技術是合適的。
1.2 ADO應用分析
ADO 並不是自動和現存的數據訪問應用程序代碼兼容的。當 ADO 封裝 DAO 和 RDO 的功能性的時候，必須將許多語言要素轉換為 ADO 語法。在某些情況下，這將意味著要對現存代碼的某些功能做一個簡單轉換。在其他情況下，最佳的做法可能是用 ADO 的新功能重寫該應用程序。
包含在 DAO 和 RDO 模型中的許多功能被合並為單個對象，這樣就生成了一個簡單得多的對象模型。然而，由於這個原因，起初可能會覺得找到合適的 ADO 對象、集合、屬性、方法，或事件非常困難。與 DAO 和 RDO不同的是，盡管 ADO 對象是分層結構的，但在分層結構范圍之外也是可以創建的。同時，也應當注意，ADO 當前並不支持 DAO 的所有功能。ADO 主要包括 RDO 風格的功能性，以便和 OLE DB 數據源交互，另外還包括遠程和 DHTML 技術。
一般說來，在 ADO 的演化過程中，馬上把大多數 DAO 應用程序（except possibly是那些使用 ODBCDirect 的應用程序）移植到 ADO 上為時太早，因為當前的 ADO 並不支持數據定義 (DDL)、用戶、組等等。不過，如果只將 DAO 用於客戶—伺服器應用程序，並不依賴於 Jet 資料庫引擎或不使用 DDL，那麼就可能移植到 ADO。最終，Microsoft 將提供一個 ADO DDL 組件來幫助進行 DAO 到 ADO 的移植，並為 OLE DB 供應商提供一般的 DDL 支持。
在ASP中使用ADO技術來訪問Web資料庫，其應用前景是無可估量的。原理圖如下：
圖2 ADO在ASP程序中的應用
2 Web資料庫管理系統
常見的資料庫類型有面向對象的資料庫（OODB）和關系型資料庫。OODB對主流資料庫應用開發來說是相當新穎的，使用OODB使應用程序中的數據對象與現實世界中的對象一一對應，面向對象資料庫擴充了對象模型。一個常用的對象模型是由對象資料庫管理組（ODMG）開發出來，具有比傳統的關系資料庫更優越的性能，但畢竟在目前還是一種探索階段，暫時還未有相應的技術普及。
關系資料庫已經是資料庫體系的世界標准。當開發一個數據驅動應用程序時，大多數情況下用戶需要訪問網路（如Internet、Intranet等）上的數據信息，就RCDS就是建立在網路的信息通訊之上，是完全的客戶機/伺服器應用程序。
SQL Server是一個可縮放、高性能的關系型資料庫管理系統（RDBMS），它的設計是為了滿足分布式客戶/伺服器計算的需要，允許客戶應用程序使用幾個特定的工具和技術控制從伺服器檢索的數據。這些包括觸發器、存儲過程和規則的選項。因此，系統採用MS SQL Server7.0作為後台資料庫。
3 Web資料庫結構
數據模型通常有層次模型、網狀模型、關系模型及OO（面向對象）模型等。其中關系模型是建立在數學概念基礎之上的一種模型，由若干個關系框架組成的集合,它也是到目前為止最為成熟的一種資料庫類型。本文RCDS採用MS SQL Server作為後台資料庫，根據資料庫工具和資料庫特點，開發出一套可靠健壯的數據存儲方案。
整個資料庫共有AdminData、ChatNames、DesignUnits、Message、OnlineUnits、Procts、RqtTasks、RqtTaskUnits、RqtDesignUnits、ShareData、Tasks、TaskUnits和UploadFiles等表格。在建立數據模型的時候首先考慮是要避免重復數據，也就是建立規范化資料庫。規范化資料庫可以通過被稱為範式水平的指標來衡量，級別有第一範式、第二範式和第三範式，通常第三範式就是要達到的目標，因為它提供了數據冗餘和開發簡易性之間的最好折衷。
RCDS資料庫正是按照第三範式標准來設計的，它保證了模型的精簡和表格的緊湊性。而第三範式標准也最大發揮了關系資料庫的優勢，圖3是部分表格的視圖鏈接情況。
圖3 關系表格視圖
4.1 並發控制的處理
在多個用戶同時訪問一個資料庫時就產生並發問題，特別是在其中一些用戶對資料庫有添加或刪除修改等操作時，那麼其他所獲得的數據可能是一塌糊塗，甚至造成整個數據訪問的沖突、終止，從而使系統發生混亂以至崩潰。RCDS採用的解決辦法是鎖定技術，總體上分為共享鎖定和排它鎖定兩種類型（如圖4）。前者是指同時有幾個過程共享一個鎖定，比如一個用戶（或客戶）正在讀取一個數據，雖然在這之前他已經對該數據設置了鎖（LOCK），但其他用戶同樣可以（也只能是）讀取它。而排他鎖定一般應用於對數據進行修改或更新（包括添加刪除等）操作，即是用戶在修改一個數據之前設置了鎖定，在一定的時間里其他用戶是不能訪問到該數據的，只有等待鎖定解除（UNLOCK）才能進行訪問到它，當然在計算機處理的時候，其他的用戶一般是感覺不到有這個等待時間的。通過這樣的處理，就保證了數據的一致性。
a) 共享鎖定
b) 排它鎖定
圖4 安全鎖定類型
在ADO進行資料庫操作時，它的鎖定類型相對來說復雜一些。打開記錄集時，可以指定鎖定類型。鎖定類型決定了當不止一個用戶同時試圖改變一個記錄時，資料庫應如何處理。ADO中的鎖定主要有以下四種類型：
l AdLockReadOnly 指定你不能修改記錄集中的記錄
l AdLockPessimistic 指定在編輯一個記錄時，立即鎖定它
l AdLockOptimstic 指定只有調用記錄集的Update方法時，才鎖定記錄
l AdLockBatchOptimstic 指定記錄只能成批地更新
在預設情況下，記錄集使用只讀鎖定。要指定不同的鎖定類型，可以在打開記錄集時包含這些鎖定常量之一。部分代碼如下：
… …
Set MyConn=Sever.CreateObject(「ADODB.Connection」)
//定義資料庫連接MyConn
Set RS=Sever.CreateObject(「ADODB.RecordSet」)
//定義返回數據記錄集
MyConn.Open 「ByktDB.dsn」//建立應用程序與數據源的連接
RS.Open 「SELECT * FROM Mytable」, MyConn, adOpenDynamic， adLockPessimistic
//進行資料庫操作，並且設置鎖定
RS.Close
MyConn.Close
… …
4.2產品數據一致性處理
數據的安全因素除了前面所提到的並行控制之外，還要考慮事務處理。網路資料庫有其不同的地方，例如：假設某個時間有一個設計人員在你的站點上索取一些設計信息，有關的設計信息存儲在兩個表中。一個表用來保存該設計者的信息，另一個表包含了要索取的設計信息。該設計人員的信息已經輸入了第一個表中。但是，就在這時，發生了意外情況，一道閃電擊中了你的伺服器，使第二個表沒有被更新。在這種情況下，一個健壯的系統就必須保證最後的結果是兩個表都沒有被更新過。這時候事務處理就發揮了重要的功效。
使用事務處理，你可以防止第二個表沒有被更新而第一個表被更新的情況出現：當一組語句構成一個事務處理時，如果一個語句沒有執行成功，則所有的語句都不成功。不管是針對多個表，還是進行表內多個記錄的操作，它們所需要的安全保證是一樣的。事務處理的實現代碼如下：
… …
Set MyConn=Sever.CreateObject(「ADODB.Connection」)
MyConn.Open 「ByktDB.dsn」
MyConn.BeginTrans //事務處理開始
MyConn.Execute 「INSERT DataTable(Num) Values(『3628』)」
MyConn.Execute 「INSERT Shipping (Address) VALUES(『Paris,France』)」
MyConn.CommitTrans //事務處理結束
MyConn.Close
… …
在上面這段代碼中，用BeginTrans方法和CommitTrans方法來標記事務處理的開始和結束。在BeginTrans方法被調用之後，CommitTRans方法被調用之前，不管出現什麼錯誤，兩個表都不會被更新，在這個過程中所有處理的數據都保持了完全可靠的一致性。
❸ mysql workbench能做什麼
MySQL Workbench是一款專為MySQL設計的ER/資料庫建模工具。它有助於創建新的物理數據模型，並通過反向/正向工程和變更管理功能修改現有的MySQL資料庫。
MySQL Workbench - 建模和設計工具。
1、模型是大多數有效和高性能資料庫的核心。MySQL workbench具有允許開發人員和資料庫管理員可視化地創建物理資料庫設計模型的工具，這些模型可以使用正向工程輕松轉換為MySQL資料庫。
2、MySQL Workbench 支持在同一環境中創建多個模型。
3、它支持構成資料庫的所有對象，如表，視圖，存儲過程，觸發器等。
4、MySQL workbench有一個內置的模型驗證實用程序，可以報告可能在數據建模器中找到的任何問題。
5、它還允許使用不同的建模符號，並且可以使用LUA腳本語言進行擴展。
MySQL Workbench - SQL開發工具。
結構化查詢語言（SQL）允許我們操縱關系資料庫。SQL是所有關系資料庫的核心。
1、MySQLworkbench，內置SQL可視化編輯器。
2、Visual SQL編輯器允許開發人員針對MySQL伺服器資料庫構建，編輯和運行查詢。它具有查看數據和導出數據的實用程序。
3、其語法顏色高亮顯示器可幫助開發人員輕松編寫和調試SQL語句。
4、可以運行多個查詢，結果會自動顯示在不同的選項卡中。
5、查詢也會保存在歷史記錄面板中，以便以後檢索和運行。
MySQL Workbench - 管理工具。
伺服器管理在保護公司數據方面發揮著關鍵作用。有關伺服器管理的主要問題是用戶管理，伺服器配置，伺服器日誌等等。Workbench MySQL具有以下功能，可簡化MySQL伺服器管理的過程;
1、用戶管理- 用於管理用戶的可視化實用程序，允許資料庫管理員在需要時輕松添加新用戶並刪除現有用戶，授予和刪除許可權以及查看用戶配置文件。
2、伺服器配置- 允許對伺服器進行高級配置並進行微調以獲得最佳性能。
3、資料庫備份和恢復- 用於導出/導入MySQL轉儲文件的可視化工具。MySQL轉儲文件包含用於創建資料庫，表，視圖，存儲過程和數據插入的SQL腳本。
4、伺服器日誌- 用於查看MySQL伺服器日誌的可視化工具 日誌包括錯誤日誌，二進制日誌和InnodDB日誌。在伺服器上執行診斷時，這些日誌會派上用場。
(3)高性能資料庫設計擴展閱讀：
MySQL Workbench為資料庫管理員和開發人員提供了一整套可視化的資料庫操作環境，主要功能有資料庫設計與模型建立、SQL 開發（取代 MySQL Query Browser）、資料庫管理（取代 MySQL Administrator）。
MySQL Workbench 有兩個版本：
MySQL Workbench Community Edition（也叫 MySQL Workbench OSS，社區版），MySQL Workbench OSS 是在GPL證書下發布的開源社會版本。
MySQL Workbench Standard Edition（也叫 MySQL Workbench SE，商業版本），MySQL Workbench SE 是按年收費的商業版本。
❹ SQLserver資料庫有什麼特徵
（1）高性能設計，可充分利用WindowsNT的優勢。
（2）系統管理先進，支持Windows圖形化管理工具，支持本地和遠程的系統管理和配置。
（3）強壯的事務處理功能，採用各種方法保證數據的完整性。
（4）支持對稱多處理器結構、存儲過程、ODBC，並具有自主的SQL語言。 SQLServer以其內置的數據復制功能、強大的管理工具、與Internet的緊密集成和開放的系統結構為廣大的用戶、開發人員和系統集成商提供了一個出眾的資料庫平台。
❺ 怎樣設計高性能的資料庫
考察現有環境
在設計一個新資料庫時，你不但應該仔細研究業務需求而且還要考察現有的系統。大多數資料庫項目都不是從頭開始建立的；通常，機構內總會存在用來滿足特定需求的現有系統（可能沒有實現自動計算）。顯然，現有系統並不完美，否則你就不必再建立新系統了。但是對舊系統的研究可以讓你發現一些可能會忽略的細微問題。一般來說，考察現有系統對你絕對有好處。
定義標準的對象命名規范
一定要定義資料庫對象的命名規范。對資料庫表來說，從項目一開始就要確定表名是採用復數還是單數形式。此外還要給表的別名定義簡單規則（比方說，如果表名是一個單詞，別名就取單詞的前 4 個字母；如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成 4 個字母長的別名；如果表的名字由 3 個單片語成，你不妨從頭兩個單詞中各取一個然後從最後一個單詞中再取出兩個字母，結果還是組成 4 字母長的別名，其餘依次類推）對工作用表來說，表名可以加上前綴 WORK_ 後面附上採用該表的應用程序的名字。表內的列[欄位]要針對鍵採用一整套設計規則。比如，如果鍵是數字類型，你可以用 _N 作為後綴；如果是字元類型則可以採用 _C 後綴。對列[欄位]名應該採用標準的前綴和後綴。再如，假如你的表裡有好多「money」欄位，你不妨給每個列[欄位]增加一個 _M 後綴。還有，日期列[欄位]最好以 D_ 作為名字打頭。
檢查表名、報表名和查詢名之間的命名規范。你可能會很快就被這些不同的資料庫要素的名稱搞糊塗了。假如你堅持統一地命名這些資料庫的不同組成部分，至少你應該在這些對象名字的開頭用 Table、Query 或者 Report 等前綴加以區別。
如果採用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符號來標識對象（比如 tbl_Employees）。我在和 SQL Server 打交道的時候還用過 tbl 來索引表，但我用 sp_company （現在用 sp_feft_）標識存儲過程，因為在有的時候如果我發現了更好的處理辦法往往會保存好幾個拷貝。我在實現 SQL Server 2000 時用 udf_ （或者類似的標記）標識我編寫的函數。
工欲善其事, 必先利其器
採用理想的資料庫設計工具，比如：SyBase 公司的 PowerDesign，她支持 PB、VB、Delphe 等語言，通過 ODBC 可以連接市面上流行的 30 多個資料庫，包括 dBase、FoxPro、VFP、SQL Server 等，今後有機會我將著重介紹 PowerDesign 的使用。
獲取數據模式資源手冊
正在尋求示例模式的人可以閱讀《數據模式資源手冊》一書，該書由 Len Silverston、W. H. Inmon 和 Kent Graziano 編寫，是一本值得擁有的最佳數據建模圖書。該書包括的章節涵蓋多種數據領域，比如人員、機構和工作效能等。其他的你還可以參考相關書籍。
暢想未來，但不可忘了過去的教訓
我發現詢問用戶如何看待未來需求變化非常有用。這樣做可以達到兩個目的：首先，你可以清楚地了解應用設計在哪個地方應該更具靈活性以及如何避免性能瓶頸；其次，你知道發生事先沒有確定的需求變更時用戶將和你一樣感到吃驚。
一定要記住過去的經驗教訓！我們開發人員還應該通過分享自己的體會和經驗互相幫助。即使用戶認為他們再也不需要什麼支持了，我們也應該對他們進行這方面的教育，我們都曾經面臨過這樣的時刻「當初要是這么做了該多好..」。
在物理實踐之前進行邏輯設計
在深入物理設計之前要先進行邏輯設計。隨著大量的 CASE 工具不斷涌現出來，你的設計也可以達到相當高的邏輯水準，你通常可以從整體上更好地了解資料庫設計所需要的方方面面。
了解你的業務
在你百分百地確定系統從客戶角度滿足其需求之前不要在你的 ER（實體關系）模式中加入哪怕一個數據表（怎麼，你還沒有模式？那請你參看技巧 9）。了解你的企業業務可以在以後的開發階段節約大量的時間。一旦你明確了業務需求，你就可以自己做出許多決策了。
一旦你認為你已經明確了業務內容，你最好同客戶進行一次系統的交流。採用客戶的術語並且向他們解釋你所想到的和你所聽到的。同時還應該用可能、將會和必須等詞彙表達出系統的關系基數。這樣你就可以讓你的客戶糾正你自己的理解然後做好下一步的 ER 設計。
創建數據字典和 ER 圖表
一定要花點時間創建 ER 圖表和數據字典。其中至少應該包含每個欄位的數據類型和在每個表內的主外鍵。創建 ER 圖表和數據字典確實有點費時但對其他開發人員要了解整個設計卻是完全必要的。越早創建越能有助於避免今後面臨的可能混亂，從而可以讓任何了解資料庫的人都明確如何從資料庫中獲得數據。
有一份諸如 ER 圖表等最新文檔其重要性如何強調都不過分，這對表明表之間關系很有用，而數據字典則說明了每個欄位的用途以及任何可能存在的別名。對 SQL 表達式的文檔化來說這是完全必要的。
創建模式
一張圖表勝過千言萬語：開發人員不僅要閱讀和實現它，而且還要用它來幫助自己和用戶對話。模式有助於提高協作效能，這樣在先期的資料庫設計中幾乎不可能出現大的問題。模式不必弄的很復雜；甚至可以簡單到手寫在一張紙上就可以了。只是要保證其上的邏輯關系今後能產生效益。
從輸入輸出下手
在定義資料庫表和欄位需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和欄位。舉個簡單的例子：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼欄位而不要把郵政編碼糅進地址欄位里。
報表技巧
要了解用戶通常是如何報告數據的：批處理還是在線提交報表？時間間隔是每天、每周、每月、每個季度還是每年？如果需要的話還可以考慮創建總結表。系統生成的主鍵在報表中很難管理。用戶在具有系統生成主鍵的表內用副鍵進行檢索往往會返回許多重復數據。這樣的檢索性能比較低而且容易引起混亂。
理解客戶需求
看起來這應該是顯而易見的事，但需求就是來自客戶（這里要從內部和外部客戶的角度考慮）。不要依賴用戶寫下來的需求，真正的需求在客戶的腦袋裡。你要讓客戶解釋其需求，而且隨著開發的繼續，還要經常詢問客戶保證其需求仍然在開發的目的之中。一個不變的真理是：「只有我看見了我才知道我想要的是什麼」必然會導致大量的返工，因為資料庫沒有達到客戶從來沒有寫下來的需求標准。而更糟的是你對他們需求的解釋只屬於你自己，而且可能是完全錯誤的。
其餘四部分待續...