Lưu trữ dữ liệu trong MySQL dưới dạng JSON

Tôi nghĩ rằng đây là một điều n00b để làm. Và, vì vậy, tôi chưa bao giờ làm điều đó. Sau đó, tôi thấy FriendFeed đã làm điều này và thực sự đã làm cho quy mô DB của họ tốt hơn và giảm độ trễ. Tôi tò mò không biết có nên làm điều này không. Và, nếu vậy, cách thích hợp để làm điều đó là gì?

Về cơ bản, đâu là nơi tốt để học cách lưu trữ mọi thứ trong MySQL dưới dạng một loại DB CouchDB? Lưu trữ mọi thứ dưới dạng JSON có vẻ như sẽ dễ dàng và nhanh chóng hơn (không phải xây dựng, độ trễ ít hơn).

Ngoài ra, có dễ dàng chỉnh sửa, xóa, v.v., những thứ được lưu trữ dưới dạng JSON trên DB không?

CouchDB và MySQL là hai con thú rất khác nhau. JSON là cách gốc để lưu trữ nội dung trong CouchDB. Trong MySQL, điều tốt nhất bạn có thể làm là lưu trữ dữ liệu JSON dưới dạng văn bản trong một trường duy nhất. Điều này sẽ hoàn toàn đánh bại mục đích lưu trữ nó trong RDBMS và sẽ làm phức tạp mọi giao dịch cơ sở dữ liệu.

Đừng.

Phải nói rằng, FriendFeed dường như sử dụng một lược đồ cực kỳ tùy chỉnh trên MySQL. Nó thực sự phụ thuộc vào chính xác những gì bạn muốn lưu trữ, hầu như không có câu trả lời chắc chắn về cách lạm dụng một hệ thống cơ sở dữ liệu để nó có ý nghĩa đối với bạn. Cho rằng bài viết rất cũ và lý do chính của họ chống lại Mongo và Couch là chưa trưởng thành, tôi sẽ đánh giá lại hai điều này nếu MySQL không cắt nó cho bạn. Đáng lẽ giờ họ đã phát triển rất nhiều.

Mọi người nhận xét dường như đến từ góc độ này không đúng, lưu trữ mã JSON thông qua PHP trong DB quan hệ là điều tốt và trên thực tế, nó sẽ nhanh hơn khi tải và hiển thị dữ liệu phức tạp như thế này, tuy nhiên bạn sẽ có những cân nhắc về thiết kế như tìm kiếm, lập chỉ mục, v.v.

Cách tốt nhất để làm điều này là sử dụng dữ liệu kết hợp, ví dụ: nếu bạn cần tìm kiếm dựa trên datetime MySQL (điều chỉnh hiệu suất) sẽ nhanh hơn rất nhiều so với PHP và đối với một số thứ như khoảng cách tìm kiếm các địa điểm thì MySQL cũng phải rất nhiều. nhanh hơn (thông báo tìm kiếm không truy cập). Dữ liệu bạn không cần phải tìm kiếm sau đó có thể được lưu trữ dưới dạng JSON, BLOB hoặc bất kỳ định dạng nào khác mà bạn thực sự cho là cần thiết.

Dữ liệu bạn cần truy cập được lưu trữ rất dễ dàng dưới dạng JSON, chẳng hạn như hệ thống hóa đơn cơ bản cho từng trường hợp. Chúng không được hưởng lợi nhiều từ RDBMS và có thể được lưu trữ trong JSON chỉ bằng json_encoding ($ _ POST ['entires']) nếu bạn có cấu trúc biểu mẫu HTML chính xác.

Tôi rất vui vì bạn hài lòng khi sử dụng MongoDB và tôi hy vọng rằng nó tiếp tục phục vụ bạn tốt, nhưng đừng nghĩ rằng MySQL sẽ luôn nằm ngoài tầm ngắm của bạn, vì ứng dụng của bạn ngày càng phức tạp, bạn có thể sẽ cần một RDBMS một số chức năng và tính năng (ngay cả khi nó chỉ để gỡ bỏ dữ liệu đã lưu trữ hoặc báo cáo kinh doanh)

