데이터베이스에서 구성 데이터를 어떻게 구성합니까?

https://stackoverflow.com/questions/240428

04-07-2019
|

문제

데이터베이스에 애플리케이션 구성 데이터를 저장하는 데 사람들이 선호하는 방법은 무엇입니까?나는 과거에 이 일을 해본 적이 있어서 두 가지 방법을 활용했습니다.

키/값 쌍을 저장하는 테이블을 생성할 수 있습니다. 여기서 key는 구성 옵션의 이름이고 value는 해당 값입니다.이것의 장점은 새로운 값을 추가하는 것이 쉽고 동일한 루틴을 사용하여 데이터를 설정/가져올 수 있다는 것입니다.단점은 값으로 유형이 지정되지 않은 데이터가 있다는 것입니다.
또는 각 열이 값 이름과 해당 데이터 유형인 구성 테이블을 하드코딩할 수 있습니다.이것의 단점은 새로운 값을 설정하는 데 더 많은 유지 관리가 필요하다는 점이지만 이를 통해 데이터를 입력할 수 있습니다.

두 가지를 모두 사용해본 결과 설정이 더 빠른 첫 번째 옵션을 선호하지만 데이터를 검색할 때 더 위험하고 성능이 (약간) 저하될 수 있습니다.대체 방법이 있는 사람이 있나요?

업데이트

아래에 설명된 대로 동일한 값을 사용하는 저장 프로시저뿐만 아니라 동일한 방식으로 구성해야 하는 프로그램의 여러 인스턴스가 있을 수 있으므로 정보를 데이터베이스에 저장해야 합니다.

해결책

옵션 1을 확장하여 세 번째 열을 가질 수 있으며 데이터 유형을 제공 할 수 있습니다. 응용 프로그램은이 데이터 유형 열을 사용하여 값을 캐스팅하는 것보다 가능합니다.

하지만 구성 파일이 옵션이 아닌 경우 옵션 1과 함께 이동합니다. 옵션 1의 또 다른 장점은 응용 프로그램에서 실제로 사용하기 위해 사전 개체 (또는 동등한)로 읽을 수 있다는 것입니다.

다른 팁

구성은 일반적으로 텍스트 파일에 저장 될 수 있으므로 문자열 데이터 유형은 구성 값을 저장하기에 충분해야합니다. 관리되는 언어를 사용하는 경우 데이터베이스가 아닌 데이터 유형이 무엇인지 아는 코드입니다.

더 중요한 것은 구성으로 이러한 것들을 고려하는 것입니다.

계층: 분명히 구성은 계층 구조의 혜택을받습니다
버전 작성: 특정 날짜에 유효한 구성으로 롤백 할 수 있다는 이점을 고려하십시오.
분포: 언젠가 응용 프로그램을 클러스터링 할 수있어서 좋을 것입니다. 일부 속성은 클러스터의 각 노드에 로컬이어야합니다.
선적 서류 비치: 웹 도구가 있거나 무언가에 따라 사용하는 코드에 가까운 속성에 대한 문서를 저장하는 것이 좋습니다. (코드 주석은 이것을 위해 매우 좋습니다.)
공고: 코드는 구성 저장소 어딘가에 변경되었음을 어떻게 알 수 있습니까?

개인적으로, 나는 구성 속성이 값이 어디에서 왔는지 모르는 모듈에 주입되는 반전 된 구성 방식을 좋아합니다. 이러한 방식으로 구성 관리 시스템은 (현재) 요구에 따라 매우 복잡하거나 매우 간단 할 수 있습니다.

옵션 1을 사용합니다.

구성 데이터에 DB를 사용하는 것이 과잉으로 보입니다.

편집 (댓글 상자에 너무 오래 죄송합니다) : 물론 프로그램의 일부를 구현하는 방법에 대한 엄격한 규칙은 없습니다. 논쟁을 위해 슬롯 드라이브 드라이버는 일부 필립스 나사에서 작동합니다! 나는 당신의 시나리오가 무엇인지 알기 전에 너무 일찍 판단했다고 생각합니다.

관계형 데이터베이스는 대규모 데이터 저장소에서 탁월하여 빠른 저장, 업데이트 및 검색을 제공하므로 구성 데이터가 업데이트되고 지속적으로 읽히면 DB를 사용합니다.

DB가 이해할 수있는 또 다른 시나리오는 데이터베이스에 중앙 구성을 저장하려는 서버 팜이있을 때이지만 XML 구성 파일을 가리키는 공유 네트워크 드라이브를 사용하여 동일한 작업을 수행 할 수 있습니다.

구성이 계층 적으로 구조화되면 XML 파일이 더 좋습니다. 필요한 것을 쉽게 구성, 찾기 및 업데이트 할 수 있으며 보너스 혜택을 위해 소스 코드와 함께 구성 파일을 제어 할 수 있습니다!

