Làm thế nào để quyết định giữa các định dạng lưu trữ và trường hợp sử dụng ví dụ cho một số trong số chúng là gì?

Chúng tôi có nhiều cách khác nhau để lưu trữ dữ liệu chương trình (lưu tệp trong trò chơi, cơ sở dữ liệu nhân viên, cấu hình chương trình, v.v.):

• Văn bản thuần túy (nghĩ .inivà .conf)
• XML
• Cơ sở dữ liệu (MySQL, SQLite ...)
• .zip và tương tự chứa một số tệp (với các định dạng khác nhau)
• Các tệp nhị phân ( .docví dụ, v.v., ví dụ được tạo bởi một công cụ tuần tự hóa)

Các trường hợp sử dụng khác nhau cho các định dạng được liệt kê ở trên là gì và nhược điểm của chúng là gì (suy nghĩ về tốc độ, tính linh hoạt, kích thước tệp, dễ sử dụng ...)? Làm thế nào để quyết định giữa chúng cho các nhiệm vụ khác nhau?

Giới thiệu về định dạng nén: Điều này chỉ được sử dụng để chứa các tệp khác. Nó có thể là một định dạng nén là tốt. Điều này cho phép cấu trúc của một số tệp, bao gồm tệp hình ảnh, tệp âm thanh và tệp văn bản. Ví dụ: giả sử bạn có định dạng lưu trữ cho thư, có thể chứa tệp. Bạn có thể có các tệp sau trong tệp nén:

message.txt (containing the message)
attachments (folder containing attachments)
  audio.wav
  picture.jpg

Tôi sử dụng như sau:

Văn bản thô

Đối với cấu hình - thường sử dụng YAML hoặc .ini. Không được tôi sử dụng cho hầu hết các mục đích sử dụng trừ khi tệp văn bản là kết quả mong muốn (ví dụ: in thành văn bản, lưu vào văn bản, v.v.)

XML

Đối với cấu hình và vận chuyển dữ liệu; ví dụ: xuất, định dạng qua XSLT, v.v ... Tốt như định dạng tệp di động (ví dụ: SVG). Công cụ thao tác và bộ lọc tuyệt vời.

Cơ sở dữ liệu

Lưu trữ dữ liệu chính từ bên trong ứng dụng / webapp. Sử dụng tất cả thời gian như lưu trữ của sự lựa chọn. Nó đáng tin cậy, mạnh mẽ và bạn được tích hợp rất nhiều (giao dịch, tính toàn vẹn tham chiếu, xóa / cập nhật xếp tầng, chỉ mục, tốc độ). Sử dụng tốt nhất với một lớp, hoặc ORM (IMO).

Lưu trữ tập tin duy nhất (ví dụ .zip)

Thích hợp để lưu trữ nhiều luồng nhị phân liên quan một cách gọn gàng, ví dụ hình ảnh ROM cho trình giả lập. Tốt nhất cho những thứ không thường xuyên hoặc không bao giờ phải cập nhật. Nó nặng, chậm và khó thao tác;

Nhị phân

Chỉ khi cơ sở dữ liệu không có sẵn để lưu trữ dữ liệu ứng dụng. Dễ nhất với tuần tự hóa (C ++). Một định dạng nhị phân được điều chỉnh cao sẽ vượt trội hơn mọi thứ khác về cả tốc độ và kích thước.

Không có viên đạn bạc. Theo kinh nghiệm của tôi:

Văn bản thuần túy như một phương tiện lưu trữ là một số tự động. Một vài trường hợp tôi thậm chí sẽ xem xét nó sẽ được bao phủ tốt hơn bởi một tệp .config nơi tôi có một lược đồ và loại an toàn. Có vẻ như nhu cầu về an toàn và trích xuất dữ liệu hầu như luôn luôn xuất hiện. Văn bản đơn giản làm cho quá trình này là một cơn ác mộng.

