외래 키 참조로 숫자 값 대신에 열 값을 사용하십시오.

Question

제목에이를 표현하는 방법을 잘 모르겠습니다. 그래서 여기 거래는 다음과 같습니다, 이상적으로는 통화 기호 (마스터 데이터)를 저장하는 다른 테이블이 있어야합니다

PAIR_ID | BASE_CURRENCY | TERM_CURRENCY | ATTRIBUTE1 | ATTRIBUTE2 ... 

BASE_CURRENCY에서 CURRENCY_SYMBOLS 및 외래 키 말 : 나는 환율에 사용되는 통화 쌍에 대한 정보를 저장하는 테이블이 이 테이블에 TERM_CURRENCY. 그러나 나는 여기서 두 가지 접근법을 혼동하고있다.

접근법 1 :

CURRENCY_PAIRS :

PAIR_ID | BASE_CURRENCY_ID | TERM_CURRENCY_ID | ATTRIBUTE1 | ATTRIBUTE2 ... 

CURRENCY_SYMBOLS :

SYMBOL_ID | SYMBOL 

BASE_CURRENCY_ID & TERM_CURRENCY_ID]을 참조로 SYMBOL_ID

또는 접근법 2을 ncing : 오히려 정말 값을 추가하지 않는 symbol_id을하는 것보다, 그냥이 :

CURRENCY_PAIRS :

PAIR_ID | BASE_CURRENCY | TERM_CURRENCY | ATTRIBUTE1 | ATTRIBUTE2 ... 

CURRENCY_SYMBOLS :

SYMBOL 

과 BASE_CURRENCY & TERM_CURRENCY은 SYMBOL을 직접 참조합니다.

어느 쪽이 더 좋을지 모르겠다. 접근 방식 1은 이상적이지만 실제로 이점이 없다. 실제로 모든 쿼리에서 데이터를 검색하려면 추가 조인이 필요하다.

접근법 2가 더 효율적이지만 어떻게 든 올바르지 않습니다.

나는 함께해야 할 포인터가 있습니까?

Answer 1

접근에 인덱싱 장점이 있지만 그것으로 몇 가지 문제가있다.

1. 외래 키 참조가 더 많은 공간을 차지할 수 : 만 3 자리 ISO 코드와 함께 사용하고 있기 때문에 나는 정말 당신에게 많이 적용되지 않습니다 그들 모두도 1, 2 생각을 나열합니다 . VARCHAR을 얼마 동안 만들어야하는지에 따라, 그들은 외래 키, 즉 바이트 또는 단락과 같은 더 많은 공간을 차지할 수 있습니다. 이러한 외래 키를 참조하는 개체 수가 많으면 추가됩니다. 일부 DB는 이것에 대해 영리하고 참조 테이블에서 해시 테이블 참조로 VARCHAR를 대체하지만 일부는 그렇지 않습니다. 어떤 DB도 그 시간의 100 %는 똑똑하지 않습니다.
2. 비즈니스 키로 데이터베이스 키 (적어도 최종 사용자에게는 의미가 없어야 함)가 노출되어 있어야합니다. 보스가 "USD"를 "$"또는 "Dollars"로 바꾸려면 어떻게해야합니까? 이 경우 조회 테이블을 추가해야하며,이 방법을 우선적으로 사용하는 주된 이유가 없습니다. 그렇지 않으면 CURRENCY_SYMBOLS의 값을 변경해야합니다. 까다로울 수 있습니다 (# 3 참조).
3. 유지 관리가 어렵습니다. 때때로 국가가 변경됩니다. 그들은 유로화를 입력/떠날 때, 쿠데타가있을 때 통화를 변경합니다. 가끔은 통화의 이름 만 정치적으로 부정확합니다. 이 접근 방식을 사용하면 CURRENCY_SYMBOLS에서 항목을 변경해야 할뿐만 아니라 해당 변경 사항을 참조하는 DB의 모든 객체에 해당 변경 사항을 계단식으로 적용해야합니다. 그것은 엄청나게 느릴 수 있습니다. 또한 상수 키가 없으므로 프로그래머가 비즈니스 논리에 하드 와이어하는 키는 이제 변경된 동일한 키입니다. 모든 코드베이스를 통해 행운을 빕니다.

나는 종종 "하이브리드"방식을 사용합니다. 즉, 접근 방식 1을 사용하지만 ID가 매우 짧은 VARCHAR (최대 3 자 또는 4 자)를 사용합니다. 이렇게하면 각 항목은 최종 사용자에게 노출되는 "SYMBOL"필드를 가질 수 있으며 필요에 따라 하나의 테이블 항목을 수정하여 변경할 수 있습니다. 또한 개발자는 "14"가 엔이고 "27"이 미국 달러임을 기억하는 것보다 약간 의미있는 ID를가집니다. 이 키는 노출되지 않으므로 개발자가 The Great Revolution 이전 통화 인 YEN임을 기억하는 한 변경하지 않아도됩니다. 비즈니스 논리를위한 쿼리 일 경우 조인을 사용하지 않고 도망 갈 수 있습니다. 그것은 어떤 것들에는 느리지 만 다른 것들에게는 더 빠릅니다. YMMV.

Answer 2

두 경우 모두 조인을 저장하지 않으므로 조인이 필요합니다.

옵션 1은 ID를 추가합니다. 이 ID는 기본적으로 클러스터 된 색인을 갖습니다. 데이터가 가장 낮은 ID가 먼저 있고 가장 높은 ID가 맨 끝에있는 디스크에서 정렬된다는 의미입니다. 이것은 미래에 쉽게 개발할 수있는 유연한 옵션입니다.

옵션 2는 기호를 통화 쌍 테이블에 하드 코딩합니다. 즉 나중에 그룹화를 위해 기호 테이블에 다른 열을 추가하려는 경우 symbol_id 필드를 만들고 통화 쌍 테이블의 모든 레코드를 업데이트해야합니다. 이는 유지 보수 비용을 증가시킵니다.

오버 헤드가 적고 유지 관리가 더 쉽기 때문에 항상이 종류의 테이블에 int ID 필드를 추가합니다.

또한이 처음에는 좋은 생각처럼 보인다 옵션 1

Answer 3

기호 ID를 사용하는 것이 좋지만 가까이 있습니다. 이것은 실제로 기호가 아닌 통화 약어를 의미한다고 가정합니다. 나는 일반적으로 대리 숫자 키를 선호한다. 문자열을 사용해야하는 경우 국제 문자를 피하고 싶습니다.

하나의 문제는 국제 표준이 아니거나 시간이 지남에 따라 변경 될 수있는 통화를 다루는 것입니다. 지난 15 년 동안 우리는 주로 유로화로 많은 통화가 변경되는 것을 보았습니다. 그러나 터키 리라가 재평가 된 다른 사례가 있습니다. 따라서 자신의 정의를 사용하면 두 통화를 구별하지 못할 수 있습니다.

또한 응용 프로그램에 따라 공식 통화가 아닌 경우 무언가를 "통화"라고 할 수 있습니다. 이것은 금융 상품이 일종의 통화 바스켓 (또는 다른 벤치 마크 메트릭)을 사용하여 가격을 책정 할 때 발생하지만, "통화 - 바구니 채권"은 시스템의 다른 채권과 동일한 방식으로 취급하려고합니다.

통화 문제는 이전에 생각했던 것보다 복잡하기 때문에 응용 프로그램의 유연성을 높이기 위해 대리 키가 있어야합니다.