대체로 구성 데이터가 어떻게 사용되는지에 따라 다릅니다.

그것은 당신의 응용 프로그램에 대한 제한된 지식으로 나의 의견을 마칩니다. 나는 당신이 올바른 결정을 내릴 수 있다고 확신합니다.

나는 이것이 여론 조사에 더 가깝다고 생각합니다. 그래서 열 접근법 (옵션 2)을 말할 것입니다. 그러나 구성이 얼마나 자주 변경되는지, 동적 인 지, 데이터가 얼마나 많은지 등에 따라 다릅니다.

나는 확실히이 접근법을 사용자 구성 / 환경 설정 등에 사용합니다.

내 프로젝트는 네 개의 열이있는 데이터베이스 테이블을 사용합니다.

ID [PK
범위 (기본 '응용 프로그램')
환경
값

'응용 프로그램'범위가있는 설정은 최대 동시 사용자 수와 같은 글로벌 설정입니다.

각 모듈에는 자체 범위 기반이 있습니다. 따라서 결과 로더와 사용자 로더마다 스코프가 다르지만 둘 다 'InputPath'라는 설정이 있습니다.

기본값은 소스 코드에 제공되거나 IOC 컨테이너를 통해 주입됩니다. 데이터베이스에 값이 주입되거나 제공되지 않으면 코드의 기본값이 사용됩니다 (존재하는 경우). 따라서 기본값은 데이터베이스에 저장되지 않습니다.

이것은 우리에게 아주 잘 작동합니다. 데이터베이스를 백업 할 때마다 구성 사본을 얻습니다. 둘은 항상 동기화됩니다.

옵션 1과 함께 이동 옵션 1은 실제로 데이터베이스 위에 데이터베이스를 삭제하는 방법이며, 이는 잘 알려진 안티 패턴으로 장기적으로 문제를 일으킬 것입니다.

적어도 두 가지 방법을 생각할 수 있습니다.

(a) 키, 문자열-값, 날짜 값, int-value, 실제 값 열이있는 테이블을 만듭니다. 사용하지 않은 유형을 널 남겨 두십시오.

(b) XML, YAML 또는 JSON과 같은 직렬화 형식을 사용하여 모든 것을 덩어리에 보관하십시오.

앱이 데이터베이스에 연결하는 데 필요한 구성 설정을 어디에 저장합니까?

다른 구성 정보도 저장하지 않겠습니까?

구성 옵션 수가 매우 작지 않는 한 옵션 1을 사용하겠습니다 (7 이하)

우리 회사에서 우리는 옵션 1 (간단한 사전과 같은 테이블)을 비틀고 사용하고 있습니다. 우리는 교체 할 구성 변수의 이름을 포함하는 토큰을 사용하여 문자열 대체를 허용합니다.

예를 들어 테이블에는 행 ( '데이터베이스 연결 문자열', 'jdbc : //%host%...') 및 ( 'host', 'foobar')가 포함될 수 있습니다. 간단한 서비스 또는 저장된 프로 시저 레이어를 사용하면 매우 간단하지만 유연하지만 재귀적인 구성이 가능합니다. 여러 개의 고립 된 환경 (개발, 테스트, 프로드 등)이 필요합니다.

나는 과거에 1과 2를 모두 사용해 본 적이 있는데 둘 다 끔찍한 해결책이라고 생각합니다.옵션 2는 입력이 가능하기 때문에 더 좋다고 생각하지만 옵션 1보다 훨씬 보기 흉합니다.내가 가진 가장 큰 문제는 구성 파일의 버전을 관리하는 것입니다.표준 버전 제어 시스템을 사용하면 SQL 버전을 합리적으로 잘 관리할 수 있지만 변경 사항 병합은 일반적으로 문제가 됩니다.이 작업을 "올바르게" 수행할 수 있는 기회가 주어지면 아마도 각 구성 매개변수 유형에 대해 하나씩(각 매개변수 자체에 대해 반드시 그럴 필요는 없음) 여러 개의 테이블을 생성하여 입력의 이점과 키/값의 이점을 얻을 것입니다. 적절한 경우 패러다임.또한 이 방법으로 목록 및 계층 구조와 같은 고급 구조를 구현할 수도 있습니다. 그러면 구성을 로드한 다음 메모리에서 변환하는 대신 앱에서 직접 쿼리할 수 있습니다.

나는 옵션 2에 투표합니다. 이해하기 쉽고 유지하기가 쉽습니다.

옵션 1은 쉽게 확장 가능한 중앙 저장소 위치에 적합합니다.RB, Hugo, elliott와 같은 사람들이 제안한 훌륭한 칼럼 외에도 다음 사항도 고려해 볼 수 있습니다.

사용자 필드 또는 사용자/컴퓨터 필드(컴퓨터별 UI 유형 설정의 경우)에 전역/사용자 설정 플래그를 포함합니다.

물론 로컬 파일에 저장할 수 있지만 어쨌든 데이터베이스를 사용하고 있으므로 디버깅할 때 사용자에게 별칭을 지정하는 데 사용할 수 있습니다. 이는 버그가 설정과 관련된 경우 중요할 수 있습니다.또한 필요할 때 관리자가 설정을 관리할 수도 있습니다.

SQL Server에서 옵션 2 및 XML 열의 혼합을 사용합니다. 테이블을 한 줄로 유지하기 위해 체크 제약 조건을 추가하지 않아도됩니다.

CREATE TABLE [dbo].[MyOption] (
  [GUID] uniqueidentifier CONSTRAINT [dfMyOptions_GUID] DEFAULT newsequentialid()  ROWGUIDCOL NOT NULL,
  [Logo] varbinary(max) NULL,
  [X] char(1)  CONSTRAINT [dfMyOptions_X] DEFAULT 'X' NOT NULL,
  CONSTRAINT [MyOptions_pk] PRIMARY KEY CLUSTERED ([GUID]),
  CONSTRAINT [MyOptions_ck] CHECK ([X]='X')
)

DB 테이블과 관련이없는 설정의 경우 값으로 작업하기 위해 DB가 필요한 경우 EAV 접근 방식이 될 것입니다. 그렇지 않으면 직렬화 된 필드 값이 실제로 앱 코드의 저장소 일 경우 양호합니다.

그러나 단일 필드가 DB에서 사용할 여러 구성 설정을 저장할 수있는 형식은 어떻습니까?

메시지 보드보기와 관련된 모든 설정 (기본 정렬 순서, 차단 된 주제 등) 및 테마에 대한 모든 설정 (텍스트 색상, BG 색상 등)이 포함 된 사용자 당 하나의 필드처럼.

관계형 DB에 계층 구조와 문서를 저장하는 것은 광기입니다. 먼저 당신은 그들을 파쇄해야하고, 나중에 어떤 단계에서 그들을 재결합하기 위해서만. 또는 얼룩 안에 삐걱 거리는 소리가 더 어리 석습니다.

사용하지 말고 비 관계형 데이터에는 관계형 DB를 사용하지 않으면 도구가 맞지 않습니다. mongodb 또는 couchdb와 같은 것을 고려하십시오. 스키마가없는 비 관계형 데이터 저장소. 클라이언트에게 어떤 식 으로든 와이어를 내려 오면 JSON으로 저장하고 서버 사이드에 XML을 사용하십시오.

CouchDB는 상자에서 버전을 제공합니다.

충분한 이유가없는 한 구성 데이터를 데이터베이스에 저장하지 마십시오. 당신이 아주 좋은 이유가 있고, 당신이 그것을 할 것이라고 확신한다면, 당신은 아마도 앱을 구성하기 위해 실제로 마크 업 언어가 필요하지 않은 한 - XML이 아닌 경우 XML이 아닌 데이터 직렬화 형식으로 저장해야 할 것입니다. - 끈으로 나를 믿으십시오). 그런 다음 문자열을 읽고 문자열을 읽고 수정하기 위해 어떤 언어로 도구를 사용할 수 있습니다. 문자열을 타임 스탬프로 저장하면 매우 간단한 시스템에 계층 적 데이터를 저장할 수있는 간단한 버전 설정 체계가 있습니다. 계층 적 구성 데이터가 필요하지 않더라도 적어도 앞으로 필요한 경우 구성 인터페이스를 변경할 필요가 없습니다. 물론 구성 데이터에서 관계형 쿼리를 수행 할 수있는 기능이 손실되지만 저장하는 경우 저것 많은 구성 데이터, 그렇다면 어쨌든 매우 잘못된 일을하고있을 것입니다.

회사는 데이터베이스에 시스템에 대한 로트 구성 데이터를 저장하는 경향이 있습니다. 왜 그런 결정에 많은 생각이 발생한다고 생각하지 않습니다. 나는 이런 종류의 일이 OSS 세계에서 너무 자주 이루어지는 것을 보지 못합니다. Apache와 같은 많은 구성이 필요한 대형 OSS 프로그램조차도 APACHE_CONFIG 테이블이 포함 된 데이터베이스에 연결할 필요가 없습니다. 앱에서 처리 할 수있는 엄청난 양의 구성을 갖는 것은 코드 냄새가 나쁘기 때문에 데이터베이스에 데이터를 저장하면 더 많은 문제가 발생합니다 (이 스레드가 설명하는 것처럼).

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow