Trước hết, bạn thực sự không muốn làm điều đó. Một cột trong RDBMS có nghĩa là nguyên tử, trong đó nó chứa một và chỉ một phần thông tin. Cố gắng lưu trữ nhiều hơn một phần dữ liệu trong một cột là vi phạm hình thức thông thường đầu tiên.
Nếu bạn nhất thiết phải làm điều đó, thì bạn cần chuyển đổi dữ liệu thành một biểu mẫu có thể được lưu trữ dưới dạng một mục dữ liệu, điển hình là một chuỗi. Bạn có thể sử dụng cơ chế serialize () của PHP, phân tích cú pháp XML (nếu dữ liệu là một cây tài liệu), json_encode (), v.v.
Nhưng làm thế nào để bạn truy vấn dữ liệu như vậy một cách hiệu quả? Câu trả lời là bạn không thể.
Ngoài ra, nếu một ngày nào đó người khác tiếp quản dự án của bạn, bạn thực sự sẽ làm phiền họ, bởi vì dữ liệu được tuần tự hóa trong cơ sở dữ liệu rất khó làm việc. Tôi biết vì tôi đã kế thừa những dự án như vậy.
Tôi đã đề cập đến bạn thực sự không muốn làm điều đó? Bạn cần phải suy nghĩ lại thiết kế của mình để có thể dễ dàng lưu trữ nó dưới dạng các hàng nguyên tử. Ví dụ:sử dụng một bảng khác cho dữ liệu này và sử dụng các khóa ngoại để liên kết nó với bản ghi chính. Chúng được gọi là cơ sở dữ liệu quan hệ vì một lý do.
CẬP NHẬT :Tôi đã được hỏi về các yêu cầu lưu trữ dữ liệu, chẳng hạn như liệu một hàng đơn lẻ có rẻ hơn về mặt lưu trữ hay không. Câu trả lời là, trong những trường hợp điển hình là không thì không, và trong những trường hợp câu trả lời là có thì cái giá bạn phải trả cho nó không đáng phải trả.
Nếu bạn sử dụng bảng phụ thuộc 2 cột (1 cột cho khóa ngoại của bản ghi mà mẫu thuộc về, một cột cho một mẫu đơn) thì mỗi cột sẽ yêu cầu tối đa là 16 byte (8 byte cho cột khóa dài, 8 byte cho một số dấu phẩy động chính xác kép). Đối với 100 bản ghi có 1600 byte (bỏ qua chi phí db).
Đối với một chuỗi được tuần tự hóa, bạn lưu trữ trong trường hợp tốt nhất là 1 byte cho mỗi ký tự trong chuỗi. Bạn không thể biết chuỗi sẽ dài bao lâu, nhưng nếu chúng tôi giả sử 100 mẫu với tất cả dữ liệu được lưu trữ bởi một số trùng hợp có sẵn, tất cả đều nằm trong khoảng từ 10000,00 đến 99999,99 với chỉ 2 chữ số sau dấu thập phân, thì bạn ' đang xem xét 8 byte cho mỗi mẫu. Trong trường hợp này, tất cả những gì bạn đã lưu là chi phí của các khóa ngoại, vì vậy dung lượng lưu trữ cần thiết là 800 byte.
Tất nhiên, điều đó dựa trên nhiều giả định, chẳng hạn như mã hóa ký tự luôn là 1 byte cho mỗi ký tự, các chuỗi tạo nên các mẫu không bao giờ dài hơn 8 ký tự, v.v.
Nhưng tất nhiên cũng có chi phí của bất kỳ cơ chế nào bạn sử dụng để tuần tự hóa dữ liệu. Phương pháp đơn giản nhất tuyệt đối, CSV, có nghĩa là thêm dấu phẩy vào giữa mọi mẫu. Điều đó thêm n-1 byte vào chuỗi được lưu trữ. Vì vậy, ví dụ trên bây giờ sẽ là 899 byte, và đó là với sơ đồ mã hóa đơn giản nhất. Các tuần tự hóa JSON, XML, thậm chí PHP đều thêm nhiều ký tự trên đầu hơn thế này và bạn sẽ sớm có các chuỗi dài hơn 1600 byte rất nhiều. Và tất cả điều này là với giả định về mã hóa ký tự 1 byte.
Nếu bạn cần lập chỉ mục các mẫu, các yêu cầu dữ liệu sẽ tăng lên không cân đối hơn so với các chuỗi, bởi vì chỉ mục chuỗi đắt hơn rất nhiều về mặt lưu trữ so với chỉ mục cột dấu phẩy động.
Và tất nhiên nếu các mẫu của bạn bắt đầu thêm nhiều chữ số hơn, thì dung lượng lưu trữ dữ liệu sẽ tăng thêm. 39281.3392810 sẽ không được lưu trữ trong 8 byte dưới dạng một chuỗi, ngay cả trong trường hợp tốt nhất.
Và nếu dữ liệu được tuần tự hóa, cơ sở dữ liệu không thể thao tác. Bạn không thể sắp xếp các mẫu, thực hiện bất kỳ loại phép toán nào trên chúng, cơ sở dữ liệu thậm chí không biết chúng là số!
Thành thật mà nói, ngày nay dung lượng lưu trữ rất rẻ, bạn có thể mua nhiều ổ đĩa TB với số tiền nhỏ. Bộ nhớ có thực sự quan trọng không? Trừ khi bạn có hàng trăm triệu bản ghi thì tôi nghi ngờ là như vậy.
Bạn có thể muốn xem một cuốn sách có tên là SQL Antipatterns
