데이터베이스에 단위를 저장하는 가장 좋은 방법

한 가지 또는 다른 것을 나타내는 수백 개의 열이있는 큰 (SQLServer) 데이터베이스를 상속했습니다. 이러한 값의 단위 (예 : "갤런", "인치"등)는 확장 속성의 MS_Description 필드에 저장됩니다. 이 정보를 저장하는 더 좋은 방법이 있는지 궁금합니다. 문서화 목적으로는 문제가 없지만이 데이터를 기반으로 강력한 단위 변환 계산을 수행하는 것은 어려울 것입니다. 이 시점에서 나는 침습적 인 변화를 만들 준비가되어 있지 않지만, 기회가 생기면 권장되는 모범 사례는 무엇입니까? 내 머리 꼭대기의 옵션에는 다음이 포함될 수 있습니다.

• 열 이름을 포함 된 단위 (예 : "TotalVolumeInGallons")로 변경하십시오. 이렇게하면 정보를 좀 더 쉽게 사용할 수 있지만 여전히 나에게 약한 것 같습니다.
• 모든 "Amount"열에 해당하는 별도의 "Units"열을 추가하십시오 (이 열은 nvarchar이거나 별도의 Units 테이블에 대한 외래 키일 수 있으므로 단위 변환을보다 쉽게 ​​계산할 수 있습니다). 많은 열이 데이터베이스의 크기를 상당히 두 배로 늘릴 수 있습니다.
• 확장 속성에서 유닛 전용으로 새 필드를 만듭니다. (불행히도 이것이 Units 테이블의 외래 키가 될 수는 없다고 생각합니다.)
• 내가 간과하는 또 다른 아이디어가 있습니까?

업데이트 : @ Todd Everett의 답변을 읽은 후 가능한 해결책이 생겼으므로 나 자신의 질문에 대답 할 것입니다. (아래 참조)

수백 개의 열을 언급 했으므로 EAV 디자인을 고려할 것 입니다. Joe Celko가 이에 대해 경고 하지만 귀하의 사용 사례에 적용될 수 있다고 생각합니다. 모든 "금액"이 숫자 인 것처럼 들리므로 Joe가 설명하는 캐스팅 문제와 모든 "값"을 문자열로 만들 필요가 없습니다. 모든 금액이 정수이면 더 잘 작동하지만 일부는 소수이면 작동 할 수 있습니다. 측정 단위를 고려하면 David Hay 의이 기사 를 기반으로 한 한 단계 더 나아가 "범용 데이터 모델"스타일 모델을 구현할 수 있으며 그의 책 Data Model Patterns : Conventions of Thought에 설명되어 있습니다.. 이 모델은 필요한 경우 어떤 "양"을 어떤 "물"에 적용 할 것인지 구성 할 수있는 추가적인 이점이 있습니다. 162 페이지의 책에 표시된 추가 단계는 여러 측정 단위 사이를 변환하는 데 사용할 수있는 측정 단위 변환 테이블입니다. 예를 들면 다음과 같습니다.

UOM Conversion              

UOM From    UOM To        Cal Step  Operator Factor Constant
Kilograms   Pounds        1         *        2.2
Celsius     Fahrenheit    1         *        1.8
Celsius     Fahrenheit    2         +               32

이것은 Kg에서 Lb로 변환하는 첫 번째 단계는 Kg에 2.2를 곱하는 것입니다. 또한 변환에 상수 값과 여러 단계를 생성하는 기능이 포함되어야하는 경우 상수도 있습니다. 따라서 Celsius를 화씨로 변환 할 때 Celsius에 1.8을 곱한 다음 32를 더합니다. 키는 UOM에서 UOM으로, 계산 단계입니다.

그건 내 2 센트 가치 야 이 참조가 현재 디자인에서 재부팅 할 수있는 기회를 얻을 수 있다면 좋은 음식을 제공하기를 바랍니다.

모든 일.

두 번째 경우에는 사과와 오렌지를 추가 할 수 없으므로 데이터를 잘못 해석하기가 매우 쉽습니다.

또한 변환은 매우 안전하지 않으며 반올림 오류, 오버플로 등의 영향을 받기 쉽습니다.

또한 비중 및 온도와 같은 물리적 문제가 있습니다. 20 갤런의 물을 파운드로 변환하려면 물의 밀도를 알아야합니다. 그러나 물의 밀도는 온도에 따라 변하기 때문에 측정과 동시에 발생하는 밀도 또는 온도를 알고 부피 측정 계수를 사용해야합니다.

