DB를 사용하는 것과 달리 실제 데이터 값을 코드에 하드 코딩하는 경우는 언제입니까?


17

나에게 가장 오래된 질문은 데이터베이스 테이블에 데이터 (실제 값)를 언제 저장하고 언제 코드에 바로 저장합니까?

알려지지 않은 합의는 일반적으로 다음과 같습니다 (*).

단일 변수이거나 간단한 구조이거나 몇 개의 값 배열이면 데이터를 코드에 바로 넣으십시오.

[* 의견과 답변에 대한 합의가 논의되었지만 기본적으로 나는 질문을 시작하기 위해 어떤 전제를 원했기 때문에 자유롭게 도전하고 개선 할 수있다 ]

예:

$number = 44;
$colors = array("blue", "yellow", ... "mauve");

동일한 유형의 수백 개 이상의 데이터 행이있는 경우 데이터베이스를 사용하십시오.

그러나 회색 영역이있는 것 같습니다. 명확하지 않은 경우는 어떻습니까? 결정을 내릴 때주의해야 할 사항과 요소는 무엇입니까?

예 :
귀사에서 "412T"로 표현할 수있는 10-15 개의 서로 다른 유형의 모터 프레임을 사용한다고 가정 해보십시오. 당신은 그들 중 약 30을 가지고 거의 변경되지 않습니다. DB 테이블을 생성하거나 데이터베이스에 하드 코딩 할 수 있습니다. 이 경우 모터는 정적이며 물리적으로 자주 변경되지 않는 것입니다.

코드에서 코드를 유지하면 데이터베이스에서 일반적으로 DB 변경 사항이 추적되지 않는 소스 제어가 적용됩니다. 그러나 데이터베이스에 유지하면 데이터에서 코드를 분리 (분리) 할 수 있습니다.

내가 사용할 수있는 또 다른 (실제) 예는 내 질문입니다 : https : //.com/questions/26169751/how-to-best-get-the-data-out-of-a-lookup-table (현재 48 옵션 데이터 행).


3
우리들의 일치는 통상적있다 NOT 같은 있었다 : 그것은 하나의 변수 또는 간단한 구조, 또는 소수 값들의 배열 인 경우, 오른쪽 코드 데이터를 넣어.
Pieter B

중간 방법이 있습니다. 데이터는 데이터베이스에 저장됩니다. 그런 다음 소스 코드를 작성하기 위해 추출됩니다 (예 : global_constants.h파일).
mouviciel

@mouviciel 그러나 데이터를 구성하는 요소 ... 데이터베이스에 액세스하려면 데이터가 필요하므로 모든 데이터를 저장할 수 없습니다.
jwenting

답변:


33

이 두 문장이 데이터를 언제 하드 코딩해야하는지에 대한 합의를 나타내는 것은 아니라고 생각합니다.

단일 변수 또는 간단한 구조이거나 몇 가지 값의 배열 인 경우 코드에 데이터를 입력하십시오

동일한 유형의 데이터 행이 수백 개 이상인 경우 데이터베이스를 사용하십시오.

간단한 반례 (더 나은 것들이 있다고 확신합니다) : 프로그래밍 언어 구문 테이블은 종종 하드 코딩 된 복잡한 대형 구조입니다. Perl 소스 코드 에서 예제를 보자 .

대신에 나는 먼저 묻는 것에 집중할 것이다.

  • 데이터는 얼마나 자주 변경됩니까?

  • 누가 변경해야합니까?

"얼마나 자주"에 대한 답변이 "새로운 버전의 앱을 배포하려는 것보다 더 자주"인 경우 데이터를 하드 코딩해서는 안됩니다.

"변경하는 사람"에 대한 대답이 "프로그래머 이외의 사람"이라면 데이터를 하드 코딩해서는 안됩니다.

