통화 값에 가장 적합한 SQL 데이터 유형은 무엇입니까? MySQL을 사용하고 있지만 데이터베이스 독립적 유형을 선호합니다.

Decimal(19,4)대부분의 경우 와 같은 것이 일반적으로 잘 작동합니다. 저장해야하는 숫자의 요구에 맞게 스케일과 정밀도를 조정할 수 있습니다. SQL Server에서도 money표준 이 아니기 때문에 " " 를 사용하지 않는 경향이 있습니다.

한 데이터베이스에서 다른 데이터베이스로 마이그레이션하는 경우 DECIMAL (19,4) 및 DECIMAL (19,4)가 다른 것을 의미 할 수 있습니다.

( http://dev.mysql.com/doc/refman/5.1/en/precision-math-decimal-changes.html )

    DBASE : 10,5 (10 개의 정수, 10 진수 5)
    MYSQL : 15,5 (15 자리, 10 개의 정수 (15-5), 5 진수)

계산에 필요한 소수 자릿수를 계산하는 것도 중요합니다.

나는 백만 주가의 계산이 필요한 주가 응용 프로그램을 작업했습니다. 인용 된 주가는 7 자리의 정확도로 저장해야했습니다.

Assaf의 답변

돈이 얼마나 있는지에 따라 ...

flippant처럼 들리지만 실제로는 관련이 있습니다.

열 중 하나 (GrossRate)가 Decimal (11,4)로 설정되어 있고 제품 ​​부서가 방금 놀라운 리조트에서 객실 계약을 체결했기 때문에 오늘만 요율표에 레코드를 삽입하지 못하는 문제가있었습니다. Bora Bora에서는 1 박에 수백만 대의 Pacific Franc을 판매합니다. 10 년 전에 데이터베이스 스키마가 설계되었을 때 절대로 바뀌지 않았습니다.

응용 프로그램을 회계는 정수로 값을 저장하는 것은 매우 일반적입니다 (일부는 심지어는 말할하도록 멀리 갈 유일한 방법). 아이디어를 얻으려면 필요한 금액을 100, 1000, 10000 등으로 계산하고 필요한 금액을 100, 1000, 10000 등으로 가정하십시오. 따라서 센트 만 저장해야하고 안전하게 반올림 또는 내림 할 수있는 경우 100을 곱하면됩니다.이 예에서는 10023을 저장할 정수로 만듭니다. 데이터베이스의 공간을 절약하고 두 부동 소수점을 비교하는 것보다 두 정수를 비교하는 것이 훨씬 쉽습니다. 내 $ 0.02.

초 늦은 입장이지만 GAAP는 좋은 경험입니다 ..

애플리케이션이 최대 1 조 달러의 돈을 처리해야하는 경우 다음과 같이 작동합니다. 13,2 GAAP (일반적으로 허용되는 회계 원칙)를 준수해야하는 경우 다음을 사용하십시오. 13,4

일반적으로 산출물을 13,2로 반올림하기 전에 13,4의 금액을 합산해야합니다.

출처 : MySQL에 금전적 가치를 저장하기위한 최상의 데이터 유형

DECIMAL(19,2)기본적으로 모든 금전적 가치에 대해 같은 것을 사용할 수 있지만 1,000 달러 미만의 값만 저장할 경우 귀중한 데이터베이스 공간을 낭비하게됩니다.

대부분의 구현에서는 DECIMAL(N,2)충분할 것입니다. 여기서 값은 N최소한 .해당 필드에 저장 될 것으로 예상되는 최대 합계 이전의 자릿수 입니다 + 5. 따라서 999999.99보다 큰 값을 저장할 것으로 예상되지 않으면 기대 값이 DECIMAL(11,2)변경 될 때까지 충분해야합니다.

당신이 원하는 경우 회계 기준의 준수를, 당신은 함께 갈 수 DECIMAL(N,4)의 값이 어디에, N전과 자릿수 적어도입니다 .혹시 그 필드에 저장 될 것으로 예상되는 가장 큰 합계가 + 7.

데이터의 특성에 따라 다릅니다. 미리 숙고해야합니다.

내 경우

• 돈 거래 기록을 위해 부호없는 10 진수 (13,4)
  • 효율적인 저장 (어쨌든 소수점의 각 측면에 4 바이트) 1
  • GAAP 호환
• 집계에 대해 부호없는 10 진수 (19,4)
  • 총 수십억 건의 거래를위한 더 많은 공간이 필요합니다
  • MS Currency 데이터 형식의 준 준수는 2를 해치지 않습니다
  • 레코드 당 더 많은 공간이 필요하지만 (11 바이트-7 개의 왼쪽 및 4 개의 오른쪽) 집계에 대한 레코드 수가 적으므로 괜찮습니다 1
• 환율 10 진수 (10,5)
  • 그들은 일반적으로 5 자리로 인용되므로 1.2345 및 12.345와 같은 값을 찾을 수 있지만 12345.67890은 찾을 수 없습니다.
  • 그것은 널리 퍼져있는 규약이지만 체계화 된 표준은 아닙니다 (적어도 나의 빠른 검색 지식)
  • 동일한 스토리지로 10 진수 (18,9)로 만들 수 있지만 데이터 유형 제한은 유용한 내장 검증 메커니즘입니다.

왜 (M, 4)?

• 천 페니로 분리 된 통화가 있습니다
• "Unidad de Fermento", "CLF"와 같은 금액이 소수점 4 자리로 표현됩니다. 3 , 4
• GAAP 호환

거래

• 낮은 정밀도 :
  • 적은 저장 비용
  • 더 빠른 계산
  • 계산 오류 위험 감소
  • 빠른 백업 및 복원
• 더 높은 정밀도 :
  • 향후 호환성 (숫자가 증가하는 경향이 있음)
  • 개발 시간 절약 (한계가 충족 될 때 시스템 절반을 다시 구축 할 필요가 없음)
  • 불충분 한 저장 정밀도로 인한 생산 실패 위험 감소

호환 익스트림

MySQL에서는 십진수 (65,30)를 사용할 수 있지만 전송 옵션을 열어 두려면 규모에 31, 정밀도에 30을 사용하는 것이 한계입니다.

가장 일반적인 RDBMS에서 최대 규모 및 정밀도 :

            정밀 스케일
오라클 31 31
T-SQL 38 38
MySQL 65 30
PostgreSQL 131072 16383

6 , 7 , 8 , 9

합리적인 극단

2. 왜 (27,4)?
   • 언제 짐바브웨 달러를 시스템에 저장해야하는지 알 수 없음

9 월 2015 짐바브웨 정부는 1 USD 35 천조 짐바브웨 달러의 비율로 미국 달러 짐바브웨 달러를 교환 할 것이라고 말했다 5

우리는 "그래, 물론 ... 나는 그 미친 인물이 필요하지 않다"고 말하는 경향이있다. 짐바브웨 사람들도 그런 말을했습니다. 얼마 전까지 만해도

짐바브웨 달러로 1 백만 달러 (USD)의 거래를 기록해야한다고 상상해 봅시다 (오늘은 아닐 수도 있지만 10 년 후에는 어떻게 보일지 누가 알겠습니까?).

1. (1 백만 달러) * (35 Quadrylion ZWL) = (10 ^ 6) * (35 * 10 ^ 15) = 35 * 10 ^ 21
2. 우리는 필요합니다 :
   • "35"를 저장하는 2 자리 숫자
   • 0을 저장하는 21 자리
   • 소수점 오른쪽 4 자리
3. 이것은 십진수 (27,4)를 만들어서 각 항목에 대해 15 바이트를 소비합니다
4. 우리는 왼쪽에 하나의 숫자를 추가 비용없이 추가 할 수 있습니다-15 바이트에는 10 진수 (28,4)가 있습니다
5. 이제 짐바브웨 달러로 표현 된 미화 10ml의 미화 거래를 저장하거나, 또 다시 일어날 수없는 고혈압 공격으로부터 보호 할 수 있습니다.

비록 이것이 늦었지만 다른 사람에게 도움이 될 것입니다. 내 경험과 연구에서 나는 decimal (19, 6)을 알고 받아 들였습니다. php와 mysql을 사용할 때입니다. 많은 돈과 환율로 일할 때