확장 속성의 경우 문서에만 유용합니다. 문서에는 열 이름이 좋습니다. 칼럼이 이름으로 고정 장치에 있다고 함축 된 문제는 측정 단위를 변경할 때 코너에 갇히게된다는 것입니다. 새로운 고객은 갤런이 아닌 배럴의 오일을 원합니다. 자체 데이터베이스이지만 열 이름이 잘못되었습니다.

또 다른 옵션은 표준 측정을 고정 된 단위 (즉, 항상 킬로그램 및 미터)로 다양한 원래 측정 값을 저장하는 것입니다. 고정 장치의 집계 작업은 양호해야하지만 (예를 들어 온도를 추가하지 않는 경우는 제외) 원래 측정 값을 잃지 않습니다.

과거에 저에게 효과적이었던 간단한 솔루션은 모든 데이터를 '기본'단위로 저장하는 것입니다. 예를 들어, 길이의 기본 단위는 밀리미터이고 무게의 기본 단위는 킬로그램 일 수 있습니다. 이 솔루션을 사용하면 기존 데이터 중 일부를 기본 단위로 변환해야 할 수도 있습니다 (아직없는 경우).

표준 기본 장치에 모든 데이터가 있으면 이제 시스템 전체의 가정이므로 장치 자체를 데이터베이스 자체에 저장할 필요가 없습니다. 각 단위 유형에 필요한 표시 단위 (예 : 길이, mm, 인치, cm, m 표시 여부)는 응용 프로그램 / 클라이언트 도메인 문제가되며 로컬 저장소에 저장할 수 있습니다.

새로운 측정 단위가 거의 변경되지 않기 때문에 지원되는 다양한 단위 간 변환을위한 단위 변환 표를 응용 프로그램 내에서 하드 코딩 할 수 있습니다.

NB는 또 다른 문제에 대한 관련 솔루션으로 타임 스탬프를 데이터베이스에 저장할 때 항상 '기본'단위-UTC에 저장합니다 .

주제에 관한 또 다른 관련 Q & A ...

• /programming/12977021/best-practice-for-storing-weights-in-a-sql-database

• 여기에는 실제 측정을 저장할 때 부동 소수점 열 유형을 사용하는 것이 가장 좋은 방법에 대한 유용한 정보가 포함되어 있습니다.

모든 단위는 다음 공식을 사용하여 동일한 유형의 다른 단위로 변환 할 수 있습니다.

y = ((x + xOffset) * multiplicand / denominator) + yOffset

단위 유형과이 4 개의 값을 포함하는 테이블을 작성합니다.

From Unit     To Unit      Unit Type    From Offset    Multiplicand    Denominator    To Offset
'milligrams'  'grams'      'mass'       0              1               1000           0
'grams'      'kilograms'   'mass'       0              1               1000           0
'grams'      'ounces'      'mass'       0              100000          2835           0
'ounces'     'pound'       'mass'       0              1               16             0

변환 할 가능성이있는 모든 측정 값을 목록의 양쪽에 추가 한 후에는 오프셋을 무시하고 곱셈과 분모, To Unit과 From Unit을 간단히 바꾸어 역 연산을 삽입하는 쿼리를 실행하십시오.

모든 유형간에 전환을 추가하려면 교차 조인 일부 필터를 사용하면 나머지 전환을 삽입 할 수 있습니다.

@Todd Everett의 답변을 읽은 후 해결책이 생겨서 내 자신의 질문에 대답 할 것입니다. 내가 내가 할거야 생각하는 것은 별도 작성하는 것입니다 ColumnUnits네 개의 열이있는 테이블을 : Schema, Table, Column, UnitsID(UnitsID는 FK는 별도의에 어디 UnitsOfMeasure따라서 측정의 관련 장치에 대한 지정된 열을 매핑 테이블). 이 아이디어의 가장 큰 단점은 개발자가 열이나 테이블의 이름을 바꿀 때마다이 테이블을 편집해야한다는 점입니다 ( DDL 트리거를 사용할 수 있습니까? ] 그렇지 않으면 시스템이 중단됩니다. 그러나 그러한 이름 바꾸기가 드물고 개발자 상점이 작다고 가정하면 (이 경우 한 사람 만)이 아키텍처는 작동 가능해야합니다. 장점은 현재 DB에 대한 침입적인 변경이 필요하지 않으며 원래 게시물의 두 번째 옵션이 요구하는 것처럼 행 당 한 번이 아니라 모든 열에 대해 한 번만 값을 저장해야한다는 것입니다.