비즈니스 규칙을 저장하기 위해 구성 파일 또는 데이터베이스를 사용해야합니까?

나는 최근에 Pragmatic Programmer 를 읽고 있다 :

세부 사항은 특히 코드가 자주 변경되는 경우 원시 코드를 엉망으로 만듭니다. 비즈니스 로직, 법률 또는 경영진의 개인적인 취향에 따라 코드를 변경하고 변경해야 할 때마다 새로운 버그가 발생할 위험이 있습니다.

헌트 앤드류; 토마스, 데이비드 (1999-10-20). 실용 프로그래머 : Journeyman에서 Master (Kindle Locations 2651-2653)까지. 피어슨 교육 (미국). 킨들 에디션.

현재 값 집합에서만 속성을 가질 수있는 일부 모델이있는 웹 앱을 프로그래밍하고 있습니다 (예 : 웹 앱 데이터 기밀 정보와 같은 실제 예는 아님).

라이트-> 유형 = 구 / 큐브 / 실린더

라이트 유형은 위의 세 가지 값만 가능하지만 TPP에 따르면 값을 변경하고 구성 파일에 배치 할 수있는 것처럼 항상 코딩해야합니다. 앱 전반에 걸쳐 여러 가지 사건이 발생하므로 내 질문은 다음과 같습니다.

다음과 같은 값을 저장할 수 있습니까?

• 구성 파일 :
  'light-types' => array(sphere, cube, cylinder),
'other-type' => value,
'etc' => etc-value

• 각 구성 항목마다 한 줄씩있는 데이터베이스의 단일 테이블

• 각 구성 항목에 대한 테이블이있는 데이터베이스 (예 : 테이블 : light_types; 열 : id, name)

• 다른 방법?

도움 / 전문 지식을 제공해 주셔서 감사합니다.

내가 작업하는 대부분의 프로젝트에서 동일한 질문이 발생합니다. 보통 나는 이것을한다 :

1. 가능한 값 집합이 곧 변경되지 않을 경우 코드의 클래스 / 인터페이스 상수 또는 열거 형과 데이터베이스의 열거 가능한 필드를 사용합니다. 예 : 블로그 항목의 게시 상태 : '게시되지 않음', '보통 중', '게시 됨'등
2. 값은 변경 될 수 있지만 변경 사항은 프로그램 논리 구성 파일에 영향을 미치지 않습니다. 예 : "웹 사이트를 어떻게 찾았습니까?" 온라인 구매 양식의 드롭 다운 목록 옵션.
3. 값은 자주 변경되거나 개발자가 아닌 사람이 편집하도록되어 있지만 이러한 변경 사항은 데이터베이스 또는 최소한 사용자 친화적 인 편집 가능한 인터페이스가있는 키-값 저장소와 같은 논리에는 영향을 미치지 않습니다.
4. 값을 변경하면 논리에 영향을 미칩니다. 아마도 시스템을 재 설계해야하거나 (일부 사실) 일부 비즈니스 규칙 엔진이 필요할 수 있습니다. 지금까지 본 가장 어려운 사례는 동료가 작업 한 심리 테스트 생성자였습니다. 각 유형의 테스트에는 간단한 추가에서 긍정적, 부정적 값을 가진 여러 특성 척도 또는 사람에 대한 답변 평가까지 다양 할 수있는 자체 스코어링 시스템이있을 수 있습니다. 이 프로젝트에 대해 논의한 후에, 우리는 Lua 를 스크립팅 엔진으로 사용하여 결국 개발자가 아닌 사람이 새로운 테스트를 만들 수있는 능력과 완전히 충돌합니다 (Lua는 비교적 간단한 언어이지만 프로그래머가 아닌 사람은 아닙니다) 그것을 배울 것입니다).

TPP의 견적에 대해. 나는 원시 코드에 대해서는 사실이라고 생각 하지만 실제로는 단순하게 시작하고 ( KISS 원칙 ) 실제로 필요한 경우 나중에 기능을 추가하는 것이 좋습니다 ( YAGNI ).

데이터가 데이터베이스에 있으면 동일한 DB에 'light_types'테이블을 갖는 것이 좋습니다. 이를 통해 외래 키를 사용하여 light-> type이 해당 값 중 하나 일 수 있다는 제약 조건을 적용 할 수 있으므로 코드가 엉망이더라도 DB의 데이터는 항상 유효합니다.

데이터가 DB에 저장되지 않으면 많은 열거 형을 위해 하나를 만드는 것이 많은 도움이되지 않습니다. 값을 하드 코딩하지 않으려면 구성 파일을 권장합니다.

(그러나 나는 하드 코딩을 피하는 데 너무 멀리 경고하지 않았다. 사소한 시스템에서는 저자가 그것을 인식하든 모르 든 비즈니스 규칙과 요구 사항에 대한 가정이있을 것이다. 모든 가정과 소프트 코드를 사용하면 기본적으로 시스템 내 및 / 또는 메타 언어 시스템 인 일종의 "규칙 엔진"으로 끝나고 메타 언어에는 많은 것들이 있습니다. 작업을 저장하지 않았거나 유연성을 얻지 못했을뿐 아니라 다른 언어를 작성 및 / 또는 배우기 만하면됩니다.

당신이 찾아 기존의 규칙 엔진을 사용하려는 경우 지금, 그 (열거 형을 저장하는 곳의 질문에 대답과 함께) 당신에게 약간의 작업을 저장할 수 있습니다. 그러나 자신만의 빌드는 작업량을 두 배로 늘리고 필연적으로 규칙 엔진을 만드는 방법을 모르는 사람들이 만든 반 시스템을 가져옵니다.)

일반적으로 데이터베이스는 데이터를 위해 사용되어야하고 구성 파일은 구성을 위해 사용되어야합니다. (이름에서 알 수 있듯이) : 데이터베이스에서 구성을 유지하는 것은 우려를 나쁘게 분리하는 데 적합하며이를 정당화 할 수있는 유스 케이스가있는 경우에만 수행해야합니다.

사용할 구성 양을 결정할 때 균형을 맞 춥니 다. 구성 파일은 코드만큼 응용 프로그램의 일부로 취급해야합니다. 최대한 간결하게 유지하십시오. 마법의 문자열로 가득 찬 거대한 xml 파일로 끝나는 구성 팽창으로 인해 응용 프로그램이 쉽게 어려움을 겪습니다.

설명하는 경우 사용할 CSS 파일을 정의하는 구성 요소를 갖는 것이 합리적입니다. 요구 사항이 변경되면 변경할 수 있습니다. 구성 파일에서 각 요소의 스타일을 구성하는 것은 과도합니다.