XML : Nhập an toàn, xác thực dữ liệu, âm lượng thấp và trong một số trường hợp tôi sử dụng nó vì .NET được tích hợp mạnh mẽ để hỗ trợ tuần tự hóa các đối tượng XML.

Cơ sở dữ liệu : Mặc định của tôi. Loại an toàn, tốc độ, giao dịch, đáng tin cậy và khó có thể đổ lỗi cho việc chọn DB làm phương tiện lưu trữ nếu có gì đó không theo kế hoạch.

.zip là một định dạng nén, không chắc cách này phù hợp với tính bền bỉ ..?

Nhị phân : Tôi chỉ sử dụng nhị phân khi tôi cần tạo một bộ nhớ tạm thời. Nhị phân không thêm giá trị theo cách khả năng truy vấn so với DB hoặc XML nơi dữ liệu của tôi được tổ chức với lược đồ.

Dễ sử dụng là tương đối và phụ thuộc vào những gì cụ thể bạn muốn thực hiện. Tốc độ là tương tự bên ngoài những gì tôi đã nói ở trên về khối lượng. Nếu kích thước tệp là một mối quan tâm và chuẩn hóa đúng được áp dụng, tôi sẽ nén nó thông qua zip hoặc một số định dạng nén khác, nhưng đây là một quá trình riêng biệt.

Tôi sử dụng chúng như sau:

Văn bản thô

Nếu danh mục đó bao gồm các định dạng phức tạp hơn một chút, như YAML hoặc tệp thuộc tính, thì đó là tùy chọn tốt nhất cho bất cứ điều gì bạn mong đợi mọi người đọc và chỉnh sửa bằng tay. Một lợi thế lớn khác là sự đơn giản của việc sửa đổi nó thông qua một tập lệnh nhỏ (ví dụ: sed).

Không có gì đánh bại sự đơn giản và dễ sử dụng. Khi nhóm hỗ trợ phải định cấu hình một cái gì đó trên máy từ xa (ví dụ: giải quyết vấn đề của khách hàng) hoặc CNTT phải cấu hình lại một loạt các máy chủ chạy phần mềm của bạn, họ sẽ cảm ơn bạn vì đã chọn định dạng này. Nó cũng sẽ giúp bạn không phải viết một số phần mềm một lần làm điều đó cho họ.

XML

Tôi đồng ý với @Ingo ở đây - không giống như XML văn bản thuần túy khó xử lý hơn thông qua tập lệnh và một cơn ác mộng để chỉnh sửa bằng tay imo.

Tuy nhiên, nếu bạn có dữ liệu với một số cấu trúc phức tạp trong đó YAML trở nên không thể mã hóa và vẫn muốn nó có thể đọc được và có thể chỉnh sửa được thì XML có lẽ là lựa chọn tốt nhất.

Cơ sở dữ liệu quan hệ

Một lựa chọn tuyệt vời khi bạn có nhiều dữ liệu (sẽ khiến văn bản đơn giản và XML trở nên cồng kềnh) mà bạn vẫn có thể muốn cho phép các bên thứ 3 chỉnh sửa thủ công - thông qua các lệnh SQL và thậm chí cả GUI.

Một ưu điểm khác là mã của bạn quản lý nội dung rất dễ đọc. @ Richard-Harrison đã đưa ra một danh sách tốt các lợi thế khác trong câu trả lời tuyệt vời của mình.

Cơ sở dữ liệu NoQuery

Một lợi thế so với RDBMS là khả năng mở rộng thông qua phân phối, có lẽ không liên quan lắm đến câu hỏi của bạn. Những lợi thế có lẽ phù hợp hơn là sự đơn giản của một cửa hàng khóa-giá trị và tính linh hoạt của tính phân liệt (đây có phải là một từ không?). Khi bạn thấy mình phá vỡ mô hình quan hệ: chỉ cần lưu trữ các đốm màu vào cơ sở dữ liệu, truy cập chúng bằng khóa và xử lý chúng thông qua mã, sau đó xem xét tùy chọn này. Một số lựa chọn (ví dụ CouchDB) rất dễ mang theo, có dấu chân nhỏ và cũng có thể mở rộng quy mô để chúng cung cấp một sự thay thế không liên quan tốt đến MySQL và SQLite.

