스토리지 형식을 결정하는 방법과 그 중 일부에 대한 사용 사례는 무엇입니까?

프로그램 데이터를 저장하는 방법에는 여러 가지가 있습니다 (파일을 게임, 직원 데이터베이스, 프로그램 구성 등에 저장).

• 일반 텍스트 (생각 .ini및 .conf)
• XML
• 데이터베이스 (MySQL, SQLite ...)
• .zip 여러 파일을 포함하는 유사한 파일 (형식이 다름)
• 이진 파일 ( .doc예 : 직렬화 도구로 만든 것 등)

위에 나열된 형식에 대한 다양한 사용 사례는 무엇이며 장점 단점 (속도, 유연성, 파일 크기, 사용 편의성 등)은 무엇입니까? 다른 작업을 위해 그들 사이를 결정하는 방법?

압축 형식 정보 : 다른 파일을 포함하는 데만 사용됩니다. 다른 압축 형식 일 수도 있습니다. 이는 이미지 파일, 사운드 파일 및 텍스트 파일을 포함한 여러 파일의 구조를 허용합니다. 예를 들어, 파일을 포함 할 수있는 메시지의 스토리지 형식이 있다고 가정하십시오. 압축 파일 안에 다음 파일이있을 수 있습니다.

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

다음과 같이 사용합니다.

일반 텍스트

구성의 경우 일반적으로 YAML 또는 .ini를 사용합니다. 텍스트 파일이 원하는 결과 인 경우를 제외하고 대부분의 용도로는 사용되지 않습니다 (예 : 텍스트로 인쇄, 텍스트로 저장 등).

XML

데이터 구성 및 전송 예 : 내보내기, XSLT 등을 통한 형식화. 휴대용 파일 형식 (예 : SVG)으로 적합합니다. 뛰어난 조작 도구 및 필터.

데이터베이스

app / webapp 내부의 기본 데이터 스토리지 항상 선택한 스토리지로 사용하십시오. 신뢰할 수 있고 강력하며 트랜잭션, 참조 무결성, 계단식 삭제 / 업데이트, 색인, 속도 등 많은 기능이 내장되어 있습니다. 레이어 또는 ORM (IMO)과 함께 사용하는 것이 가장 좋습니다.

단일 파일 아카이브 (예 : .zip)

관련된 다중 이진 스트림을 컴팩트하게 저장하는 데 적합합니다 (예 : 에뮬레이터의 ROM 이미지). 자주 업데이트되지 않아도되는 업데이트에 적합합니다. 그것은 무겁고 느리고 조작하기 어렵다.

이진

앱 데이터를 저장할 수있는 데이터베이스가없는 경우에만 해당됩니다. 직렬화가 가장 쉽습니다 (C ++). 높게 조정 된 이진 형식은 속도와 크기면에서 다른 모든 것보다 성능이 뛰어납니다.

총알이 없습니다. 내 경험상 :

저장 매체로서의 일반 텍스트 는 자동 번호입니다. 심지어 스키마와 유형 안전이있는 .config 파일로 더 잘 다루는 경우도 있습니다. 형식 안전과 데이터 추출에 대한 필요성이 거의 항상 제기되는 것 같습니다. 일반 텍스트는이 과정을 악몽으로 만듭니다.

XML : 형식 안전성, 데이터 유효성 검사, 낮은 볼륨 및 .NET에는 객체의 XML 직렬화 지원 기능이 강력하게 내장되어 있기 때문에 경우에 따라 사용합니다.

데이터베이스 : 내 기본값. 계획에 따라 문제가 발생하지 않으면 안전, 속도, 트랜잭션, 신뢰성이 높고 DB를 스토리지 미디어로 선택하는 데 대한 책임을지기 어려운 유형을 입력하십시오.

.zip 은 압축 형식이며 이것이 지속성에 어떻게 적합한 지 잘 모르겠습니다 ..?

이진 : 임시 메모리 스트림을 만들어야 할 때만 이진을 사용합니다. 이진은 내 데이터가 스키마로 구성된 DB 또는 XML에 비해 쿼리 기능에 가치를 더하지 않습니다.

사용 편의성은 상대적이며 달성하고자하는 대상에 따라 다릅니다. 볼륨과 관련하여 위에서 말한 것 이외의 속도는 비슷합니다. 파일 크기가 중요하고 적절한 정규화가 적용되면 zip 또는 다른 압축 형식을 통해 압축하지만 별도의 프로세스입니다.

다음과 같이 사용합니다.

일반 텍스트

해당 카테고리에 YAML 또는 특성 파일과 같이 좀 더 정교한 형식이 포함 된 경우 사람들이 직접 읽고 편집 할 수있는 모든 옵션에 가장 적합한 옵션입니다. 또 다른 큰 장점은 작은 스크립트 (예 : sed)를 통해 간단하게 수정할 수 있다는 것입니다.

