JSON 真違反了數(shù)據(jù)庫第一范式嗎？我們來聊一聊。

1. MySQL的JSON

MySQL 在 5.7 版本中正式引入了原生的 JSON 數(shù)據(jù)類型，接下來我們來詳細地介紹 JSON相關(guān)的信息。

1.1 MySQL 5.7 中的 JSON 支持

• 發(fā)布日期：MySQL 5.7 正式發(fā)布于 2015 年10月。
• JSON 數(shù)據(jù)類型：在此版本中，MySQL 引入了 JSON 類型，允許開發(fā)者在表中存儲和操作 JSON 格式的數(shù)據(jù)。這不僅提高了處理半結(jié)構(gòu)化數(shù)據(jù)的效率，還帶來了更多的靈活性。
• 功能特性：

驗證：MySQL 會自動驗證存儲在 JSON 列中的數(shù)據(jù)是否為有效的 JSON 格式。

高效存儲：JSON 數(shù)據(jù)以二進制格式存儲，優(yōu)化了存儲空間和訪問速度。

內(nèi)置函數(shù)：MySQL 5.7 提供了一系列與 JSON 操作相關(guān)的函數(shù)，如 JSON_EXTRACT、JSON_SET、JSON_ARRAY 等，方便對 JSON 數(shù)據(jù)進行查詢和修改。

索引支持：雖然初期對 JSON 索引的支持有限，但通過生成虛擬列并在這些列上創(chuàng)建索引，可以提高查詢性能。

1.2 后續(xù)版本的改進

• MySQL 8.0：在隨后的 MySQL 8.0 版本中，JSON 支持得到了進一步增強，包括：

更豐富的 JSON 函數(shù)：新增了更多操作 JSON 數(shù)據(jù)的函數(shù)，如 JSON_TABLE 等。

性能優(yōu)化：提升了 JSON 數(shù)據(jù)的處理性能，特別是在大規(guī)模數(shù)據(jù)集上的表現(xiàn)。

更好的與 SQL 標準的兼容性。

為了更好地理解 MySQL 的 JSON 數(shù)據(jù)類型，下面給出了一個使用 JSON 數(shù)據(jù)類型的簡單示例。

CREATE TABLEusers (
    idINT AUTO_INCREMENT PRIMARY KEY,
    nameVARCHAR(100),
    attributesJSON
);

INSERTINTOusers (name, attributes) VALUES
('Alice', '{"age": 30, "city": "New York"}'),
('Bob', '{"age": 25, "city": "Los Angeles"}');

-- 查詢 JSON 數(shù)據(jù)
SELECTname, JSON_EXTRACT(attributes, '$.city') AS city FROMusers;

2. JSON 是否違反第一范式？

在關(guān)系數(shù)據(jù)庫設計中，第一范式（1NF）要求每個表的每個字段都包含原子性（不可再分）的值。這意味著每個字段只能存儲單一值，不能包含集合、數(shù)組或其他復雜的數(shù)據(jù)結(jié)構(gòu)。MySQL 的 JSON 數(shù)據(jù)類型允許在一個字段中存儲復雜的嵌套數(shù)據(jù)結(jié)構(gòu)，這在某些情況下可能違反 1NF，但在其他情況下又可能不違反。下面我們將分別舉例來說明。

2.1 違反第一范式

為了說明 JSON違反1NF，這里以存儲多個電話號碼為例。假設我們有一個 users 表，每個用戶可能有多個電話號碼。如果我們將所有電話號碼存儲在一個 JSON 字段中，就違反了 1NF 的原子性要求。

CREATE TABLE users_conflict (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(100),
    phone_numbers JSON
);

INSERT INTO users_conflict (name, phone_numbers) VALUES 
('Alice', '["123-4567", "234-5678"]'),
('Bob', '["345-6789"]');

問題分析：