MySQL 5.7 Hiện hỗ trợ kiểu dữ liệu JSON gốc tương tự như MongoDB và các kho dữ liệu tài liệu không toán học khác:

Hỗ trợ JSON

Bắt đầu với MySQL 5.7.8, MySQL hỗ trợ kiểu JSON gốc. Giá trị JSON không được lưu trữ dưới dạng chuỗi, thay vào đó sử dụng định dạng nhị phân nội bộ cho phép truy cập đọc nhanh vào các phần tử tài liệu. Các tài liệu JSON được lưu trữ trong các cột JSON được tự động xác thực bất cứ khi nào chúng được chèn hoặc cập nhật, với một tài liệu không hợp lệ sẽ gây ra lỗi. Các tài liệu JSON được chuẩn hóa khi tạo và có thể được so sánh bằng cách sử dụng hầu hết các toán tử so sánh như =, <, <=,>,> =, <>,! =, Và <=>; để biết thông tin về các toán tử được hỗ trợ cũng như mức độ ưu tiên và các quy tắc khác mà MySQL tuân theo khi so sánh các giá trị JSON, hãy xem So sánh và Thứ tự các Giá trị JSON.

MySQL 5.7.8 cũng giới thiệu một số hàm để làm việc với các giá trị JSON. Các chức năng này bao gồm những chức năng được liệt kê ở đây:

1. Các hàm tạo giá trị JSON: JSON_ARRAY (), JSON_MERGE () và JSON_OBJECT (). Xem Phần 12.16.2, “Các hàm tạo giá trị JSON”.
2. Các hàm tìm kiếm giá trị JSON: JSON_CONTAINS (), JSON_CONTAINS_PATH (), JSON_EXTRACT (), JSON_KEYS () và JSON_SEARCH (). Xem Phần 12.16.3, “Các chức năng tìm kiếm giá trị JSON”.
3. Các hàm sửa đổi giá trị JSON: JSON_APPEND (), JSON_ARRAY_APPEND (), JSON_ARRAY_INSERT (), JSON_INSERT (), JSON_QUOTE (), JSON_REMOVE (), JSON_REPLACE (), JSON_SET () và JSON_UNQUOTE (). Xem Phần 12.16.4, “Các hàm sửa đổi giá trị JSON”.
4. Các hàm cung cấp thông tin về giá trị JSON: JSON_DEPTH (), JSON_LENGTH (), JSON_TYPE () và JSON_VALID (). Xem Phần 12.16.5, “Các hàm trả về thuộc tính giá trị JSON”.

Trong MySQL 5.7.9 trở lên, bạn có thể sử dụng đường dẫn column-> như viết tắt cho JSON_EXTRACT (cột, đường dẫn). Điều này hoạt động như một bí danh cho một cột ở bất cứ nơi nào mà một định danh cột có thể xuất hiện trong câu lệnh SQL, bao gồm các mệnh đề WHERE, ORDER BY và GROUP BY. Điều này bao gồm SELECT, UPDATE, DELETE, CREATE TABLE và các câu lệnh SQL khác. Phía bên trái phải là số nhận dạng cột JSON (và không phải là bí danh). Phía bên phải là biểu thức đường dẫn JSON được trích dẫn được đánh giá dựa trên tài liệu JSON được trả về dưới dạng giá trị cột.

Xem Phần 12.16.3, “Các hàm tìm kiếm giá trị JSON”, để biết thêm thông tin về -> và JSON_EXTRACT (). Để biết thông tin về hỗ trợ đường dẫn JSON trong MySQL 5.7, hãy xem Tìm kiếm và sửa đổi giá trị JSON. Xem thêm Chỉ mục phụ và Cột được tạo ảo.

Thêm thông tin:

https://dev.mysql.com/doc/refman/5.7/en/json.html

Các ký tự json không có gì đặc biệt khi nó được lưu trữ, các ký tự như

