코드에서 정적 데이터베이스 데이터를 참조하는 가장 좋은 방법은 무엇입니까?

많은 응용 프로그램에는 '정적 데이터'가 있습니다. 응용 프로그램 수명 동안 실제로 변경되지 않는 데이터입니다. 예를 들어, 가까운 장래에 고정리스트가 될 가능성이있는 판매 지역리스트가있을 수 있습니다.

데이터베이스 테이블에서이 정적 데이터를 찾는 것은 드문 일이 아닙니다 (종종 다른 테이블의 외래 키에서이를 참조하려고하기 때문에). 간단한 예제 테이블에는 기본 키 및 설명으로 사용할 ID가 있습니다. 예를 들어 SalesArea 테이블에는 최소한 SalesAreaId 열과 SalesAreaDescription 열이 있습니다.

이제 코드에서 테이블의 각 행을 동일하게 취급하지 않을 수 있습니다. 예를 들어, 일부 화면에서 기본 판매 지역을 설정하거나 일부 지역에 대해 다른 수치를 제공하거나 다른 지역에서 사용자가 수행 할 수있는 작업을 제한 할 수 있습니다.

코드에서이 정적 데이터를 참조하는 가장 좋은 방법은 무엇입니까? 왜?

1. 코드에 설명을 하드 코딩하십시오. 필요할 때 데이터베이스에서 SalesAreaId를 조회하려면이를 사용하십시오.
2. 코드에 ID를 하드 코딩하십시오. 이를 사용하여 필요할 때 SalesAreaDescription을 찾아보십시오.
3. 각 목적 (예 : "IsDefaultOnProductLaunchScreen"열 등)에 대해 열을 테이블에 추가하십시오 (많이있을 수 있음).
4. 다른 것.

정적 데이터베이스 데이터를 처리 할 때 고려해야 할 다른 특별한 사항이 있습니까? 예를 들어,이 테이블에 특별한 이름을 부여 하시겠습니까?

응용 프로그램을 시작할 때 캐시 (일반적으로 해시 테이블로 구현)에로드하는 방법은 무엇입니까? 그렇게하면 데이터베이스를 쿼리 할 필요조차 없습니다 (한 번 이상).

또한 하드 코딩을 피하는 것이 좋습니다. 기본값이 필요한 화면에 대해 기본 표시기 (처음에는 DB 테이블 및 캐시 구조)를 추가하십시오. 고장이 아닌 곳에서 조회 할 경우 가능하면 구성 또는 특성 파일에서 조회 할 키를 저장하십시오.

DB 또는 하드 코딩의 대안은 시작시 읽은 구성 파일을 사용하는 것입니다. 그런 다음이 데이터를 코드 내에서 읽기 전용 구조로 저장할 수 있습니다.

이 데이터를 편집하는 드문 경우이지만 불가능하지는 않지만 앱을 다시 시작해야합니다. 이것이 가능하지 않은 경우 데이터에 액세스 할 때마다 구성 파일의 변경 사항을 확인하는 더 복잡한 구성 관리자를 작성할 수 있습니다. 실제로 파일에서 타임 스탬프를 확인한 다음 모든 데이터를 무효화하기 만하면 매우 효율적입니다. 파일이 업데이트 된 경우

데이터가 DB의 기존 데이터와 관련이있는 경우 코드에 추가하는 것만 큼 DB에 추가하는 것이 효율적일 수 있습니다. 그렇지 않다면 나는 보통 그 총알을 한 번 가져 가고 처음으로 바뀔 때까지 코드에 넣는 유혹을 받는다.

우리가 정적이라고 생각하는 경우가 종종 있으며, 그럴 때 변경이 이루어질 때까지 코드 릴리스를 기다릴 필요가 없습니다. 한 번만 발생하면 데이터베이스에 넣고 관리자 페이지를 작성하여 추가 업데이트를 수행하십시오.

예를 들어 DB에 이미 판매 지역이있는 경우 여기에 설명을 추가하고 데이터베이스 데이터를 하드 코딩 된 목록과 연관시키기 위해 해시 테이블을 작성하지 마십시오. 그러나 영업 지역의 해시 테이블을 작성하지 않고 준비가 되었다면 누군가가 처음으로 설명을 변경하거나 새로운 영업 지역을 추가 할 때 DB로 이동하십시오.

왜 모든 것을 하드 코딩하지 않습니까? 내가 항상 가지고 있었던 주요 문제 는 응용 프로그램 코드에서 DB의 정적 값을 참조 하는 것입니다. 드롭 다운 목록이나 정적 값이 아닌 것을 직접 작성하는 경우 한 가지이지만 일부 응용 프로그램 논리가 DB의 값에 의존하면 어떻게됩니까?

간단한 응용 프로그램에는 현재 초안, 게시 됨, 보관 됨 등의 콘텐츠에 대한 편집 상태 목록이 있습니다.

콘텐츠 항목은 현재 상태에 따라 다르게 처리해야합니다.이 상태 데이터를 각각 1, 2, 3 값으로 DB에 유지하려면 임시 보관함에 있는지 확인하는 방법은 무엇입니까? 상태?

if (content.State == 1)
또는
if (content.State == "Draft")?

방금 값을 하드 코딩했습니다!
캐시 / 해시 테이블을 사용하는 경우에도 마찬가지입니다. 데이터를 조회하기 위해 코드 로 작성된 일부 값을 키로 사용해야 합니다.