• 非原子性：phone_numbers 字段中包含了一個數(shù)組，存儲了多個電話號碼，違反了每個字段只能包含單一值的要求。
• 數(shù)據(jù)冗余與一致性：查詢特定電話號碼或更新某個電話號碼變得復雜，且難以利用關(guān)系數(shù)據(jù)庫的約束（如唯一性）來保證數(shù)據(jù)的一致性。

當我們要查詢所有包含電話號碼 "123-4567" 的用戶時，SQL語句如下：

SELECT name
FROM users_conflict
WHERE JSON_CONTAINS(phone_numbers, '"123-4567"', '$');

雖然 MySQL 提供了 JSON 函數(shù)，但這種查詢復雜度高于標準的關(guān)系型查詢，并且性能可能較低。

2.2 不違反第一范式

為了說明 JSON 不違反1NF，這里以存儲可選的、結(jié)構(gòu)化的屬性為例。假設我們有一個 products 表，其中大部分產(chǎn)品都有固定的屬性（如 id、name、price），但某些產(chǎn)品可能有額外的可選屬性（如 dimensions、manufacturer_details）。這些可選屬性可以存儲在一個 JSON 字段中，而不會違反 1NF。

CREATE TABLE products_no_conflict (
    idINT AUTO_INCREMENT PRIMARY KEY,
    nameVARCHAR(100),
    price DECIMAL(10,2),
    attributesJSON
);

INSERTINTO products_no_conflict (name, price, attributes) VALUES
('Laptop', 999.99, '{"dimensions": {"width": 35, "height": 2, "depth": 25}, "manufacturer_details": {"name": "TechCorp", "warranty": "2 years"}}'),
('Smartphone', 599.99, '{"color": "black", "storage": "128GB"}'),
('Book', 19.99, NULL);

問題分析：

• 維持原子性：attributes 字段用于存儲可選的、結(jié)構(gòu)化的額外信息。每個 attributes 字段本身被視為一個單一的 JSON 值，符合 1NF 的原子性要求。
• 數(shù)據(jù)靈活性：不需要為每種可能的屬性創(chuàng)建單獨的列，保持了表結(jié)構(gòu)的簡潔性。
• 查詢與維護：盡管某些查詢可能需要使用 JSON 函數(shù)，但由于這些屬性是附加的、可選的，不會影響表的主要結(jié)構(gòu)和核心數(shù)據(jù)的完整性。

當我們要查詢所有寬度大于 30 的產(chǎn)品時，SQL語句如下：

SELECT name, attributes
FROM products_no_conflict
WHERE JSON_EXTRACT(attributes, '$.dimensions.width') > 30;

雖然這種查詢依賴于 JSON 函數(shù)，但由于 attributes 字段僅包含相關(guān)的附加信息，主表結(jié)構(gòu)依然保持了 1NF 的原子性。

3. 總結(jié)

本文，我們分析了 MySQL 的 JSON 數(shù)據(jù)類型是否違反了數(shù)據(jù)庫的第一范式（1NF），通過全文的分析，我們可以知道：JSON 是否違反 1NF 取決于具體的應用需求和數(shù)據(jù)模型設計：

• 與 1NF 沖突：當 JSON 字段用于存儲多值集合（如數(shù)組、重復組）時，會違反 1NF 的原子性要求。例如，將多個電話號碼存儲在一個 JSON 字段中。
• 不與 1NF 沖突：當 JSON 字段用于存儲單一的結(jié)構(gòu)化對象，即使該對象內(nèi)部包含多個鍵值對，也可以視為一個原子值，從而不違反 1NF。例如，存儲產(chǎn)品的可選屬性或配置信息。

需要注意的是，雖然在某些情況下使用 JSON 字段不會直接違反 1NF，但過度依賴 JSON 可能會帶來查詢復雜性、性能問題和數(shù)據(jù)一致性維護的挑戰(zhàn)。因此，在設計數(shù)據(jù)庫時，應權(quán)衡使用 JSON 字段的優(yōu)勢與潛在的規(guī)范化沖突，確保數(shù)據(jù)模型的可靠性和可維護性。