{, }, [, ], ', a-z, 0-9.... thật sự không có gì đặc biệt và có thể được lưu trữ dưới dạng văn bản.

vấn đề đầu tiên bạn gặp phải là cái này

{profile_id: 22, tên người dùng: 'Robert', mật khẩu: 'skhgeeht893htgn34ythg9er'}

được lưu trữ trong cơ sở dữ liệu không đơn giản để cập nhật trừ khi bạn đã tiến hành riêng và phát triển mã jsondecode cho mysql

UPDATE users SET JSON(user_data,'username') = 'New User';

Vì vậy, khi bạn không thể làm điều đó, trước tiên bạn sẽ phải CHỌN json, Giải mã nó, thay đổi nó, cập nhật nó, vì vậy về lý thuyết, bạn cũng có thể dành nhiều thời gian hơn để xây dựng một cấu trúc cơ sở dữ liệu phù hợp!

Tôi sử dụng json để lưu trữ dữ liệu nhưng chỉ Dữ liệu Meta, dữ liệu không được cập nhật thường xuyên, không liên quan đến người dùng cụ thể .. ví dụ nếu người dùng thêm một bài đăng và trong bài đăng đó, anh ta thêm hình ảnh. Phân tích cú pháp hình ảnh và tạo ngón tay cái và sau đó sử dụng các url ngón tay cái ở định dạng json.

Để minh họa mức độ khó khăn khi lấy dữ liệu JSON bằng cách sử dụng truy vấn, tôi sẽ chia sẻ truy vấn mà tôi đã thực hiện để xử lý điều này.

Nó không tính đến mảng hoặc các đối tượng khác, chỉ là các kiểu dữ liệu cơ bản. Bạn nên thay đổi 4 trường hợp của cột thành tên cột lưu trữ JSON và thay đổi 4 trường hợp của myfield thành trường JSON mà bạn muốn truy cập.

SELECT
    SUBSTRING(
        REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', ''),
        LOCATE(
            CONCAT('myfield', ':'),
            REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', '')
        ) + CHAR_LENGTH(CONCAT('myfield', ':')),
        LOCATE(
            ',',
            SUBSTRING(
                REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', ''),
                LOCATE(
                    CONCAT('myfield', ':'),
                    REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', '')
                ) + CHAR_LENGTH(CONCAT('myfield', ':'))
            )
        ) - 1
    )
    AS myfield
FROM mytable WHERE id = '3435'

Nó thực sự phụ thuộc vào trường hợp sử dụng của bạn. Nếu bạn đang lưu trữ thông tin hoàn toàn không có giá trị trong báo cáo và sẽ không được truy vấn thông qua JOIN với các bảng khác, bạn có thể lưu trữ dữ liệu của mình trong một trường văn bản, được mã hóa dưới dạng JSON.

Điều này có thể đơn giản hóa rất nhiều mô hình dữ liệu của bạn. Tuy nhiên, như RobertPitt đã đề cập, đừng mong đợi có thể kết hợp dữ liệu này với dữ liệu khác đã được chuẩn hóa.

Đây là một câu hỏi cũ, nhưng tôi vẫn có thể thấy câu này ở đầu kết quả tìm kiếm của Google, vì vậy tôi đoán sẽ rất có ý nghĩa nếu thêm một câu trả lời mới 4 năm sau khi câu hỏi được hỏi.

Trước hết, có sự hỗ trợ tốt hơn trong việc lưu trữ JSON trong RDBMS. Bạn có thể cân nhắc chuyển sang PostgreSQL (mặc dù MySQL đã hỗ trợ JSON kể từ v5.7.7). PostgreSQL sử dụng các lệnh SQL rất giống với MySQL ngoại trừ chúng hỗ trợ nhiều chức năng hơn. Một trong những chức năng họ đã thêm là họ cung cấp kiểu dữ liệu JSON và bây giờ bạn có thể truy vấn JSON được lưu trữ. ( Một số tài liệu tham khảo về điều này ) Nếu bạn không tạo truy vấn trực tiếp trong chương trình của mình, chẳng hạn như sử dụng PDO trong php hoặc eloquent trong Laravel, tất cả những gì bạn cần làm chỉ là cài đặt PostgreSQL trên máy chủ của mình và thay đổi cài đặt kết nối cơ sở dữ liệu. Bạn thậm chí không cần phải thay đổi mã của mình.

