Ⅰ 簡述文件系統與資料庫系統有什麼區別和聯系
文件系統和資料庫系統之間的區別。
（1）
文件系統用文件將數據長期保存在外存上，資料庫系統用資料庫統一存儲數據；
（2）
文件系統中的程序和數據有一定的聯系，資料庫系統中的程序和數據分離；
（3）
文件系統用操作系統中的存取方法對數據進行管理，資料庫系統用DBMS統一管理和控制數據；
（4）
文件系統實現以文件為單位的數據共享，資料庫系統實現以記錄和欄位為單位的數據共享。
文件系統和資料庫系統之間的聯系：
（1）
均為數據組織的管理技術；
（2）
均由數據管理軟體管理數據，程序與數據之間用存取方法進行轉換；
（3）
資料庫系統是在文件系統的基礎上發展而來的。
Ⅱ 關於資料庫系統對比文件系統的優點有哪些
關於資料庫系統對比文件系統的優點有：
1、提高了數據的共享性，使多個用戶能夠同時訪問資料庫中的數據。
2、提高了數據的一致性和完整性。
3、提供數據與應用程序的獨立性。
資料庫技術的主要目的是有效地管理和存取大量的數據資源，包括：提高數據的共享性，使多個用戶能夠同時訪問資料庫中的數據；減小數據的冗餘，以提高數據的一致性和完整性；提供數據與應用程序的獨立性，從而減少應用程序的開發和維護代價。對於數據的冗餘是不能消除的，只能減小。任何的資料庫中都存在著數據冗餘的現象，但這些都應該是合理的數據冗餘。
Ⅲ 試述文件系統與資料庫系統的區別與聯系
一、文件系統與資料庫系統的區別：
1、數據存儲方法不同：
文件系統使用文件將數據長期保存在外部內存中，資料庫系統將數據與資料庫統一存儲，程序與文件系統中的數據有一定的連接，資料庫系統中的程序與數據分離.
2、數據管理的方法不同：
文件系統採用操作系統中的訪問方法對數據進行管理，資料庫系統使用DBMS統一管理和控制數據。
3、數據共享程度不同：
文件系統實現需要基於文件的數據共享，資料庫系統實現的記錄和欄位作為數據共享的單位。文件系統面向某一應用程序，共享性差，冗餘度大，數據獨立性差。
4、資料庫獨立性不同：
資料庫系統面向現實世界，共享性高，冗餘度小，具有較高的物理獨立性和一定的邏輯獨立性。
二、文件系統與資料庫系統的聯系：
1、文件系統於資料庫系統都是計算機系統中管理資料庫的軟體。解析文件系統是操作系統的重要組成部分。
2、而DBMS是獨立於操作系統的軟體，文件管理都是DBMS在操作系統的基礎上實現的。資料庫系統的組織和存儲是通過操作系統中的文件系統來實現的。
3、資料庫系統主要管理資料庫的存儲、事務以及對資料庫的操作。文件系統是操作系統管理文件和存儲空間的子系統，主要是分配文件所佔的簇、盤塊或者建立FAT、管理空間空間等。
4、通常，資料庫系統會調用文件系統來管理自己的數據文件，但某些資料庫系統能夠自行管理數據文件，即使在裸機上也是如此。文件系統是操作系統所必需的，資料庫系統只需要用於資料庫管理和應用。
(3)文件系統查詢與資料庫查詢哪個快擴展閱讀：
文件系統和資料庫系統的用途：
文件系統將數據組織到單獨的數據文件中，實現了記錄中的結構，但整體是非結構化的，而資料庫系統實現了整個數據的結構，這是資料庫的主要特徵之一，也是資料庫的主要特徵之一。資料庫系統和文件系統之間的本質區別。在文件系統中，數據冗餘大。浪費了存儲空間。容易造成數據不一致。
資料庫系統中，數據是面向整個系統，數據可以被多個用戶、多個應用共享使用，減少了數據冗餘。
文件系統中的文件為特定應用程序提供服務，當您要修改數據的邏輯結構時，必須修改應用程序，修改文件結構的定義，數據和程序之間缺乏獨立性，並且在通過DBMS的兩級圖像實現了數據的物理獨立性和邏輯獨立性。將數據的定義與程序分開，減少了應用程序的維護和修改。
文件系統和資料庫系統均可以長期保存數據，由數據管理軟體管理數據，資料庫系統是在文件系統基礎上發展而來。
參考資料來源：網路-資料庫系統
參考資料來源：網路-文件系統
Ⅳ 磁碟讀寫和資料庫讀寫哪個效率更高
假定在程序效率和關鍵過程相當且不計入緩存等措施的條件下，讀寫任何類型的數據都沒有直接操作文件來的快，不論MSYQL過程如何，最後都要到磁碟上去讀這個「文件」（記錄存儲區等效），所以當然這一切的前提是只讀 內容，無關任何排序或查找操作。
動態網站一般都是用資料庫來存儲信息，如果信息的及時性要求不高 可以加入緩存來減少頻繁讀寫資料庫。
兩種方式一般都支持，但是繞過操作系統直接操作磁碟的性能較高，而且安全性也較高，資料庫系中的磁碟性能一直都是瓶頸，大型資料庫一般基於unix
系統，當然win下也有，不常用應為win的不可靠性，unix下，用的是裸設備raw設備，就是沒有加工過的設備（unix下的磁碟分區屬於特殊設備，
以文件形式統一管理），由dbms直接管理，不通過操作系統，效率很高，可靠性也高，因為磁碟，cache和內存都是自己管理的，大型資料庫系統
db2，oracal，informix（不太流行了），mssql算不上大型資料庫系統。
1、直接讀文件相比資料庫查詢效率更勝一籌，而且文中還沒算上連接和斷開的時間。
2、一次讀取的內容越大，直接讀文件的優勢會越明
顯（讀文件時間都是小幅增長，這跟文件存儲的連續性和簇大小等有關系），這個結果恰恰跟書生預料的相反，說明MYSQL對更大文件讀取可能又附加了某些操
作（兩次時間增長了近30%），如果只是單純的賦值轉換應該是差異偏小才對。
3、寫文件和INSERT幾乎不用測試就可以推測出，資料庫效率只會更差。
4、很小的配置文件如果不需要使用到資料庫特性，更加適合放到獨立文件里存取，無需單獨創建數據表或記錄，很大的文件比如圖片、音樂等採用文件存儲更為方便，只把路徑或縮略圖等索引信息放到資料庫里更合理一些。
5、PHP上如果只是讀文件，file_get_contents比fopen、fclose更有效率，不包括判斷存在這個函數時間會少3秒左右。
6、fetch_row和fetch_object應該是從fetch_array轉換而來的，書生沒看過PHP的源碼，單從執行上就可以說明fetch_array效率更高，這跟網上的說法似乎相反。
磁碟讀寫與資料庫的關系：
一 磁碟物理結構
(1) 碟片：硬碟的盤體由多個碟片疊在一起構成。
在硬碟出廠時，由硬碟生產商完成了低級格式化(物理格式化)，作用是將空白的碟片(Platter)劃分為一個個同圓心、不同半徑的磁軌
(Track)，還將磁軌劃分為若干個扇區(Sector)，每個扇區可存儲128×2的N次方（N=0.1.2.3）位元組信息，默認每個扇區的大小為
512位元組。通常使用者無需再進行低級格式化操作。
(2) 磁頭：每張碟片的正反兩面各有一個磁頭。
(3) 主軸：所有磁片都由主軸電機帶動旋轉。
(4) 控制集成電路板：復雜！上面還有ROM（內有軟體系統）、Cache等。
二 磁碟如何完成單次IO操作
(1) 尋道
當控制器對磁碟發出一個IO操作命令的時候，磁碟的驅動臂(Actuator
Arm)帶動磁頭(Head)離開著陸區(Landing
Zone，位於內圈沒有數據的區域)，移動到要操作的初始數據塊所在的磁軌(Track)的正上方，這個過程被稱為尋道(Seeking)，對應消耗的時
間被稱為尋道時間(Seek Time)；
(2) 旋轉延遲
找到對應磁軌還不能馬上讀取數據，這時候磁頭要等到磁碟碟片(Platter)旋轉到初始數據塊所在的扇區(Sector)落在讀寫磁頭正下方之後才能開始讀取數據，在這個等待碟片旋轉到可操作扇區的過程中消耗的時間稱為旋轉延時(Rotational Delay)；
(3) 數據傳送
接下來就隨著碟片的旋轉，磁頭不斷的讀/寫相應的數據塊，直到完成這次IO所需要操作的全部數據，這個過程稱為數據傳送(Data Transfer)，對應的時間稱為傳送時間(Transfer Time)。完成這三個步驟之後單次IO操作也就完成了。
根據磁碟單次IO操作的過程，可以發現：
單次IO時間 = 尋道時間 + 旋轉延遲 + 傳送時間
進而推算IOPS(IO per second)的公式為：
IOPS = 1000ms/單次IO時間
三 磁碟IOPS計算
不同磁碟，它的尋道時間，旋轉延遲，數據傳送所需的時間各是多少？
1. 尋道時間
考慮到被讀寫的數據可能在磁碟的任意一個磁軌，既有可能在磁碟的最內圈（尋道時間最短），也可能在磁碟的最外圈（尋道時間最長），所以在計算中我們只考慮平均尋道時間。
在購買磁碟時，該參數都有標明，目前的SATA/SAS磁碟，按轉速不同，尋道時間不同，不過通常都在10ms以下：
3. 傳送時間2. 旋轉延時
和尋道一樣，當磁頭定位到磁軌之後有可能正好在要讀寫扇區之上，這時候是不需要額外的延時就可以立刻讀寫到數據，但是最壞的情況確實要磁碟旋轉整整
一圈之後磁頭才能讀取到數據，所以這里也考慮的是平均旋轉延時，對於15000rpm的磁碟就是(60s/15000)*(1/2) = 2ms。
(1) 磁碟傳輸速率
磁碟傳輸速率分兩種：內部傳輸速率(Internal Transfer Rate)，外部傳輸速率(External Transfer Rate)。
內部傳輸速率(Internal Transfer Rate)，是指磁頭與硬碟緩存之間的數據傳輸速率，簡單的說就是硬碟磁頭將數據從碟片上讀取出來，然後存儲在緩存內的速度。
理想的內部傳輸速率不存在尋道，旋轉延時，就一直在同一個磁軌上讀數據並傳到緩存，顯然這是不可能的，因為單個磁軌的存儲空間是有限的；
實際的內部傳輸速率包含了尋道和旋轉延時，目前家用磁碟，穩定的內部傳輸速率一般在30MB/s到45MB/s之間(伺服器磁碟，應該會更高)。
外部傳輸速率(External Transfer Rate)，是指硬碟緩存和系統匯流排之間的數據傳輸速率，也就是計算機通過硬碟介面從緩存中將數據讀出交給相應的硬碟控制器的速率。
硬碟廠商在硬碟參數中，通常也會給出一個最大傳輸速率，比如現在SATA3.0的6Gbit/s，換算一下就是6*1024/8，768MB/s，通常指的是硬碟介面對外的最大傳輸速率，當然實際使用中是達不到這個值的。
這里計算IOPS，保守選擇實際內部傳輸速率，以40M/s為例。
(2) 單次IO操作的大小
有了傳送速率，還要知道單次IO操作的大小(IO Chunk Size)，才可以算出單次IO的傳送時間。那麼磁碟單次IO的大小是多少？答案是：不確定。
操作系統為了提高 IO的性能而引入了文件系統緩存(File System Cache)，系統會根據請求數據的情況將多個來自IO的請求先放在緩存裡面，然後再一次性的提交給磁碟，也就是說對於資料庫發出的多個8K數據塊的讀操作有可能放在一個磁碟讀IO里就處理了。
還有，有些存儲系統也是提供了緩存（Cache），接收到操作系統的IO請求之後也是會將多個操作系統的 IO請求合並成一個來處理。
不管是操作系統層面的緩存還是磁碟控制器層面的緩存，目的都只有一個，提高數據讀寫的效率。因此每次單獨的IO操作大小都是不一樣的，它主要取決於系統對於數據讀寫效率的判斷。這里以SQL Server資料庫的數據頁大小為例：8K。
(3) 傳送時間
傳送時間 = IO Chunk Size/Internal Transfer Rate = 8k/40M/s = 0.2ms
可以發現：
(3.1) 如果IO Chunk Size大的話，傳送時間會變大，從而導致IOPS變小；
(3.2) 機械磁碟的主要讀寫成本，都花在了定址時間上，即：尋道時間 + 旋轉延遲，也就是磁碟臂的擺動，和磁碟的旋轉延遲。
(3.3) 如果粗略的計算IOPS，可以忽略傳送時間，1000ms/(尋道時間 + 旋轉延遲)即可。
4. IOPS計算示例
以15000rpm為例：
(1) 單次IO時間
單次IO時間 = 尋道時間 + 旋轉延遲 + 傳送時間 = 3ms + 2ms + 0.2 ms = 5.2 ms
(2) IOPS
IOPS = 1000ms/單次IO時間 = 1000ms/5.2ms = 192 (次)
這里計算的是單塊磁碟的隨機訪問IOPS。
考慮一種極端的情況，如果磁碟全部為順序訪問，那麼就可以忽略：尋道時間 + 旋轉延遲 的時長，IOPS的計算公式就變為：IOPS = 1000ms/傳送時間
IOPS = 1000ms/傳送時間= 1000ms/0.2ms = 5000 (次)
顯然這種極端的情況太過理想，畢竟每個磁軌的空間是有限的，尋道時間 + 旋轉延遲 時長確實可以減少，不過是無法完全避免的。
四 資料庫中的磁碟讀寫
1. 隨機訪問和連續訪問
(1) 隨機訪問(Random Access)
指的是本次IO所給出的扇區地址和上次IO給出扇區地址相差比較大，這樣的話磁頭在兩次IO操作之間需要作比較大的移動動作才能重新開始讀/寫數據。
(2) 連續訪問(Sequential Access)
相反的，如果當次IO給出的扇區地址與上次IO結束的扇區地址一致或者是接近的話，那磁頭就能很快的開始這次IO操作，這樣的多個IO操作稱為連續訪問。
(3) 以SQL Server資料庫為例
數據文件，SQL Server統一區上的對象，是以extent(8*8k)為單位進行空間分配的，數據存放是很隨機的，哪個數據頁有空間，就寫在哪裡，除非通過文件組給每個表預分配足夠大的、單獨使用的文件，否則不能保證數據的連續性，通常為隨機訪問。
另外哪怕聚集索引表，也只是邏輯上的連續，並不是物理上。
日誌文件，由於有VLF的存在，日誌的讀寫理論上為連續訪問，但如果日誌文件設置為自動增長，且增量不大，VLF就會很多很小，那麼就也並不是嚴格的連續訪問了。
2. 順序IO和並發IO
(1) 順序IO模式(Queue Mode)
磁碟控制器可能會一次對磁碟組發出一連串的IO命令，如果磁碟組一次只能執行一個IO命令，稱為順序IO；
(2) 並發IO模式(Burst Mode)
當磁碟組能同時執行多個IO命令時，稱為並發IO。並發IO只能發生在由多個磁碟組成的磁碟組上，單塊磁碟只能一次處理一個IO命令。
(3) 以SQL Server資料庫為例
有的時候，盡管磁碟的IOPS(Disk Transfers/sec)還沒有太大，但是發現資料庫出現IO等待，為什麼？通常是因為有了磁碟請求隊列，有過多的IO請求堆積。
磁碟的請求隊列和繁忙程度，通過以下性能計數器查看：
LogicalDisk/Avg.Disk Queue Length
LogicalDisk/Current Disk Queue Length
LogicalDisk/%Disk Time
這種情況下，可以做的是：
(1) 簡化業務邏輯，減少IO請求數；
(2) 同一個實例下，多個資料庫遷移的不同實例下；
(3) 同一個資料庫的日誌，數據文件分離到不同的存儲單元；
(4) 藉助HA策略，做讀寫操作的分離。
3. IOPS和吞吐量(throughput)
(1) IOPS
IOPS即每秒進行讀寫（I/O）操作的次數。在計算傳送時間時，有提到，如果IO Chunk Size大的話，那麼IOPS會變小，假設以100M為單位讀寫數據，那麼IOPS就會很小。
(2) 吞吐量(throughput)
吞吐量指每秒可以讀寫的位元組數。同樣假設以100M為單位讀寫數據，盡管IOPS很小，但是每秒讀寫了N*100M的數據，吞吐量並不小。
(3) 以SQL Server資料庫為例
對於OLTP的系統，經常讀寫小塊數據，多為隨機訪問，用IOPS來衡量讀寫性能；
對於數據倉庫，日誌文件，經常讀寫大塊數據，多為順序訪問，用吞吐量來衡量讀寫性能。
磁碟當前的IOPS，通過以下性能計數器查看：
LogicalDisk/Disk Transfers/sec
LogicalDisk/Disk Reads/sec
LogicalDisk/Disk Writes/sec
磁碟當前的吞吐量，通過以下性能計數器查看：
LogicalDisk/Disk Bytes/sec
LogicalDisk/Disk Read Bytes/sec
LogicalDisk/Disk Write Bytes/sec
Ⅳ php 查資料庫 查文件 哪個快
file_exists 會更快
Ⅵ 利用文件系統處理數據與資料庫系統處理數據有什麼不同各有何優缺點
一、文件系統有明顯的缺點:
1、編寫應用程序很不方便。
2、文件的設計很難滿足多種應用程序的不同要求，數據冗餘經常是不可避免的。
3、文件結構的修改將導致應用程序的修改，應用程序的維護量將很大。
4、文件系統不支持對文件的並發訪問（concurrent access）。
二、優點:
1、提供高級的用戶介面。
2、查詢處理和優化。
3、數據目錄管理。
4、並發控制。
5、恢復功能。
6、完整性約束檢查。
7、訪問控制。
Ⅶ 利用文件系統處理數據與資料庫系統處理數據有什麼不同各有何優缺點
早期的資料庫管理都是採用文件系統。在文件系統中，數據按其內容、結構和用途組成若干命名的文件。文件一般為某個用戶或用戶組所有，但可供其他用戶共享。用戶可以通過操作系統對文件進行打開、讀、寫和關閉等操作。
文件系統有明顯的缺點:
(1).編寫應用程序很不方便。
應用程序的設計者必須對所用的文件的邏輯及物理結構有清楚的了解。操作系統 只能打開、關 閉、讀、寫等幾個低級的文件操作命令，對文件的查詢修改等處理都須在應用程序內解決。應用程序還 不可避免地在功能上有所重復。在文件系統上編寫應用程序的效率不高。
(2).文件的設計很難滿足多種應用程序的不同要求，數據冗餘經常是不可避免的。
為了兼顧各種應用程序的要求，在設計文件系統時，往往不得不增加冗餘的數據。數據冗餘不僅浪費空間，而且會帶來數據的不一致性（inconsistency).在文件系統中沒有維護數據一致性的監控機制，數據的一致性完全有用戶負責維護。在簡單的系統中勉強能應付，但在大型復雜的系統中幾乎是不可能完成的。
(3).文件結構的修改將導致應用程序的修改，應用程序的維護量將很大。
(4).文件系統不支持對文件的並發訪問（concurrent access）。
(5).數據缺少統一管理，在數據的結構、編碼、表示格式、命名以及輸出格式等方面不容易做到規范化、標准化；數據安全和保密方面，也難以採取有效的辦法。
針對文件系統的缺點,人們發展了以統一管理和共享數據為主要特徵的資料庫系統。在資料庫系統中，數據不再僅僅服務於某個程序或用戶，而是看成一個單位的共享資源，由一個叫資料庫管理系統（Data Management System，簡稱DBMS）的軟體統一管理。由於有DBMS的統一管理，應用程序不必直接介入諸如打開、關閉、讀寫文件等低級的操作，而由DBMS代辦。用戶也不必關系數據存儲和其他實現的細節，可在更高的抽象級別上觀察和訪問數據。文件結構的一些修改也可以由DBMS屏蔽，使用戶看不到這些修改，從而減少應用程序的維護工作量，提高數據的獨立性。由於數據的統一管理，人們可以從全單位著眼，合理組織數據，減少數據冗餘；還可以更好地貫徹規范化和標准化，從而有利於數據的轉移和更大范圍的共享。由於DBMS不是為某個應用程序服務，而是為整個單位服務的，DBMS做得復雜一些也是可以接受的。許多在文件系統中難以實現的動能，在DBMS中都一一實現了。
例如：適合不同類型用戶的多種用戶界面，保證並發訪問時的數據一致性的並發控制（concurrent control），增進數據安全性（security）的訪問控制（access control），在故障的情況下保證數據一致性的恢復（recovery）功能，保證數據在語義上的一致性的完整性約束（integrity constraints）檢查功能等。隨著計算機應用的發展，DBMS的功能愈來愈強，規模愈來愈大，復雜性和開銷也隨之增加。目前，在一些功能非常明確且無數據共享的簡單應用系統中，為減少開銷，提高性能，有時仍採用文件系統；不過在數據密集型應用系統中，基本上都使用資料庫系統。
現代的資料庫管理系統應該具備的7個功能：
1、提供高級的用戶介面
2、查詢處理和優化
這里的查詢(query)泛指用戶對資料庫所提的訪問要求,不但包含數據檢索,也包括修改\定義新數據等
3、數據目錄管理
4、並發控制
5、恢復功能
6、完整性約束檢查
7、訪問控制
數據管理和數據處理一樣，都是計算機系統的最基本的支撐技術。盡管計算機科學技術經歷了飛速的發展，但數據管理的這一地位沒有變化。數據管理將作為計算機科學技術的一個重要分支一直發展下去，社會信息化，對數據管理的要求也愈高。
Ⅷ 資料庫和文件哪個快 csdn
不能一概而論，要看是什麼數據，多少數據。
假如只有一條數據還專門存資料庫， 那絕對是沒事找事。
不過如果是百萬級的數據，還是用資料庫吧。即使用了資料庫也還是很慢，還需要創建索引。
就開發來說，如果你需要經常使用的數據，而且潛在可能會有不少，那麼就使用資料庫吧。比如很多的用戶資料產品資料這些。但是如果只是要保存一個個人設置，比如現在登錄的用戶的資料，就使用文件吧。
伺服器端還是使用資料庫好些
Ⅸ php 讀寫文件和資料庫哪個快
1、直接讀文件相比資料庫查詢效率更勝一籌，而且文中還沒算上連接和斷開的時間。
2、一次讀取的內容越大，直接讀文件的優勢會越明顯（讀文件時間都是小幅增長，這跟文件存儲的連續性和簇大小等有關系），這個結果恰恰跟天緣預料的相反，說明MYSQL對更大文件讀取可能又附加了某些操作（兩次時間增長了近30%），如果只是單純的賦值轉換應該是差異偏小才對。
3、寫文件和INSERT幾乎不用測試就可以推測出，資料庫效率只會更差。
4、很小的配置文件如果不需要使用到資料庫特性，更加適合放到獨立文件里存取，無需單獨創建數據表或記錄，很大的文件比如圖片、音樂等採用文件存儲更為方便，只把路徑或縮略圖等索引信息放到資料庫里更合理一些。
5、PHP上如果只是讀文件，file_get_contents比fopen、fclose更有效率，不包括判斷存在這個函數時間會少3秒左右。
6、fetch_row和fetch_object應該是從fetch_array轉換而來的，我沒看過PHP的源碼，單從執行上就可以說明fetch_array效率更高，這跟網上的說法似乎相反。