Nhị phân

Ưu điểm của nhị phân là nhanh và gọn. Khi điều duy nhất cần đọc và sửa đổi tệp của bạn là một chương trình và dữ liệu không phù hợp với mô hình quan hệ hoặc tốc độ thực sự quan trọng thì đây có thể là một lựa chọn tốt. Có lẽ là phù hợp nhất cho các tập tin phương tiện truyền thông.

Tôi nên chỉ ra rằng tôi chưa gặp phải trường hợp truy cập đơn giản vào dữ liệu chương trình tại một số điểm vì những lý do không được xem xét trong thiết kế ban đầu. Ngày nay, cá nhân tôi chọn tùy chọn cơ sở dữ liệu cho bất kỳ thứ gì khác sau đó các tệp có định dạng chuẩn và cần được mã hóa / giải mã bằng phần mềm khác (ví dụ: âm thanh, video).

Lưu ý: có một quan niệm sai lầm phổ biến rằng nhị phân là mờ đục và do đó bằng cách nào đó an toàn hơn. Nếu không có sự bảo vệ bổ sung thì không - nếu ai đó muốn hack phần mềm của bạn thì chỉ cần lưu trữ cấu hình của bạn hoặc bất cứ thứ gì trong nhị phân sẽ không ngăn chặn chúng.

Lưu trữ nén

Không thực sự là một thay thế cho ở trên, mà là một biện pháp bổ sung.

Thuận lợi khi bạn cần truyền tải mọi thứ qua mạng hoặc khi bạn lưu trữ rất nhiều dữ liệu và muốn tiết kiệm dung lượng. Lưu ý rằng không gian lưu trữ thường rất phong phú trong những ngày này, vì vậy hãy xem xét nền tảng mục tiêu của bạn.

Thực hiện rất nhanh trên hầu hết mọi thứ ngày nay (luật hành động của Moore, em bé), vì vậy lý do duy nhất để không sử dụng nó là nó làm tăng thêm sự phức tạp cho mã của bạn. Không phức tạp lắm, nhưng vẫn vi phạm nguyên tắc KISS. Đặc biệt cồng kềnh đối với các tệp cấu hình cần được chỉnh sửa thủ công hoặc thông qua tập lệnh - và nếu bạn thực sự cần tiết kiệm dung lượng ở đó, thì có lẽ bạn nên sử dụng tùy chọn cơ sở dữ liệu.

Tôi sẽ sử dụng chúng như sau:

• Văn bản thuần túy : Ứng dụng có kích thước nhỏ của dữ liệu có cấu trúc đơn giản (cặp giá trị tên cho ví dụ cũ). Dữ liệu không được sửa đổi đồng thời bởi nhiều người dùng.
• XML : Kích thước nhỏ của dữ liệu có cấu trúc không được sửa đổi đồng thời hoặc thường xuyên.
• Cơ sở dữ liệu : dữ liệu có cấu trúc lớn hoặc truy cập đồng thời là cần thiết. Cần cho truy vấn và tìm kiếm là phải trong ứng dụng.
• Dữ liệu nhị phân : Tôi sẽ sử dụng nó chỉ cho các đối tượng truyền phát.
• nén là nén có thể được thêm vào như là một quá trình khác cho bất kỳ điều nào ở trên trừ cơ sở dữ liệu trên máy chủ.

Tôi đã nghe nói rằng XML kết hợp các tính năng tồi tệ nhất của văn bản (khó / chậm xử lý) và nhị phân (không thể đọc được).