Hầu hết thời gian, như các câu trả lời khác đã đề xuất, lưu trữ dữ liệu dưới dạng JSON trực tiếp trong RDBMS không phải là một ý tưởng hay. Có một số ngoại lệ mặc dù. Một tình huống tôi có thể nghĩ đến là một trường có số lượng mục nhập được liên kết thay đổi.

Ví dụ: để lưu trữ thẻ của một bài đăng trên blog, thông thường bạn sẽ cần phải có một bảng cho bài đăng trên blog, một bảng thẻ và một bảng phù hợp. Vì vậy, khi người dùng muốn chỉnh sửa một bài đăng và bạn cần hiển thị thẻ nào liên quan đến bài đăng đó, bạn sẽ cần truy vấn 3 bảng. Điều này sẽ làm hỏng hiệu suất rất nhiều nếu bảng / bảng thẻ phù hợp của bạn dài.

Bằng cách lưu trữ các thẻ dưới dạng JSON trong bảng bài đăng trên blog, hành động tương tự chỉ yêu cầu một tìm kiếm bảng duy nhất. Sau đó, người dùng sẽ có thể thấy bài đăng trên blog được chỉnh sửa nhanh hơn, nhưng điều này sẽ làm hỏng hiệu suất nếu bạn muốn tạo báo cáo về bài đăng nào được liên kết với thẻ hoặc có thể tìm kiếm theo thẻ.

Bạn cũng có thể cố gắng hủy bình thường hóa cơ sở dữ liệu. Bằng cách sao chép dữ liệu và lưu trữ dữ liệu theo cả hai cách, bạn có thể nhận được lợi ích của cả hai phương pháp. Bạn sẽ chỉ cần thêm một chút thời gian để lưu trữ dữ liệu của mình và nhiều không gian lưu trữ hơn (rẻ so với chi phí của sức mạnh máy tính cao hơn)

Tôi sẽ nói hai lý do duy nhất để xem xét điều này là:

• hiệu suất không đủ tốt với cách tiếp cận bình thường hóa
• bạn không thể dễ dàng lập mô hình dữ liệu đặc biệt linh hoạt / linh hoạt / thay đổi của mình

Tôi đã viết một chút về cách tiếp cận của riêng tôi ở đây:

Bạn đã gặp phải sự cố nào về khả năng mở rộng khi sử dụng kho dữ liệu NoSQL?

(xem câu trả lời trên cùng)

Ngay cả JSON cũng không đủ nhanh nên chúng tôi đã sử dụng cách tiếp cận định dạng văn bản tùy chỉnh. Đã làm việc / tiếp tục hoạt động tốt cho chúng tôi.

Có lý do gì bạn không sử dụng một cái gì đó như MongoDB? (có thể là MySQL là "bắt buộc"; chỉ là tò mò)

Đối với tôi, dường như tất cả mọi người trả lời câu hỏi này đều thiếu một vấn đề quan trọng, ngoại trừ @deceze - sử dụng đúng công cụ cho công việc . Bạn có thể buộc cơ sở dữ liệu quan hệ lưu trữ hầu hết mọi loại dữ liệu và bạn có thể buộc Mongo xử lý dữ liệu quan hệ, nhưng với chi phí nào? Bạn kết thúc việc giới thiệu sự phức tạp ở tất cả các cấp độ phát triển và bảo trì, từ thiết kế lược đồ đến mã ứng dụng; chưa kể đến hit hiệu suất.

Trong năm 2014, chúng tôi có quyền truy cập vào nhiều máy chủ cơ sở dữ liệu xử lý các loại dữ liệu cụ thể đặc biệt tốt.

• Mongo (lưu trữ tài liệu)
• Redis (lưu trữ dữ liệu khóa-giá trị)
• MySQL / Maria / PostgreSQL / Oracle / etc (dữ liệu quan hệ)
• CouchDB (JSON)

Tôi chắc chắn rằng tôi đã bỏ lỡ một số người khác, như RabbirMQ và Cassandra. Quan điểm của tôi là, hãy sử dụng đúng công cụ cho dữ liệu bạn cần lưu trữ.

Nếu ứng dụng của bạn yêu cầu lưu trữ và truy xuất nhiều loại dữ liệu thực sự, thực sự nhanh chóng và (và ai không) thì đừng ngại sử dụng nhiều nguồn dữ liệu cho một ứng dụng. Hầu hết các khung công tác web phổ biến đều cung cấp hỗ trợ cho nhiều nguồn dữ liệu (Rails, Django, Grails, Cake, Zend, v.v.). Chiến lược này giới hạn độ phức tạp cho một khu vực cụ thể của ứng dụng, ORM hoặc giao diện nguồn dữ liệu của ứng dụng.

Đây là một hàm sẽ lưu / cập nhật các khóa của mảng JSON trong một cột và một hàm khác truy xuất các giá trị JSON. Các hàm này được tạo với giả định rằng tên cột lưu trữ mảng JSON là json . Nó đang sử dụng PDO .

Lưu / Cập nhật chức năng

function save($uid, $key, $val){
 global $dbh; // The PDO object
 $sql = $dbh->prepare("SELECT `json` FROM users WHERE `id`=?");
 $sql->execute(array($uid));
 $data      = $sql->fetch();
 $arr       = json_decode($data['json'],true);
 $arr[$key] = $val; // Update the value
 $sql=$dbh->prepare("UPDATE `users` SET `json`=? WHERE `id`=?");
 $sql->execute(array(
   json_encode($arr), 
   $uid
 ));
}

Ở đâu $ uid là id của người dùng, $ key - khóa JSON để cập nhật và giá trị của nó được đề cập là $ val .

Hàm nhận giá trị

function get($uid, $key){
 global $dbh;
 $sql = $dbh->prepare("SELECT `json` FROM `users` WHERE `id`=?");
 $sql->execute(array($uid));
 $data = $sql->fetch();
 $arr  = json_decode($data['json'], true);
 return $arr[$key];
}

trong đó $ key là một khóa của mảng JSON mà từ đó chúng ta cần giá trị.

Hỗ trợ sớm cho việc lưu trữ JSON trong MySQL đã được thêm vào bản phát hành MySQL 5.7.7 JSON labs ( mã nhị phân linux , nguồn )! Bản phát hành dường như đã phát triển từ một loạt các chức năng liên quan đến JSON do người dùng xác định được công khai vào năm 2013 .

Hỗ trợ JSON nguyên gốc non trẻ này dường như đang đi theo một hướng rất tích cực, bao gồm xác thực JSON trên INSERT, một định dạng lưu trữ nhị phân được tối ưu hóa bao gồm bảng tra cứu trong phần mở đầu cho phép hàm JSN_EXTRACT thực hiện tra cứu nhị phân thay vì phân tích cú pháp trên mọi truy cập. Ngoài ra còn có một loạt các chức năng mới để xử lý và truy vấn các kiểu dữ liệu JSON cụ thể:

CREATE TABLE users (id INT, preferences JSON);

INSERT INTO users VALUES (1, JSN_OBJECT('showSideBar', true, 'fontSize', 12));

SELECT JSN_EXTRACT(preferences, '$.showSideBar') from users;

+--------------------------------------------------+
| id   | JSN_EXTRACT(preferences, '$.showSideBar') |
+--------------------------------------------------+
| 1    | true                                      |
+--------------------------------------------------+

