단일 행의 응용 프로그램 설정

Originally posted here
장면은 다음과 같다. 외부 API에서 데이터를 가져와 계기판에 다양한 방식으로 표시하는 상당히 간단한 웹 응용 프로그램을 구축하고 있다.이러한 특정 데이터 검색을 가능하게 하는 과정의 관건은api 키의 존재입니다.이 키는 API를 잠금 해제하고, 내 프로그램의 모든 매력적인 재미를 제공합니다.
이 데이터에 실제로 액세스하는 것 외에, 나의 또 다른 요구는 언제든지 쉽게 API 키를 변경할 수 있고, 응용 프로그램의 코드 라이브러리에 깊이 들어가지 않아도 된다는 것이다.어떻게 해야 합니까?
나는 지금 Ruby on Rails를 사용하고 있지만, 이것은 상당히 중요하지 않다는 것이 증명될 것이다.물론 다음과 같이 애플리케이션 전반적인 구성(예: API 키)을 Rails에 간편하고 안전하게 저장할 수 있는 방법이 있습니다.

# config/environments/production.rb
config.mailchimp_api_key = “ABCDEF”

또는 암호화된 Rails 기밀을 사용하여 config/secrets.yml 파일에 유사한api 키 내용을 저장하고 다음과 같이 액세스할 수 있습니다.

Rails.application.credentials.dig(:facebook, :api_key)

이 두 가지 해결 방안의 문제는 모두 동적이지 않다는 것이다. 키를 업데이트하려면 코드 라이브러리에 수동으로 들어가서 변경, 테스트를 하고 프로그램을 재배치해야 한다.이것은 단지 작은 놀이일 뿐이다. 나는 응용 프로그램 코드 라이브러리에 접근하고 이해할 수 있는 사람들에 대한 의존을 없애고 싶다.
그래서 나는 키를 데이터베이스 테이블에 저장하기로 결정했다. 이것은 정말 창의적인 것이다.이 간단한 해결 방안이 왜 매우 효과적인지, 그리고 당신이 그것을 어떻게 실시할 수 있는지 깊이 있게 이해합시다.
SRT(Single List)를 선택했습니다.이것은 상대적으로 자명하다. 이것은 단지 한 줄만 있는 책상이다.내 예에서, 이 테이블은 app_settings 라고 불리는데, 이 테이블의 열은 나의 가장 중요한 API 키를 포함한 다양한 응용 프로그램 범위의 설정을 저장한다.나는 지금 다른 모든 표를 처리하는 것처럼 일반적인 읽기/쓰기 작업을 수행할 수 있다.그러나 이 차이점은 표 자체가 한 줄(또는 기록)밖에 없다는 데 있다.이 가능하다, ~할 수 있다,...
신분증
암호화api 키
암호화api 키 iv
...
1
asD2-f21Fa-126d-a
$bRs23Gjg82dsGDsF
...
Rails에서 이러한 이점을 실현하는 것은 매우 간단합니다. 다른 웹 프레임워크에서는 그 어떠한 복잡함도 알 수 없습니다.

사용attr_encrypted gem 문서의 간단한 설명에 따라 AppSetting라는 모델(상응하는 이전을 통해 app_settings표를 만들고)과 API 키의 암호화 속성/열을 만들었습니다.

이 테이블에만 기록을 만들고 사용할 수 있도록 특정 줄에만 조회를 실행하는 인터페이스가 필요합니다.나는 이 방법을 AppSetting모델에 추가했고 이 모델은 Active Record's handy 'first_or_create' method:

def self.current
   first_or_create
end

이 점에서부터 저는 AppSetting 모델을 사용할 때마다 current 유형의 방법을 결합시켰습니다. 예를 들어Services::Api::Request.call(api_key: AppSetting.current.api_key).중요한 것은, 나는 현재 응용 프로그램의 사용자 인터페이스를 통해 낡은 폼을 사용하여api 키를 쉽게 업데이트할 수 있는 방법이 있다.