소규모 상점에서는 코더와 사용자 간의 구별이 사라 졌을 수 있으며 "배포"라는 아이디어도 사라졌습니다. 이 경우 당신은 당신의 자신의 도메인의 왕이며 당신이 원하는대로 할 수 있습니다.

그러나 이러한 상황에서도 공동 작업의 필요성이 발생할 수 있으며, 사용자 지정 응용 프로그램이 일반적으로 프로그래머가 따르는 규칙을 따르지 않으면 어려울 수 있습니다.


6
자주 묻는 질문과 마찬가지로 또 다른 질문은 "얼마나 빨리 변경해야합니까?"입니다. 게이팅 요소는 사용자 기반에 배포하는 데 걸리는 시간 일 수 있습니다. 중앙 집중식 서버 소프트웨어의 경우 답변은 몇 분이 될 수 있지만 현장의 모바일 앱의 경우 몇 주가 걸릴 수 있습니다.
CuriousRabbit

Perl 예제에서 an array with a few values기본 데이터 유형의 377-ish 행은 거의 없습니다. 어쩌면 일부에게 "몇 개"이상일 수도 있지만 여전히 꽤 작습니다. 비슷하지만 약간 덜 평평한 구조가 하드 코딩되어 있습니다. 1000 행 이상이라면 아마 이런 식으로 하드 코딩하는 것을 꺼려 할 것입니다.
Dennis

14

세 번째 옵션 인 구성 파일을 사용하겠습니다!

내가 작업하는 응용 프로그램 (Java에서 모든 예제는 Java + Spring 사용)의 경우 이러한 값은 일반적으로 구성 파일에 저장되고 응용 프로그램을 시작할 때 필요한 코드에 스프링을 통해 주입됩니다. 특성 파일에서 :

motorFramesString=412T, 413T, ...

스프링 설정에서 :

<bean="motorFrameManager" class="myCompany.MotorFrameManager" >
    <property name="motorFrames" value="${motorFrames}"/>
</bean>

이것의 장점은 재 컴파일하지 않고도 이러한 대부분의 정적 값을 쉽게 쉽게 변경하거나 추가 할 수 있으며 (관계형) 데이터베이스를 참조 데이터로 채울 염려가 없다는 것입니다. 걱정할 수도 있고 어쨌든 모든 것이 데이터베이스에있을 필요 는 없습니다 ).

에 관해서는 이 값 대신 참조 테이블의 설정 파일에 가야한다 : 당신이 주로 코드에서이 값을 사용할 계획, 또는 대부분의 데이터베이스에 있습니까? 이러한 값에 의존하는 기존 쿼리와보기 및 프로 시저가 많이있는 경우 구성 파일에서로드하고 모든 가능한 쿼리 /에 매개 변수로 전송하는 것이 더 쉬우므로 데이터베이스에 참조 데이터로 저장하는 것이 가장 좋습니다. 그것들을 참조하는보기 / 절차. 값이 주로 응용 프로그램 코드에서 사용되는 경우 구성 파일이 더 나은 선택 일 수 있습니다.


속성과 함께 또는 속성없이 연결하는 것과 같은 더 복잡한 예제도 수행 할 수 있습니다.

products.properties에서 :

productA.name=Product A 123
productA.hasMotor=true
productA.numFeet=1
productA.hasOutlet=true
productA.needsManual=true

productB.name=Product B 456
productB.hasMotor=false
productB.numFeet=1
productB.hasOutlet=true
productB.needsManual=true

스프링 설정 파일에서 :

<bean name="productA" class="com.mycompany.Product">
   <property name="name" value="${productA.name}"/>
   <property name="hasMotor" value="${productA.hasMotor}"/>
   <!-- rest omitted for brevity -->
</bean>
<bean name="productB" class="com.mycompany.Product">
   <property name="name" value="${productB.name}"/>
   <property name="hasMotor" value="${productB.hasMotor}"/>
   <!-- rest omitted for brevity -->
