거의 변하지 않는 "합리적으로 큰"양의 데이터를 저장하는 실용적인 방법은 무엇입니까?

사전 계산 된 룩업 테이블 또는 다른 측면에서 생각하십시오. 내 응용 프로그램에서 값을 하드 코딩하는 대신 데이터베이스를 사용하는 것이 더 합리적입니까? 가치는 변하지 않을 것이며 유지 보수 개발자 들과는 분리되어 있습니다. 100 개의 값, 1k, 10k, 100k? 약 40k 값을 저장하고 싶습니다. 현재 이것은 기계 생성 switch진술입니다 (VS2010은 불행합니다).

편집하다:

궁금한 사람이 있다면 여기에 접근 한 방법이 있습니다. 내 데이터는 두 개의 100k 요소 부동 소수점 배열로 저장 가능하므로 이것이 내가 한 일입니다. 데이터를 생성하는 데 약 20 초가 걸렸으므로 한 번 수행하고 BinaryFormatter를 사용하여 포함 된 리소스로 직렬화했습니다. 응용 프로그램을 시작할 때 데이터 압축을 풀 때 약 5 밀리 초가 걸리고 내가 대체했던 데이터베이스 구현 (이러한 하드 코딩 된 값이 이전에 저장된 값)보다 거의 45,000 배나 뛰어납니다.

내 제안은 데이터를 파일 또는 데이터베이스 테이블에 보관하는 것입니다. 속도가 문제가되지 않으면 런타임에 파일 또는 데이터베이스를 쿼리하십시오 (데이터베이스가 더 좋습니다). 메모리에 문제가 없지만 속도를 원한다면 프로그램이 시작될 때 데이터를 메모리에로드하십시오. C #에서는 해시 테이블을 사용하고 배열, 나열 또는 (최상의 옵션) 런타임에 필요한 데이터를 반환하는 메소드 (예 : getDataValue (string keyToValue))를 가질 수 있습니다.

유지 관리가 매우 어려워 EXE 실행 공간이 커질 수 있으므로 switch 문을 사용하지 않는 것이 좋습니다.

해시 테이블 (예 : http://support.microsoft.com/kb/309357)

개인적으로, 하나의 특정 배포 또는 핫픽스를 위해 데이터를 조정할 필요가 없을 때까지 응용 프로그램에 하드 코딩 된 모든 양의 데이터를 저장하는 것이 좋습니다.

그러나 C # switch 문을 사용하여 데이터를 저장하고 액세스하는 것은 데이터 저장 및 데이터 액세스 모델을 밀접하게 결합하고 스위치 매개 변수 별 한 가지 방법 액세스 방법 만 암시하기 때문에 다소 좋지 않습니다.

데이터를 Hashtable 또는 Dictionary에 저장하고 데이터를 검색하기위한 별도의 클래스를 제공하고 조회 사전을 한 번 채우는 것을 선호합니다.

최근에는 비즈니스 규칙을 지정하기 위해 작은 DSL ( SiteMap에 대한 유창한 인터페이스 또는 규칙 방어에 대한 세금 계산기 인터뷰 질문 확인 "calc"방법)을 구현 한 다음 이러한 규칙을 쿼리하기위한 별도의 개체를 제공하는 것이 다소 편리한 것으로 나타났습니다 . 이 기법은 스위치 케이스 시나리오에 적합합니다.

이러한 분해의 장점 중 하나는 XXXk 행 얼룩을 건드리지 않고 해당 데이터를 정의하는 데이터에 여러보기를 구현할 수 있다는 것입니다.

40k 라인 스위치 문은 약간 의문의 여지가 있습니다. 여전히 쿼리 작업을 올바르게 수행해야한다고 가정합니까? 데이터 캡슐화를 시도 했습니까? 그런 다음 LINQ를 사용하여 컬렉션에서 쿼리 작업을 수행하여 성능을 테스트하십시오. StopWatch 와 같은 타이머로 단위 테스트를 실행하여 구체적인 시간을 얻으십시오 . 그렇다면 당신은 그것이 효과가 있다고 생각한다면. 사용자에게 성능이 적합한 지 확인하십시오.

나는이 같은 요구 사항을 두 번 가지고있다. 응용 프로그램은 데이터베이스 설정 / 액세스가 필요없는 독립형으로 설계되었습니다. 두 경우 모두 XML 파일을 사용하여 데이터를 저장했습니다. 2.0 프레임 워크에 있던 첫 번째 스타일에서는 구식 XML 구문 분석 호출을 사용하여 데이터를 검색했습니다. 최신 버전 인 3.5 프레임 워크에서는 LINQ to XML을 사용하여 필요한 것을 찾았습니다. 두 경우 모두 데이터에 대한 액세스가 클래스로 캡슐화되었습니다.

여기서 중요한 것은 퍼블릭 인터페이스가 구현을 캡슐화하는지 확인하는 것입니다. 그러나 그것은 귀하의 질문이 아니며 귀하가 그렇지 않다고 생각할 이유가 없습니다. 그 외에도 성능 대 슬픔의 문제 일뿐입니다 (성능 차이는 신경 쓰지 않아도됩니다). 실용적인 해결책으로 VS 2010 문제의 경우 항상 사례 진술을 사례 진술의 계층 구조로 나눌 수 있습니다. 예를 들어 최상위 수준에서는 각각 사례가 4000 건인 10 개의 다른 방법 중 하나를 호출 할 수 있습니다. 필요한 경우 10 개 각각을 자체 파일에 넣을 수 있습니다. 조금 추악하지만 어쨌든 코드 생성 중입니다.

DB로 전환하는 숫자는 DB를 사용하지 않을 때마다 문제가됩니다.

SQL Compact와 같은 것을 사용할 수 있습니다. 데이터를 테이블에 넣고 DB 파일을 프로젝트에 그대로 둡니다. 테이블은 switch 문보다 해당 양의 데이터에 더 적합합니다.

여기서 핵심 단어는 '거의'가 아니라고 생각합니다

사전 계산 된 수학적 값, 색상 상수 등과 같이 데이터가 변경 되지 않으면 크기를 관리 할 수있는 한 코드에 보관하십시오. 성능에 문제가 있으면 다른 옵션에 비해 case / switch 문이 매우 느리다는 점에 유의하십시오.

전화 지역 코드, 국가 경계 등과 같이 데이터가 거의 변경 되지 않는 경우 데이터를 외부 방식으로 유지하려고합니다. 특히 그것이 수십 개 이상의 가치를 가지기 시작했다면.

많은 양의 데이터를 응용 프로그램에 저장하면 프로그램이 느리게로드되고 일부 파일이 이진 파일이나 실행 파일로 재생 될 수있는 경우 코드가 노출 될 수 있습니다.

또한 프로그램을 여러 번 편집하면 실수로 또는 변경 명령의 결과로 숫자를 잘못 입력하여 오류가 발생할 수 있습니다.

미래에 누군가가 데이터에 대해 쿼리를 실행하도록 요청할 수 있습니다. 예를 들어 누군가 열의 평균을 요청할 수 있습니다.이 경우 응용 프로그램을 변경하고 사용자가 등장하는 모든 쿼리를 계산하는 방법을 추가해야합니다 그런 다음 코드를 프로덕션으로 승격시키는 모든 단계를 수행하십시오. 이것은 실제로 좋지 않습니다.

데이터가 큰 경우 데이터와 코드를 분리하는 것이 좋습니다.