너는 이 글을 읽을 가능성이 높다. 한 줄의 표가 좀 이상하게 들리는지 확인하려고 한다.나도 그곳에 앉아서 내가 원하는'더 깨끗한'방식을 똑같이 생각하고 찾았다.솔리드 속성 값(Entity Attribute Value, EAV) 테이블(이름-값 쌍 테이블)이라는 또 다른 유행하고 실행 가능한 솔루션을 만났습니다.
EAV의 작업 원리는 매우 간단합니다. 이것은 모든 설정 값에 한 줄을 정의합니다. 한 열은 설정 이름을 나타내고, 한 열은 설정 값을 나타낼 수 있습니다.내 요구사항에 따라 테이블은 다음과 같습니다.
구성 옵션
가치 01 명
암호화api 키
asD2-f21Fa-126d-a
암호화api 키 iv
H4FHSDFFASQ2
EAV의 매력은 명백합니다. 모든 설정 옵션은 익숙한 키 값 쌍과 비슷한 형식으로 줄을 가지고 있습니다.그러나 내가 한 줄의 표를 굴리기로 결정한 것은 개발자 포럼의 보편적인 견해가 EAV가 아닌 SRT에 더 치우친 것 같기 때문이다.나는 기회를 잡아 시뮬레이션 벨트를 펼치고 찬성/반대 명세서를 대충 적어 놓았다.이 점을 아래에 공유하여 보기 드문 '편집 가능한 프로그램 범위 설정' 난제에 대한 응답을 선택하거나 계획할 수 있도록 도와 드리겠습니다.
단일 열 Table Pro's

간단하게 말하면 쉽다.그것은 실현이 빠르고 익숙하며 효과가 있다.

모든 설정 값은 정확한 데이터 형식에 저장됩니다. 암호화된 api key 열은 문자열이고refresh seconds는 정수입니다.

만약에 사용자의 수요가 바뀌었다면 응용 프로그램 범위의 설정은 현재 하나의 실체(예를 들어 사용자나 회사)에 적용되어야 합니다. 그러면 외부 키를 app_settings 테이블에 추가하는 것은 매우 간단합니다. 정렬을 할 수 있습니다.또한 실체 속성 값표를 사용한다면 이 정도는 간단하지 않습니다.

단일 목록 Con's

기타 구성 옵션은 데이터베이스 아키텍처를 변경해야 합니다.예를 들어 트위터 api 키를 추가하려면 새 칼럼이 필요합니다.

구성 옵션이 많으면 테이블이 매우 넓어질 수 있습니다.

이 행에서 구성 값이 추가/업데이트된 시기를 정확히 추적하기가 쉽지 않습니다.

솔리드 속성 값

그것의 실현과 사용도 매우 간단하다.

새 설정을 추가하려면 데이터베이스 모델을 변경할 필요가 없습니다. 단지 줄일 뿐입니다.

표 모드가 매우 좁습니다.

테이블에 created_at 및 updated_at 열을 추가하면 구성 옵션을 추가/업데이트할 때 추적하기 쉽습니다.

솔리드 속성 값 Con's

모든 내용은'stringly typed'입니다. 따라서value열은 여러 가지 고유 데이터 형식(JSON,string,integer,decimal)을 가진config를 포함할 수 있지만 모든 것을 문자열(열의 필드 형식)로 저장해야 합니다.

여러 유형의 열을 추가하여 이러한 문제를 해결하고 다양한 구성 옵션을 올바른 데이터 유형에 저장하기로 결정하더라도 테이블의 범위가 확대되고 기록에 다음과 같은 빈 값이나 빈 값이 대량으로 남게 됩니다

.
구성 옵션
문자열 값
int 값
암호화api 키
asD2-f21Fa-126d-a
무효이었어
갱신 초
무효이었어
20

이것은 좋지 않습니다. 코드 라이브러리에서 데이터를 비관적으로 처리하도록 하기 때문입니다. 즉, 기록된 주어진 값이 존재하지 않을 수도 있는 것 같습니다.

사실 이 문제는 너에게 자주 나타나지 않을 것이다.자신의 프로그램에 편집 가능한 프로그램 범위 설정을 추가하려는 모든 사람들에게 이것은 의심할 여지없이 화제이다.배달과 TL;박사는 SRT와 EAV가 가장 유행하는 해결 방안인 것 같다고 생각한다.