</bean>
<!-- configure as many beans as needed -->
<bean="motorFrameManager" class="myCompany.MotorFrameManager" >
    <property name="motorFrames"> <!-- assumes that MotorFrameManager has a property motorFrames which is a List<Product> -->
        <list>
            <ref bean="productA"/>
            <ref bean="productB"/>
        </list>
    </property>
</bean>

이것에 대한 좋은 점은 소스 데이터가 링크 된 질문과 같은 스프레드 시트 인 경우 Excel에서 매크로를 사용하여 속성 및 스프링 스 니펫을 자동으로 생성 할 수 있다는 것입니다.


프레임 예제를 사용하는 동안 상당히 간단합니다 (하나의 문자열 값만). n 개의 튜플 혼합 변수가있는 옵션 테이블 (내 질문의 맨 아래에 링크되어 있음)에 대한 접근 방식이 기본적으로 동일합니까?
Dennis

@Dennis : 더 복잡한 예를 추가했습니다.
FrustratedWithFormsDesigner

8
구성 파일은 db의 한 형태 일뿐입니다.
DougM

3
@DougM, 동의하지만 Oracle에서 일련의 구성 테이블을 설정하는 것과 간단한 XML 구성 파일을 갖는 것에는 차이가 있습니다. 구성 파일은 버전 제어에 의해 제어되는 장점도 있습니다. 구성 파일은 중간 수준이며 코더가 더 많은 구성 데이터를 분리하도록 권장하는 파일입니다. 시간이 좋은 일이 아니다 어디 현실적인 시나리오를 생각 사투를 벌인거야
mcottle

2
@gbjbaanb : 대부분의 응용 프로그램에서 RDBMS는 WAAAAAY 과잉입니다. 속도가 느리고 유지 및 통합에 상당한 노력이 필요하다는 것은 말할 것도 없습니다. "ini"파일은 어떤 형식의 안전성도 제공하지 않으므로 파서를 직접 작성해야하며 자신의 형식 검사를 작성해야합니다. 적어도 .Net의 XML 구성 파일은 기본적으로 무료 옵션 중 하나를 통해 제공되는 모든 이점을 누릴 수 있습니다. 따라서 XML 구성 파일이 항상 더 나쁜 선택이라는 주장은 더 잘못 될 수 없습니다.
Dunk

10

나는 그 질문의 전제가 옳지 않다고 생각합니다. 나누는 요소는 변경해야 할 레코드 의 이 아니라 변경 빈도 및 변경하는 사람 입니다.

회수

데이터가 휘발성 일 때 소프트웨어의 릴리스주기와 외부에서 자주 변경된다는 점에서 하드 코딩 된 값 또는 구성 파일 외부에서 구성 할 수 있어야합니다. 데이터베이스는 특히 응용 프로그램 자체에서 데이터베이스를 유지 관리 할 수있는 경우에 적합합니다.

누구

고객이 데이터 변경 할 수 있어야합니다, 그것은 릴리스주기의 사용자 친화적 인 방식으로 외부에서 수정 될 필요가있다.

공통 스레드

여기서 일반적인 스레드는 소프트웨어 릴리스 외부에서 데이터를 변경해야 할 경우 데이터베이스에 저장해야한다는 것입니다. 데이터베이스는 릴리스 중에 업그레이드 될 수 있지만 데이터는 재설정되거나 크게 수정되지 않고 유지됩니다. 고객이 데이터를 수정하거나 기능을 구성 할 수 있어야하는 경우, 바보가없는 프런트 엔드가있는 데이터베이스에 저장해야합니다.

테스팅

다양한 구성에서 소프트웨어의 유효성을 검사하는 단위 테스트를 작성하십시오. 고객이 옵션 프롬프트를 켜거나 1 미터를 12 피트에 맞게 재정의 할 수 있습니다. 변경이 얼마나 합리적인지에 관계없이 소프트웨어가 허용하는 경우 변경이 아무리 잘못되어도 변경이 예상대로 작동하는지 확인하는 것이 좋습니다.


