정적 데이터를 데이터베이스 또는 다른 곳에 저장해야합니까?

현재 일부 소프트웨어를 개발 중이며 어떤 경로를 사용 해야할지 잘 모르겠습니다. 모바일 장치의 어딘가에 저장할 데이터가 있습니다. 데이터는 변경되지 않으며 계층 적 관계가 있으며 디스플레이를 채우는 데 사용됩니다. 이 데이터의 양이 합리적입니다.

다음과 같은 옵션이 있습니다.

1. 열거 형 / 객체 세트
2. XML 파일
3. 임베디드 SQLite 데이터베이스

이 특별한 경우 enums 옵션이 가장 효과가 없다고 생각하지만 코드에 포함 된 데이터에서 냄새가납니다.

XML 파일은 내가 생각하는 가장 의미가 있지만 파싱하면 '절대'변화가 없기 때문에 낭비처럼 보일 수 있습니다.

데이터베이스는 성능 저하가 적어야하지만 정적 데이터에 대해서는 과도한 것으로 보입니다.

올바른 설계 경로는 무엇입니까?

참고 : '절대로'변경하지 않으면 거의 변경되지 않습니다. 해당 데이터는 정부 표준 세트의 모델이므로 향후 어느 시점에서 변경 될 수 있지만 정기적으로 변경되지는 않으며 표준 변경으로 인해 소프트웨어가 자동으로 업데이트되지 않습니다. 요구 사항이 변경 될 수 있습니다.

나는 이것을 위해 객체를 사용할 것이다.

데이터가 변경되지 않으므로 응용 프로그램에 쉽게 저장할 수 있다고 말했습니다. 데이터베이스가 과도하게 사용되어 크기가 커집니다.
XML 파일도 다소 과잉이며 크기도 증가합니다.

내 의견으로는 가장 좋은 옵션은 열거 형 또는 객체 일 것입니다.

절대 바뀌지 않습니까? 좋은 답변을 얻기 전에 실제로 대답해야 할 질문입니다.

변경되지 않는 정적 데이터 (예 : 요일 이름)는 코드에 적합합니다.

실제로 변경되지 않는 데이터 (예 : 서버 DNS 이름)도 코드를 입력하는 것이 좋습니다. 변경이 필요한 경우 코드 업데이트가 거의 없습니다.

변경되지는 않지만 (예 : 주기적 새로 고침 간격 지연) 로컬 구성 저장소 (sqlite 또는 xml, 실제 차이는 없음)와 같이 쉽게 변경할 수있는 위치에서 가장 좋습니다.

스토리지는 거의 문제가되지 않습니다. 절대 또는 거의 변경되지 않는 경우 프로그램 시작시 모든 데이터를 읽고 프로그램 데이터로 캐시 할 수 있습니다. 드물게 변경해야 할 경우 앱을 다시 시작하는 것이 그리 중요하지 않습니다.

일반적으로 "변경하지 않는 것"이 ​​가장 먼저 변경됩니다 ...
데이터베이스 나 다른 외부 시스템 (구성 파일과 같은)을 사용하는지 여부는 필요할 때 쉽고 빠르게 액세스 할 수있는 한 중요하지 않습니다.
어쨌든 이미 데이터베이스가있는 경우 데이터베이스 테이블을 사용하는 경향이 있으며, 응용 프로그램이 배포 된 서버에 대한 파일 시스템 액세스 권한이 없거나 여러 컴퓨터에서 실행되는 사람들이 데이터를 변경해야 할 수도 있습니다. 구성을 동기화해야합니다).
물론 데이터베이스는 모든 것을 보유 할 수는 없습니다. 예를 들어 데이터베이스 자격 증명은 구성 파일과 같은 다른 곳에 저장해야합니다.

데이터를 요구하는 질문은 데이터의 변경 여부가 아닙니다. 당신은 아마 알지 못하며, 그렇게해도 대답이 잘못 될 수 있습니다.

물어볼 질문은 변경 될 때 누가 변경해야하는지입니다.

• 소프트웨어 제작자 : 코드로 작성
• 최종 사용자 : GUI에 옵션이 있습니다
• 다른 사람 (예 : 시스템 통합 자, 국제화 서비스 등) : 데이터베이스 테이블, 파일 또는 의미있는 것 (때로는 확장 API 포함).

