Chỉ cần một lưu ý. Quy tắc thứ hai này [thực ra là quy tắc thứ 3 - bắt đầu đánh số, theo phong cách đam mê thực sự, từ 0] sẽ gợi ý rằng các mảng không có chỗ trong một hệ thống quan hệ, tuy nhiên không có lý do gì mà một mảng không thể được coi là "nguyên tử". Một chuỗi [ví dụ một mảng ký tự trong C] có thể được coi là nguyên tử, tại sao không phải là một mảng số [hoặc kiểu dữ liệu khác]
Cũng cần phải nhận ra rằng các mảng có thể rất hữu ích và tương ứng với các thực thể trong đời thực, do đó, việc đưa vào loại mảng và chức năng của người phục vụ sẽ không gây ngạc nhiên đối với "những người theo chủ nghĩa hiện thực". Các quy tắc của Codd được bắt nguồn từ các nghiên cứu của ông về phép tính quan hệ và một số người nói rằng việc triển khai hoàn chỉnh sẽ là quá khó đối với các RDBMS trong thế giới thực. Tuy nhiên, chúng tôi đang trôi ra khỏi phạm vi
Tôi cho rằng câu trả lời cho câu hỏi này là không - có một lựa chọn tốt hơn ở cả 3 cấp độ để xử lý mảng trong máy chủ cơ sở dữ liệu
- mảng đơn giản. ==============
MySQL không thực sự có kiểu dữ liệu mảng - thứ gần nhất mà họ có là kiểu dữ liệu SET, chức năng của nó rất hạn chế. Như bạn lưu ý trong câu hỏi của mình, một tìm kiếm dẫn đến nhiều liên kết đến mã PHP thực hiện chức năng mảng trong ứng dụng thay vì db
PostgreSQL có kiểu dữ liệu ARRAY với nhiều hàm để xử lý thao tác, so sánh và tìm phần tử trong mảng. Quan tâm đặc biệt là các hàm UNNEST[] và STRING_TO_ARRAY[]/REGEXP_SPLIT_TO_ARRAY[] cung cấp các phương thức thuận tiện để di chuyển dữ liệu đến và từ các mảng sang các cấu trúc quan hệ
Ngày nay, các mảng đã được thay thế phần lớn bởi JSON - hầu như không ngạc nhiên vì JSON về cơ bản là một mảng ++ [nhưng XML--. -]]. Điều này đúng với MySQL và PostgreSQL
Có một số lượng lớn các hàm JSON có sẵn trên cả hai hệ thống - MySQL và PostgreSQL - nhưng nhiều hơn nữa trên PostgreSQL. Tôi sẽ sử dụng thuật ngữ JSON và JSONB [nhị phân - ví dụ dành cho mongodb nhưng áp dụng chung cho JSON nhị phân] thay thế cho nhau. MySQL JSON chỉ là nhị phân, PostgreSQL có cả hai - nhưng JSONB thường được coi là hiệu quả hơn nhiều. Xem bài đăng này để có một cuộc thảo luận tốt về những loại "NoSQL" của PostgreSQL tốt cho việc gì. "NoSQL" là một cách gọi sai;
Đối với việc lập chỉ mục - Về cơ bản, MySQL thực hiện điều này bằng cách hack cột GENERATED trong khi PostgreSQL triển khai 3 loại chỉ mục [Gin, Btree và Hash - xem phần 8.14.4. jsonb Indexing tại đây] cho JSONB
Các phép nối có thể được thực hiện giữa JSON và các bảng trong cả MySQL và PostgreSQL
Nhìn chung, công bằng mà nói thì JSON đã tồn tại lâu hơn và trưởng thành hơn trong PostgreSQL so với MySQL
Có báo cáo rằng PostgreSQL thực sự có thể hoạt động thậm chí còn tốt hơn MongoDB với các tài liệu JSON - có một lưu ý ở đây là nghiên cứu được thực hiện bởi các công ty [EnterpriseDB và Ongres] là nhà cung cấp PostgreSQL, tuy nhiên các thử nghiệm mà họ thực hiện là nguồn mở và
Tất nhiên, bạn có thể triển khai một số chức năng "đa phần tử" bằng cách sử dụng phương pháp Thực thể liên kết cổ điển. Các thực thể liên kết còn được gọi là các bảng joining, bridging, many-to-many hoặc C0. Chiến lược này được vạch ra ở đây với một ví dụ sử dụng các sinh viên đăng ký các khóa học đại học
1 khóa học có thể có nhiều học viên và 1 học viên có thể tham gia nhiều khóa học. Bảng tham gia chứa C1 từ cả hai bảng C2 và C3 và bản thân C4 của bảng tham gia là cả hai cùng nhau - một học sinh không thể tham gia cùng một khóa học hai lần
Ủng hộ cách tiếp cận cổ điển, Erwin Brandtstetter [một người rất đáng lắng nghe về cơ sở dữ liệu. ] đã chỉ ra trong câu trả lời của anh ấy đề cập đến một giải pháp JSON. [C5]. JSON không phải là thuốc chữa bách bệnh và phán đoán phải được thực hiện khi sử dụng nó. Đã có rất nhiều thay đổi trong những năm gần đây với NoSQL C6 từ ~ 2008 - 2015 [Mongodb đặc biệt xuất hiện trong tâm trí]. Bây giờ hầu như tất cả các hệ thống NoSQL đều có hoặc đang cố gắng đưa các giao diện và công cụ SQL vào hệ thống của họ. Đối với tiền của tôi, nếu các mảng của bạn tương đối đơn giản, hãy sử dụng phương pháp cổ điển, nếu không thì hãy sử dụng JSONB
SQL không được thiết kế và không giỏi thao tác với các danh sách giá trị được phân tách bằng dấu phẩy. Trong mọi trường hợp, họ vi phạm Quy tắc 2 của Quy tắc Codd quy định rằng C7. Với. csv liệt kê một tham số vị trí khác được yêu cầu mà SQL không cung cấp nhưng các hệ thống khác nhau có "thủ thuật" để vượt qua điều này. Sở trường của SQL là các bản ghi "cắt và cắt hạt lựu" được tạo thành từ các dữ liệu nguyên tử đơn giản nhỏ
PostgreSQL là hệ thống F/LOSS [Phần mềm mã nguồn mở và miễn phí] gần nhất để cung cấp tốt nhất cho cả 3 phương thức mảng. MySQL phổ biến hơn và có thể có bản sao và/hoặc sharding bên thứ 3 và sẵn có tốt hơn, nhưng PostgreSQL tuân thủ các tiêu chuẩn hơn và gần đây đã đạt được những bước tiến trong các lĩnh vực đó. Nó cũng có chức năng JSONB vượt trội