IMHO, trên đây là một trường hợp sử dụng tuyệt vời cho chức năng mới này; nhiều cơ sở dữ liệu SQL đã có một bảng người dùng và thay vì thực hiện các thay đổi lược đồ vô tận để phù hợp với một nhóm sở thích người dùng đang phát triển, việc có một cột JSON duy nhất JOINlà hoàn hảo. Đặc biệt là vì nó không bao giờ cần phải được truy vấn cho các mục riêng lẻ.

Trong khi nó vẫn còn những ngày đầu, nhóm máy chủ MySQL đang làm một công việc tuyệt vời của giao tiếp những thay đổi trên các diễn đàn .

Tôi tin rằng việc lưu trữ JSON trong cơ sở dữ liệu mysql trên thực tế không đánh bại mục đích sử dụng RDBMS như nó được dự định sử dụng. Tôi sẽ không sử dụng nó trong bất kỳ dữ liệu nào sẽ bị thao túng vào một thời điểm nào đó hoặc được báo cáo, vì nó không chỉ làm tăng thêm độ phức tạp mà còn có thể dễ dàng ảnh hưởng đến hiệu suất tùy thuộc vào cách nó được sử dụng.

Tuy nhiên, tôi tò mò không biết có ai khác nghĩ ra lý do khả dĩ để thực sự làm điều này không. Tôi đã suy nghĩ để tạo một ngoại lệ cho mục đích ghi nhật ký. Trong trường hợp của tôi, tôi muốn ghi lại các yêu cầu có số lượng thông số và lỗi thay đổi. Trong tình huống này, tôi muốn sử dụng các bảng cho loại yêu cầu và bản thân các yêu cầu với một chuỗi JSON có các giá trị khác nhau đã nhận được.

Trong tình huống trên, các yêu cầu được ghi lại và không bao giờ được thao tác hoặc lập chỉ mục trong trường chuỗi JSON. TUY NHIÊN, trong một môi trường phức tạp hơn, tôi có thể sẽ cố gắng sử dụng thứ gì đó có ý định hơn đối với loại dữ liệu này và lưu trữ nó với hệ thống đó. Như những người khác đã nói, nó thực sự phụ thuộc vào những gì bạn đang cố gắng hoàn thành, nhưng việc tuân theo các tiêu chuẩn luôn giúp kéo dài tuổi thọ và độ tin cậy!

JSON cũng là một kiểu dữ liệu hợp lệ trong cơ sở dữ liệu PostgreSQL. Tuy nhiên, cơ sở dữ liệu MySQL vẫn chưa chính thức hỗ trợ JSON. Nhưng đó là nướng: http://mysqlserverteam.com/json-labs-release-native-json-data-type-and-binary-format/

Tôi cũng đồng ý rằng có nhiều trường hợp hợp lệ mà một số dữ liệu tốt hơn nên được tuần tự hóa thành một chuỗi trong cơ sở dữ liệu. Lý do chính có thể là khi nó không được truy vấn thường xuyên và khi lược đồ của chính nó có thể thay đổi - bạn không muốn thay đổi lược đồ cơ sở dữ liệu tương ứng với nó. Lý do thứ hai là khi chuỗi được tuần tự hóa trực tiếp từ các nguồn bên ngoài, bạn có thể không muốn phân tích cú pháp tất cả chúng và cấp dữ liệu trong cơ sở dữ liệu bằng bất kỳ giá nào cho đến khi bạn sử dụng bất kỳ. Vì vậy, tôi sẽ chờ bản phát hành MySQL mới hỗ trợ JSON vì khi đó sẽ dễ dàng hơn cho việc chuyển đổi giữa các cơ sở dữ liệu khác nhau.