화요일은 결코 변할 수 없기 때문에 일반적으로 열거 형이어야합니다. 그러나 미친 독재자가 화요일에 그를 지명하고 그를 요구한다면, 소프트웨어 제작자로서 당신은 그것을 바꾸거나 상어에게 먹이를 주어야 할 것입니다.

당신은 모든 사용자가 그 운명을 피하기 위해 구성 파일을 파거나 데이터베이스 테이블을 모호하게하지 않기를 원하지 않을 것입니다 ...

실제 세계에서 데이터가 나타내는 개체는 변경하지 않아도 "귀하의"데이터를 변경해야 할 수도 있습니다. 전체 앱을 업데이트하지 않고 업데이트 할 수있는 별도의 텍스트 파일을 포함시킬 가치가 있는지 결정해야합니다.

예 :

1. 인쇄상의 오류 / 맞춤법 오류.
2. 실수로 누락되었습니다.
3. 다른 언어로 데이터를 제공하십시오.
4. 사용자가 직접 변경할 수있는 방법을 제공하십시오.

다른 유형의 데이터 구조 변경은 아마도 앱에 대한 업데이트가 필요할 것이므로 이점이 없습니다.

나는 원래이 질문에 대한 이 답변을 stackoverflow 에 작성했지만이 질문에도 동일한 대답이 적용된다고 생각합니다.

Mathias Verraes 의 기사에 문제에 대한 기사가 있습니다 . 그는 UI를 제공하는 개념에서 모델의 가치 객체를 분리하는 것에 대해 이야기합니다.

국가를 엔터티 또는 값 개체로 모델링할지 묻는 경우 기사에서 인용 :

국가를 엔터티로 모델링하고 데이터베이스에 저장하는 것은 본질적으로 잘못된 것은 없습니다. 그러나 대부분의 경우 너무 복잡합니다. 국가는 자주 바뀌지 않습니다. 국가의 이름이 바뀌면 사실상 모든 실제적인 목적을 위해 새로운 국가입니다. 국가가 더 이상 존재하지 않으면 국가가 두 국가로 분할되어 있기 때문에 모든 주소를 변경할 수는 없습니다.

그는 다음과 같은 새로운 개념을 도입하기위한 다른 접근법을 제안했습니다 AvailableCountry.

사용 가능한 국가는 데이터베이스의 엔터티, JSON의 레코드 또는 코드의 하드 코드 된 목록 일 수 있습니다. (비즈니스가 UI를 통해 쉽게 액세스 할 수 있는지 여부에 따라 다릅니다.)

<?php

final class Country
{
    private $countryCode;

    public function __construct($countryCode)
    {
        $this->countryCode = $countryCode;
    }

    public function __toString()
    {
        return $this->countryCode;
    }
}

final class AvailableCountry
{
    private $country;
    private $name;

    public function __construct(Country $country, $name)
    {
        $this->country = $country;
        $this->name = $name;
    }

    /** @return Country */
    public function getCountry()
    {
        return $this->country;
    }

    public function getName()
    {
        return $this->name;
    }

}

final class AvailableCountryRepository
{
    /** @return AvailableCountry[] */
    public function findAll()
    {
        return [
            'BE' => new AvailableCountry(new Country('BE'), 'Belgium'),
            'FR' => new AvailableCountry(new Country('FR'), 'France'),
            //...
        ];
    }

    /** @return AvailableCountry */
    public function findByCountry(Country $country)
    {
        return $this->findAll()[(string) $country];
    }
}

따라서 조회 테이블을 값 객체와 엔티티로 모델링하는 세 번째 솔루션이있는 것 같습니다.

BTW 는 기사에 대한 몇 가지 진지한 논의 를 위해 의견 섹션을 확인 하십시오.

고려해야 할 사항 :

• 데이터는 얼마나 정적인가? 절대 바뀌지 않으면 물체 안에 있어야합니다. 데이터를 변경하려면 다시 컴파일하고 재배치해야 할 수도 있습니다. 사소한 변경을 위해 재배치를하는 것에 만족하십니까?

• 웹 응용 프로그램이고 web.config의 일부로 사용하는 경우 해당 데이터를 변경할 때 응용 프로그램을 다시 시작 하시겠습니까?

• 데이터베이스에 저장하면 클라이언트 측 (데스크톱 애플리케이션) 또는 서버 측 (서비스 또는 웹 사이트)에 언제든지 캐시 할 수 있습니다. 데이터베이스는 좋은 솔루션 IMO 일 수 있습니다.