단순성과 사용 편의성을 능가하는 것은 없습니다. 지원 팀이 원격 시스템에서 무언가를 구성해야하거나 (예 : 클라이언트 문제 해결) IT가 소프트웨어를 실행하는 여러 서버를 재구성해야하는 경우이 형식을 선택해 주셔서 감사합니다. 또한 일회성 소프트웨어를 작성하지 않아도됩니다.

XML

일반 텍스트 XML이 스크립팅을 통해 처리하기가 어렵고 수동으로 편집하는 악몽과 달리 @Ingo에 동의합니다.

그럼에도 불구하고 YAML을 해독 할 수없는 정교한 구조의 데이터가 있고 여전히 사람이 읽고 편집 할 수있게하려면 XML이 최선의 선택 일 것입니다.

관계형 데이터베이스

SQL 명령 및 GUI를 통해 타사에서 수동으로 편집 할 수있는 데이터가 많을 때 (일반 텍스트와 XML을 번거롭게하는 경우) 적합한 선택입니다.

또 다른 장점은 내용을 관리하는 코드를 읽을 수 있다는 것입니다. @ Richard-Harrison은 그의 훌륭한 답변에서 다른 장점의 좋은 목록을 제공했습니다.

NoSQL 데이터베이스

RDBMS에 비해 한 가지 장점은 배포를 통한 확장 성입니다. 이는 아마도 귀하의 질문과 관련이 없을 것입니다. 아마도 더 관련성이 높은 장점은 키-값 저장소의 단순성과 스키마없는 유연성 (이것이 단어입니까?)입니다. 관계형 패러다임을 깨뜨리는 경우 : 데이터베이스에 Blob을 저장하고 키로 액세스하고 코드를 통해이를 처리 한 다음이 옵션을 고려하십시오. 일부 선택 (예 : CouchDB)은 이식성이 뛰어나고 설치 공간이 작으며 확장 가능하여 MySQL 및 SQLite에 대한 비 관계형 대안을 제공합니다.

이진

바이너리의 장점은 빠르고 컴팩트하다는 것입니다. 파일을 읽고 수정해야하는 유일한 프로그램이 프로그램이고 데이터가 관계형 패러다임이나 속도에 맞지 않는 것이 정말로 중요한 경우에는 이것이 좋은 선택 일 수 있습니다. 미디어 파일에 가장 적합합니다.

초기 설계 중에 고려되지 않은 이유로 인해 프로그램 데이터에 대한 간단한 액세스가 필요하지 않은 경우가 아직 발생하지 않았 음을 지적해야합니다. 요즘 나는 표준 형식을 가지며 다른 소프트웨어 (예 : 오디오, 비디오)로 인코딩 / 디코딩 해야하는 파일 이외의 다른 데이터베이스 옵션을 개인적으로 선택합니다.

참고 : 바이너리가 불투명하고 어쨌든 더 안전하다는 일반적인 오해가 있습니다. 추가 보호가 없으면 소프트웨어를 해킹하려는 경우 구성을 바이너리 또는 바이너리로 저장하면 중단되지 않습니다.

압축 아카이브

실제로 위의 대안이 아니라 추가 조치입니다.

네트워크를 통해 전송해야하거나 많은 양의 데이터를 저장하고 공간을 절약하려는 경우에 유리합니다. 요즘에는 스토리지 공간이 풍부하므로 대상 플랫폼을 고려하십시오.

오늘날 거의 모든 것 (무어의 법칙, 베이비)에서 매우 빠르게 수행되므로이를 사용하지 않는 유일한 이유는 코드에 복잡성을 더하기 때문입니다. 복잡하지는 않지만 KISS 원칙을 여전히 위반합니다. 특히 수동으로 또는 스크립팅을 통해 편집해야하는 구성 파일의 경우 번거 롭습니다. 실제로 공간을 절약해야하는 경우 데이터베이스 옵션을 사용해야합니다.

다음과 같이 사용합니다.

• 일반 텍스트 : 응용 프로그램에는 작은 크기의 구조화 된 데이터가 있습니다 (예 : 이름 값 쌍). 여러 사용자가 동시에 데이터를 수정하지 않습니다.
• XML : 동시에 또는 자주 수정되지 않는 작은 크기의 구조화 된 데이터.
• 데이터베이스 : 큰 구조적 데이터 또는 동시 액세스가 필요합니다. 응용 프로그램에서 조회 및 검색이 필요합니다.
• 이진 데이터 : 스트리밍 객체에만 사용합니다.
• 압축 은 서버의 데이터베이스를 제외한 위의 모든 프로세스에 대해 다른 프로세스로 추가 될 수있는 압축입니다.

XML은 최악의 텍스트 기능 (처리하기 어렵거나 느리게 처리됨)과 바이너리 (읽을 수 없음)를 결합한다고 들었습니다.