4

변경 빈도 나 데이터 저장 위치를 ​​결정하는 데이터 양이 아닙니다.

프로그램을 실행하는 데 데이터가 필요한 경우 프로그램 코드의 일부이므로 상수로 저장하십시오. 다른 모든 데이터는 데이터베이스에 들어갑니다.

물론 설정 파일, 이미지, 사운드 등은 일반적으로 파일 시스템에 더 잘 저장됩니다.


전적으로 DB 중심의 콜센터 지원 프로그램을 만들었습니다. 데이터는 "코드를 실행"하는 데 필요했지만 코드를 컴파일하는 것은 부적절했을 것입니다.
DougM

1
저는 8 년 동안 Oracle 개발자 였지만 기본 데이터베이스와 긴밀하게 연결되어있는 응용 프로그램을 여전히 좋아하지 않습니다.
winkbrace

2

하드 코딩 된 항목이 변경되어 응용 프로그램을 다시 작성해야하는 전화를받을 가능성이 가장 적더라도 하드 코딩하지 마십시오. 최소한 구성 파일 또는 db 테이블에 보관하십시오. UI를 반드시 제공 할 필요는 없지만 UI를 제공 할 필요는 없지만 설정 파일을 다이얼링하고 변경하거나 테이블에서 SQL UPDATE를 실행하는 것이 전체 촬영 일치를 다시 작성하는 것이 좋습니다.


1

구별은 실제로 다소 회색 영역이지만 이러한 종류의 문제에 대한 나의 접근 방식은 다음과 같습니다. 프로덕션에서 데이터가 변경됩니까? "프로덕션 환경에서 배포 후 변경된 내용은 거의 변경되지 않는 경우에도 데이터베이스에 저장되어야합니다.

따라서 당신이 묻어 야 할 질문은 "얼마나 자주 변할 것인가?"가 아니라 "변경 될 수 있습니까?"입니다. 프로덕션 환경에서 코드의 다른 항목을 건드리지 않고 동일한 코드 반복 내에서 속성 값이 다를 수 있으면 데이터베이스로 이동합니다.


0

또한 "프로그램 제어"유형 정보에는 최대 버퍼 크기, 순서대로 항목 수, 화면의 최대 페이지 크기가 프로그램 또는 구성 파일에 하드 코딩되어있는 것이 더 좋습니다.

이런 종류의 데이터를 데이터베이스에 보관하면 누군가가 즉시 데이터를 변경하고 시스템의 동작을 완전히 변경할 수 있습니다.

또 다른 문제점은 사용해야하는 소스 제어 / 변경 관리 / 자동 빌드 시스템을 통해 데이터베이스 항목을 얻는 쉬운 방법이 없다는 것입니다.


0

데이터베이스에 보관해서는 안되는 한 가지는 데이터베이스에 액세스하는 데 필요한 세부 정보입니다.
결국 동일한 데이터베이스의 연결 문자열, 사용자 이름 및 비밀번호를 검색하기 위해 데이터베이스에 액세스 해야하는 경우 약간의 문제가 있습니다.

하드 코드? 흠, 응용 프로그램과 함께 설치 및 제공되는 일종의 데이터베이스를 사용하는 경우 작동 할 수 있습니다.
구성 파일? 더 유망하지만 계정 보안은 어떻습니까?

물론 데이터베이스 정보를 해당 구성 파일에 암호화 된 형식으로 저장할 수 있지만 암호 해독 키를 어딘가에 저장해야하며 거의 확실하게 하드 코딩됩니다.

그 외에도, 절대 변하지 않는 것들이 있습니다. 자연 상수 (G, pi, e, 이름 지정)와 같은 것, 이메일 유효성 검사와 같은 특정 정규식과 같은 것들이 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.