簡介
關系型數據庫的使用已經有相當長的時間了。它們變得流行起來托了管理系統(tǒng)的福,關系模型被實現(xiàn)得相當的好,并且被證明是操作數據的好方法(特別是事務性強的應用)。
在這篇DigitalOcean文章中,我們將嘗試理解一些最常用、最流行的關系型數據庫管理系統(tǒng)(RDBMS)的內核區(qū)別。我們將會探索最底層的區(qū)別——特性與功能,它們如何工作,在哪方面更出色,以幫助程序員選擇合適的RDBMS。
條目表
1. 數據庫管理系統(tǒng)
關系型數據庫管理系統(tǒng)
關系與數據類型
重要的和流行的關系型數據庫
2. SQLite
SQLite支持的數據類型
SQLite的優(yōu)勢
SQLite的劣勢
何時使用SQLite
何時不用SQLite
3. MySQL
MySQL支持的數據類型
MySQL的優(yōu)勢
MySQL的劣勢
何時使用MySQL
何時不用MySQL
3. PostgreSQL
PostgreSQL支持的數據類型
PostgreSQL的優(yōu)勢
PostgreSQL的劣勢
何時使用PostgreSQL
何時不用PostgreSQL
數據庫管理系統(tǒng)
數據庫是有組織地存儲模型數據的空間,存儲各種類型的信息(數據)。每個數據庫,除了無模式型的,都有一個模型,提供數據的結構描述。數據庫管理系統(tǒng)是管理數據庫結構、大小和排序的應用(或庫)。
關系型數據庫管理系統(tǒng)
關系型數據庫系統(tǒng)實現(xiàn)了關系模型,并用它來處理數據。關系模型在表中將信息與字段關聯(lián)起來(也就是schemas),從而存儲數據。
這種數據庫管理系統(tǒng)需要結構(例如表)在存儲數據之前被定義出來。有了表,每一列(字段)都存儲一個不同類型(數據類型)的信息。數據庫中的每個記錄,都有自己唯一的key,作為屬于某一表的一行,行中的每一個信息都對應了表中的一列——所有的關系一起,構成了關系模型。
關系和數據類型
關系可以被看做是包含一系列共同表示被保持數據庫以及相關信息的屬性的數學集合. 這種類型的識別和采集方法可以讓關系型數據庫以它們自己的方式運作.
在定義一個可以向其中插入數據的表時,每一個形成一條記錄的元素(例如: 屬性)都必須同定義的數據類型相匹配(例如:一個integer, 一個date 等等.). 不同的關系型數據庫管理系統(tǒng)實現(xiàn)了不同的數據類型 — 它們不總是能直接互相轉換的.
與限制的協(xié)作,就像我們之前已經介紹過的,在關系數據庫的使用中是很普遍的。事實上,限制形成了關系的核心.
重要和流行的關系型數據庫
本文中,我們將會介紹三種主要而且重要的開源關系型數據庫管理系統(tǒng),是他們影響了應用開發(fā)世界。
SQLite:
一個強大的嵌入式關系型數據庫管理系統(tǒng)。
MySQL:
最流行的RDBMS。
PostgreSQL:
最先進SQL型開源objective-RDBMS。
注: 開源應用總是可以自由使用的。大多數時候,復制工程(利用代碼)創(chuàng)建新應用也是被允許的。如果你對DBMS感興趣,你可以看看一些基于這些工程的分支項目,例如MariaDB。
SQLiteSQLite是非凡的數據庫,他可以進程在使用它的應用中。作為一個自包含、基于文件的數據庫,SQLite提供了出色的工具集,可以處理所有類型的數據,沒有什么限制,而且比起服務器運行的進程型服務器使用起來輕松許多。
一個應用使用SQLite時,它的功能直接被集成在其中,應用會直接訪問包含數據的文件(即SQLite數據庫),而不是通過一些端口(port, socket)來交互。感謝這種底層技術,這使SQLite變得非??焖俸透咝?,并且十分強大。
SQLite支持的數據類型
- NULL:
NULL值。
- INTEGER:
有符號整數,按照設置用1、2、3、4、6或8字節(jié)存儲。
- REAL:
浮點數,使用8字節(jié)IEEE浮點數方式存儲。
- TEXT:
文本字符串,使用數據庫編碼存儲(UTF-8, UTF-16BE 或 UTF-16LE)。
- BLOB:
二進制大對象,怎么輸入就怎么存儲。
SQLite 的優(yōu)點
- 基于文件:
整個數據庫都包含在磁盤上的一個文件中,因此它有很好的遷移性。
- 標準化:
盡管它看起來像個“簡化版”的數據庫,SQLite 確實支持 SQL。它略去了一些功能(RIGHT OUTER JOIN 和 FOR EACH STATEMENT),但是,又同時增加了一些其他功能。
- 對開發(fā)乃至測試都很棒:
在絕大多數應用的開發(fā)階段中,大部分人都非常需要解決方案能有并發(fā)的靈活性。SQLite 含有豐富功能基礎,所能提供的超乎開發(fā)所需,并且簡潔到只需一個文件和一個 C 鏈接庫。
SQLite的缺點
- 沒有用戶管理:
高級數據庫都能支持用戶系統(tǒng),例如,能管理數據庫連接對數據庫和表的訪問權限。但由于 SQLite 產生的目的和本身性質(沒有多用戶并發(fā)的高層設計),它沒有這個功能。
- 缺乏額外優(yōu)化性能的靈活性:
仍然是從設計之初,SQLite 就不支持使用各種技巧來進行額外的性能優(yōu)化。這個庫容易配置,容易使用。既然它并不復雜,理論上就無法讓它比現(xiàn)在更快,其實現(xiàn)在它已經很快了。
何時使用 SQLite ?
- 嵌入式應用:
所有需要遷移性,不需要擴展的應用,例如,單用戶的本地應用,移動應用和游戲。
- 代替磁盤訪問:
在很多情況下,需要頻繁直接讀/寫磁盤文件的應用,都很適合轉為使用 SQLite ,可以得益于 SQLite 使用 SQL 帶來的功能性和簡潔性。
- 測試:
它能秒殺大部分專門針對應用業(yè)務邏輯(也就是應用的主要目的:能完成功能)的測試。
何時不用 SQLite ?
- 多用戶應用:
如果你在開發(fā)的應用需要被多用戶訪問,而且這些用戶都用同一個數據庫,那么相比 SQLite 最好還是選擇一個功能完整的關系型數據庫(例如 MySQL)。
- 需要大面積寫入數據的應用:
SQLite 的缺陷之一是它的寫入操作。這個數據庫同一時間只允許一個寫操作,因此吞吐量有限。
MySQLMySQL 在所有大型數據庫服務器中最流行的一個. 它的特性豐富,產品的開源性質使得其驅動了線上大量的網站和應用程序. 要入手 MySQL 相對簡單,開發(fā)人員可以在互聯(lián)網上面訪問到大量有關這個數據庫的信息.
注意: 由于這個產品的普及性,大量的第三方應用、工具和集成庫對于操作這個RDBCMS的方方面面大有幫助.
Mysql沒有嘗試去實現(xiàn)SQL標準的全部,而是為用戶提供了很多有用的功能. 作為一個獨立的數據庫服務器,應用程序同Mysql守護進程的交互,告訴它去訪問數據庫自身 — 這一點不像 SQLite.
MySQL支持的數據類型
- TINYINT:
一個非常小的整數. - SMALLINT:
一個小整數. - MEDIUMINT:
一個中間大小的整數. - INT or INTEGER:
一個正常大小的整數. - BIGINT:
一個大的整數. - FLOAT:一個小的 (單精度) 浮點數,不能是無符號的那種.
- DOUBLE, DOUBLE PRECISION, REAL:一個正常大小 (雙精度) 的浮點數,不能使無符號的那種.
- DECIMAL, NUMERIC:沒有被包裝的浮點數。不能使無符號的那種.
- DATE:
一個日期. - DATETIME:
一個日期和時間的組合. - TIMESTAMP:
一個時間戳. - TIME:
一個時間. - YEAR:
一個用兩位或者4位數字格式表示的年份(默認是4位). - CHAR:
一個固定長度的字符串,存儲時總是在其固定長度的空間里右對齊. - VARCHAR:
一個可變長度的字符串. - TINYBLOB, TINYTEXT:
一個BLOB或者TEXT列,最大長度255 (2^8 – 1)個字符.
BLOB, TEXT:
一個BLOB或者TEXT列,最大長度 65535 (2^16 – 1)個字符.
- MEDIUMBLOB, MEDIUMTEXT:
一個BLOB或者TEXT列,最大長度 16777215 (2^24 – 1)個字符. - LONGBLOB, LONGTEXT:
一個BLOB或者TEXT列,最大長度4294967295 (2^32 – 1) 個字符. - ENUM:
一個枚舉類型. - SET:
一個集合.
MySQL的優(yōu)點
- 容易使用:
安裝MySQL非常容易。第三方庫,包括可視化(也就是有GUI)的庫讓上手使用數據庫非常簡單。
- 功能豐富:
MySQL 支持大部分關系型數據庫應該有的 SQL 功能——有些直接支持,有些間接支持。
- 安全:
MYSQL 有很多安全特性,其中有些相當高級。
- 靈活而強大:
MySQL 能處理很多數據,此外如有需要,它還能“適應”各種規(guī)模的數據。
- 快速:
放棄支持某些標準,讓 MySQL 效率更高并能使用捷徑,因此帶來速度的提升。
MySQL的缺點
- 已知的局限:
從設計之初,MySQL 就沒打算做到全知全能,因此它有一些功能局限,無法滿足某些頂尖水平應用的需求。 - 可靠性問題:
MySQL 對于某些功能的實現(xiàn)方式(例如,引用,事務,數據審核等) 使得它比其他一些關系型數據庫略少了一些可靠性。 - 開發(fā)停滯:
盡管 MySQL 理論上仍是開源產品,也有人抱怨它誕生之后更新緩慢。然而,應該注意到有一些基于 MySQL 并完整集成的數據庫(如 MariaDB),在標準的 MySQL 基礎上帶來了額外價值。
何時使用 MySQL?
- 分布式操作:
當SQLite所提供的不能滿足你的需要時,可以把MySQL包括進你的部署棧,就像任何一個獨立的數據庫服務器,它會帶來大量的操作自由性和一些先進的功能。 - 高安全性:
MySQL的安全功能,用一種簡單的方式為數據訪問(和使用)提供了可靠的保護。 - Web網站 和 Web應用:
絕大多數的網站(和Web應用程序)可以忽視約束性地簡單工作在MySQL上。這種靈活的和可擴展的工具是易于使用和易于管理的——這被證明非常有助于長期運行。 - 定制解決方案:
如果你工作在一個高度量身定制的解決方案上,MySQL能夠很容易地尾隨和執(zhí)行你的規(guī)則,這要感謝其豐富的配置設置和操作模式。
何時不用 MySQL?
- SQL 服從性:
因為 MySQL 沒有[想要]實現(xiàn) SQL 的全部標準,所以這個工具不完全符合SQL。如果你需要對這樣的關系數據庫管理系統(tǒng)進行整合,從MySQL進行切換是不容易的。 - 并發(fā):
即使MySQL和一些存儲引擎能夠真地很好執(zhí)行讀取操作,但并發(fā)讀寫還是有問題的。 - 缺乏特色:
再次提及,根據數據庫引擎的選擇標準,MySQL會缺乏一定的特性,如全文搜索。
PostgreSQL
PostgreSQL 是一個先進的,開放源代碼的[對象]-關系型數據庫管理系統(tǒng),它的主要目標是實現(xiàn)標準和可擴展性. PostgreSQL, 或者說是 Postgres, 試圖把對 ANSI/ISO SQL標準的采用與修正結合起來.
對比其他的RDBMS, PostgreSQL以它對于對象-關系和\或關系型數據庫功能,比如對于可靠事務,例如原子性,一致性,隔離性和持久性(ACID)的完全支持,這些東西的高度需求和集合的支持,以示其獨特性.
由于強大的底層技術, Postgres對于高效的完成許多處理任務很有一手. 得益于其多版本并發(fā)控制 (MVCC)的實現(xiàn),在沒有讀取鎖的前提下也能達成并發(fā), 這也同樣確保了ACID的實施.
PostgreSQL是高度可編程的, 因而可以使用被稱作“存儲過程”的自定義程序進行擴展. 這些功能可以被創(chuàng)建用來簡化一個寫重復、復雜并且常常需要數據庫操作的任務的執(zhí)行.
雖然特性強大,但這個 DBMS并沒有MySQL那么流行, 可還是有許多迷人的第三方工具和庫被設計出來用于使得對PostgreSQL的操作簡化. 如今通過許多操作系統(tǒng)默認的包管理器輕松的獲取PostgreSQL已成為可能.
PostgreSQL支持的數據類型
- bigint:
有符號的八位整數 - bigserial:
自增長的八位整數 - bit [(n)]:
固定長度的位串 - bit varying [(n)]:
可變長度的位串 - boolean:
邏輯布爾值(true/false) - box:
在一個平面上的矩形框 - bytea:
二進制數據(“位數組”) - character varying [(n)]:
可變長度的字符串 - character [(n)]:
固定長度的字符串 - cidr:
IPv4 或者 IPv6 網絡地址 - circle:
平面上的一個圓 - date:
日歷日期 ( 年月日) - double precision:
雙精度浮點數(8位) - inet:
IPv4 或者 IPv6 主機地址 - integer:
有符號的四位整數 - interval [fields] [(p)]:
時間跨度 - line:
平面上的一個無限長的直線 - lseg:
平面上的一個線段 - macaddr:
MAC (媒體訪問控制)地址 - money:
貨幣金額 - numeric [(p, s)]:
可選精度的精確數字 - path:
一個平面上的幾何路徑 - point:
一個平面上的幾何點 - polygon:
一個平面上的閉合的幾何路徑 - real:
單精度浮點數(4 位) - smallint:有符號的兩位整數
- serial:
自增長4位整數 - text:
可變長度字符創(chuàng) - time [(p)] [without time zone]:
一天中的時間(無時區(qū)) - time [(p)] with time zone:
一天中的時間,包含時區(qū) - timestamp [(p)] [without time zone]:
日期和時間(沒有時區(qū)) - timestamp [(p)] with time zone:
日期和時間,包含時區(qū) - tsquery:
文本搜索查詢 - tsvector:
文本搜索文檔 - txid_snapshot:
用戶級事務ID快照 - uuid:
通用的唯一標識符 - xml:
XML 數據
PostgreSQL的優(yōu)點
- 標準支持 SQL 的開源關系型數據庫:
PostgreSQL 是一個開源的,自由(free)的,同時非常強大的關系型數據管理系統(tǒng)。 - 強大的社區(qū):
PostgreSQL 背后有熱忱而經驗豐富的社區(qū),可以通過知識庫和問答網站獲取支持,全天候免費。 - 強大的第三方支持:
即使其本身功能十分強大,PostgreSQL 仍附帶有許多強大的開源第三方工具來輔助系統(tǒng)的設計、管理和使用。 - 可擴展性:
可以用預先存儲的流程來程序性擴展 PostgreSQL ,一個高級的關系型數據庫理應如此。 - 面向對象:
PostgreSQL 不只是一個關系型數據庫,還是一個面向對象數據庫——支持嵌套,及一些其他功能。
PostgreSQL的缺點:
- 性能:
對于簡單而繁重的讀取操作, PostgreSQL 會小題大作而可能會出現(xiàn)比同行(如MySQL)更低的性能。 - 普及:
根據該工具的性質,從普及度來說它還缺乏足夠后臺支撐,盡管有大量的部署——這可能會影響能夠獲得支持的容易程度。 - 托管:
由于上述因素的影響,要讓主機或服務提供商提出使用PostgreSQL實例是很難的。
何時使用PostgreSQL?
數據完整性: 當可靠性和數據完整性是絕對必要而無需理由時,PostgreSQL是更好的選擇。
復雜的自定義過程: 如果你需要你的數據庫執(zhí)行自定義過程,可擴展的PostgreSQL是更好的選擇。
整合: 在將來,如果可能要把整個數據庫系統(tǒng)遷移到另一個適當的解決方案(例如Oracle)中,PostgreSQL對于這種切換將是最兼容和易于操作的。
復雜的設計:
相比其他的開源和自由的 RDBMS(關系數據庫管理系統(tǒng))實現(xiàn)來說,對于復雜的數據庫設計,PostgreSQL提供了大部分的功能和可能性,同時并沒放棄其他有價值的地方。
何時不用 PostgreSQL?
- 速度:
如果你需要的只是快速的讀取操作, PostgreSQL 不是為此而準備的工具。 - 簡化體制:
除非你需要絕對的數據完整性,原子性,一致性,隔離性,耐久性,或復雜的設計,PostgreSQL 對簡化體制來說是殺手。 - 復制:
除非你愿意花不少時間,精力和資源,否則對于那些缺乏數據庫和系統(tǒng)管理經驗的人來說,實現(xiàn)與MySQL的(主從)復制可能不容易。
本文轉自開源中國,參與翻譯(4人):趙亮-碧海情天, 戴倉薯, realZ, leoxu
End.
- 央視315聚焦啄木鳥維修亂象:亂收費遭投訴,黑貓投訴量破紀錄,消費者權益受威脅
- 嚴守品質底線:大岸浪花品牌全面下架蝦仁,消費者權益保障新篇章
- 中國移動回應315晚會投訴:正自查通信電話營銷亂象,承諾2025年還用戶清朗通訊環(huán)境
- 2025款G6與G9破繭而出,小鵬汽車科技平權新篇章,顛覆想象
- 優(yōu)音通信被315點名:積極配合調查,揭露問題真相,維護消費者權益
- 挪威科學家研發(fā)自修復電動汽車電池:續(xù)航、充電、壽命三提升,未來可期
- 啄木鳥承諾整改并推出六大措施:誠信經營、價格透明化等
- "3·15"曝光問題迅速響應,市監(jiān)總局、工信部聯(lián)手查處,守護消費者權益!
- 海淀首推智能餐飲機器人標準:引領餐飲業(yè)革新,邁向智能化新時代
- 兌吧回應央視3·15點名:痛定思痛,全面整改業(yè)務風險,重塑信任
免責聲明:本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿,凡在本網站出現(xiàn)的信息,均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性,但不保證有關資料的準確性及可靠性,讀者在使用前請進一步核實,并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏,概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時,應及時向本網站提出書面權利通知或不實情況說明,并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后,將會依法盡快聯(lián)系相關文章源頭核實,溝通刪除相關內容或斷開相關鏈接。