Tôi sử dụng json để ghi lại bất cứ thứ gì cho một dự án, tôi sử dụng ba bảng trên thực tế! một cho dữ liệu trong json, một cho chỉ mục của mỗi siêu dữ liệu của cấu trúc json (mỗi meta được mã hóa bởi một id duy nhất) và một cho người dùng phiên, vậy thôi. Điểm chuẩn không thể được định lượng ở trạng thái ban đầu của mã này, nhưng để ví dụ, tôi là lượt xem của người dùng (kết hợp bên trong với chỉ mục) để nhận được một danh mục (hoặc bất kỳ thứ gì, với tư cách là người dùng, ...) và nó rất chậm (rất chậm , chế độ xem được sử dụng trong mysql không phải là cách tốt). Mô-đun tìm kiếm, trong cấu trúc này, có thể làm bất cứ điều gì tôi muốn, nhưng tôi nghĩ mongodb sẽ hiệu quả hơn trong khái niệm bản ghi dữ liệu json đầy đủ này. Đối với ví dụ của tôi, tôi sử dụng các lượt xem để tạo cây danh mục và breadcrumb, chúa ơi! rất nhiều truy vấn để làm! apache tự biến mất! và trên thực tế, đối với trang web nhỏ này, tôi biết một php tạo cây và breadcrumb, việc trích xuất dữ liệu được thực hiện bởi mô-đun tìm kiếm (người chỉ sử dụng chỉ mục), bảng dữ liệu chỉ được sử dụng để cập nhật. Nếu tôi muốn, tôi có thể hủy tất cả các chỉ mục và tạo lại nó với từng dữ liệu, và làm ngược lại, chẳng hạn như hủy tất cả dữ liệu (json) và chỉ tạo lại nó với bảng chỉ mục. Dự án của tôi còn non trẻ, đang chạy dưới php và mysql, nhưng, đôi khi tôi sử dụng nút js và mongodb sẽ hiệu quả hơn cho dự án này.

Sử dụng json nếu bạn nghĩ rằng bạn có thể làm, chỉ để làm điều đó, bởi vì bạn có thể! và, hãy quên nó đi nếu nó là một sai lầm; thử bằng cách đưa ra lựa chọn tốt hoặc xấu, nhưng hãy thử!

Thấp

một người dùng pháp

Tôi biết điều này thực sự đã muộn nhưng tôi đã gặp phải tình huống tương tự khi tôi sử dụng phương pháp kết hợp duy trì các tiêu chuẩn RDBMS của việc chuẩn hóa bảng cho đến một điểm và sau đó lưu trữ dữ liệu trong JSON dưới dạng giá trị văn bản ngoài thời điểm đó. Vì vậy, ví dụ, tôi lưu trữ dữ liệu trong 4 bảng tuân theo các quy tắc chuẩn hóa RDBMS. Tuy nhiên, trong bảng thứ 4 để chứa giản đồ động, tôi lưu trữ dữ liệu ở định dạng JSON. Mỗi khi tôi muốn truy xuất dữ liệu, tôi lấy dữ liệu JSON, phân tích cú pháp và hiển thị nó trong Java. Điều này đã làm việc cho tôi cho đến nay và để đảm bảo rằng tôi vẫn có thể lập chỉ mục các trường mà tôi chuyển đổi thành dữ liệu json trong bảng theo cách chuẩn hóa bằng cách sử dụng ETL. Điều này đảm bảo rằng trong khi người dùng đang làm việc trên ứng dụng, anh ta phải đối mặt với độ trễ tối thiểu và các trường được chuyển đổi sang định dạng thân thiện với RDBMS để phân tích dữ liệu, v.v.

Bạn có thể sử dụng ý chính này: https://gist.github.com/AminaG/33d90cb99c26298c48f670b8ffac39c3

Sau khi cài đặt nó vào máy chủ (chỉ cần đặc quyền root chứ không phải siêu), bạn có thể làm như sau:

select extract_json_value('{"a":["a","2"]}','(/a)')

Nó sẽ trả về a 2 . Bạn có thể trả lại bất cứ thứ gì bên trong JSON bằng cách sử dụng cái này. Phần tốt là nó hỗ trợ MySQL 5.1,5.2,5.6. Và bạn không cần phải cài đặt bất kỳ tệp nhị phân nào trên máy chủ.

Dựa trên dự án cũ common-schema, nhưng nó vẫn đang hoạt động cho đến ngày nay https://code.google.com/archive/p/common-schema/