하드 코딩 어프로치의 단점은 무엇입니까?

FrustratedWithFormsDesigner가 말한 것과 유사하게, 이는 정적 데이터를 한 번만로드하면되지만 OAOO 패턴을 따르기 때문에 일반적으로 캐시를 사용하여 수행됩니다. 즉, 두 위치 (데이터베이스 및 귀하의 코드).

NHibernate ORM이 2 차 캐시 를 통해이 기능을 제공한다는 것을 알고 있습니다. 특정 테이블의 데이터를 캐시하고 읽기 전용이라고 말할 수 있습니다. 처음 필요할 때로드되며, 여러 세션에서 데이터에 액세스하더라도 그 후에 데이터베이스에 다시 도달하지 않습니다.

이것은 최악의 조기 최적화입니다.

첫째, 현대의 모든 DBMS는 작은 테이블에서 빠른 속도로 데이터를 검색하며 모두 우수한 캐싱 알고리즘에서 우수한 캐싱 알고리즘을 제공합니다 (DBMS에 지불하는 금액이 많을수록 캐시 성능이 향상됩니다). 따라서 최소한의 리소스 만 소비하는 것을 최적화하고 있습니다.

둘째, "판매 영역"과 같은 것이 정적 데이터라고 생각하면 실제 비즈니스 응용 프로그램에 대한 경험이 거의 없습니다. 이들은 마케팅 이사 또는 CEO가 변경 될 때마다 변경 될 수 있습니다. 2 년 동안 고통의 세계로 향하고 있습니다.

여기에는 두 가지 방법 만 있습니다 :-

데이터베이스에 저장하고 "normal"sql을 사용하여 데이터에 액세스하십시오.

"전략적인 정책 변경"이있을 때마다 쉽게 편집 할 수있는 멋진 XML 구성 파일 (REST 또는 SOAP을 통해 액세스 가능)에 저장하십시오.

데이터로 무엇을하고 있는지에 따라 다릅니다. 그것이 무언가의 목록이라면 나는 보통 그것을 배열로 가져올 것입니다. 목록을 다른 버전으로 확장해야하는 경우 데이터베이스에 추가하고 코드를 변경하여 배열의 추가 데이터를 처리 할 수 ​​있습니다 (코드에 따라 필요하지 않을 수도 있음). 배열의 상한을 사용하는 for 루프). 설정 목록 인 경우 일반적으로 SQL 문을 사용하는 것보다 많지 않고 쉽고 빠르므로 일반적으로 하드 코딩합니다. 사용자가 변경할 수있는 설정이고 후속 실행을 위해 선택 항목을 저장하려면 레지스트리로 사용할 테이블을 만들고 필요에 따라 개별 항목을 변수로 가져옵니다.

나는이 답변이 받아 들여 졌다는 것을 알고 있지만 데이터베이스 I / O를 최대한 줄이려고 노력했던 마지막 웹 개발 상점에서이 작업을 수행 한 방법을 공유하고 싶었습니다.

우리는 가능한 많은 조회 유형 데이터 구조를 위해 서버 측 포함 파일을 사용했습니다. 주로 사이트 탐색 (하위 탐색 포함)을위한 것이었지만 가능한 한 많은 드롭 다운 및 확인란 (주, 국가, 범주)에도 사용되었습니다.

원래 우리는이 모든 데이터를 데이터베이스에서 가져 왔습니다. 고객에게 관리자 위젯을 제공했기 때문에이 데이터를 마음대로 변경할 수 있었으며 약간의 nickle-dime 변경으로 인해 결코 혼란에 빠지지 않았습니다. 대부분의 경우이 데이터는 거의 변경되지 않았지만 가끔 변경되었습니다.

우리는 항상 더 빠른 로딩 시간을 찾고있었습니다. 따라서 가능한 많은 정적 서버 측 텍스트 파일을 구현하기로 결정했습니다. 우리는 이것을 관리자 위젯에서 수행했습니다. 데이터베이스 테이블이 업데이트 될 때마다 해당 정적 텍스트 파일을 재생성합니다. 이것은 우리에게 매우 유연하고 빠른 환경을 제공했습니다.

모든 상황에서 작동하지 않을 수도있는 이것에 대한 나의 해결책은 정적 데이터베이스 데이터를 하드 코딩 된에 바인딩하는 것 enum입니다. 동적 데이터 (데이터베이스)가 정적 논리 (코드)에 바인드되어 문제점이 발생하므로에 연결된 데이터베이스 테이블을 사용하여이 바인딩을 명시 적으로 (느슨하게) 만드십시오 enum. 전의:

LooseDBCodeBinding (database table)
   ID : Int32 (key)
   Name : String
   HardCodedTypeID : Int32

// in code:
public enum LooseDBCodeBinding
{
   TYPE_1 = 1,
   TYPE_2 = 2,
   TYPE_3 = 3 // etc...
}

그런 다음 LooseDBCodeBinding레코드 목록을 쉽게보고 이를 LooseDBCodeBinding enum"브로큰"바인딩 지원을 포함 하여 값에 맵핑 할 수있는 UI를 작성하십시오 . 그런 다음을 중심으로 프로그래밍 enum하고 테이블 키를 중심으로 데이터베이스를 디자인 할 수 있으며 두 컨텍스트에 대한 지식이있는이 테이블입니다.