Bạn nên chọn các kiểu dữ liệu TIỀN hoặc DECIMAL (x, y) trong SQL Server?

Tôi tò mò liệu có hay không có sự khác biệt thực sự giữa moneykiểu dữ liệu và một cái gì đó giống như decimal(19,4)(đó là những gì tiền sử dụng trong nội bộ, tôi tin).

Tôi biết rằng đó moneylà cụ thể cho SQL Server. Tôi muốn biết nếu có một lý do thuyết phục để chọn cái này hơn cái kia; hầu hết các mẫu SQL Server (ví dụ: cơ sở dữ liệu AdventureWorks) sử dụng moneyvà không sử dụng decimalcho những thứ như thông tin về giá.

Tôi có nên tiếp tục sử dụng kiểu dữ liệu tiền hay thay vào đó là lợi ích của việc sử dụng số thập phân? Tiền có ít ký tự để nhập, nhưng đó không phải là lý do hợp lệ :)

Không bao giờ nên sử dụng tiền. Nó không chính xác, và nó là rác nguyên chất; luôn luôn sử dụng số thập phân / số.

Chạy cái này để xem ý tôi là gì:

DECLARE
    @mon1 MONEY,
    @mon2 MONEY,
    @mon3 MONEY,
    @mon4 MONEY,
    @num1 DECIMAL(19,4),
    @num2 DECIMAL(19,4),
    @num3 DECIMAL(19,4),
    @num4 DECIMAL(19,4)

    SELECT
    @mon1 = 100, @mon2 = 339, @mon3 = 10000,
    @num1 = 100, @num2 = 339, @num3 = 10000

    SET @mon4 = @mon1/@mon2*@mon3
    SET @num4 = @num1/@num2*@num3

    SELECT @mon4 AS moneyresult,
    @num4 AS numericresult

Đầu ra: 2949.0000 2949,8525

Đối với một số người nói rằng bạn không chia tiền theo tiền:

Đây là một trong những truy vấn của tôi để tính toán tương quan và thay đổi điều đó thành tiền cho kết quả sai.

select t1.index_id,t2.index_id,(avg(t1.monret*t2.monret)
    -(avg(t1.monret) * avg(t2.monret)))
            /((sqrt(avg(square(t1.monret)) - square(avg(t1.monret))))
            *(sqrt(avg(square(t2.monret)) - square(avg(t2.monret))))),
current_timestamp,@MaxDate
            from Table1 t1  join Table1 t2  on t1.Date = traDate
            group by t1.index_id,t2.index_id

SQLMenace cho biết tiền không chính xác. Nhưng bạn không nhân / chia tiền với tiền! Bao nhiêu là 3 đô la 50 xu? 150 đô la? Bạn nhân / chia tiền theo vô hướng, nên là số thập phân.

DECLARE
@mon1 MONEY,
@mon4 MONEY,
@num1 DECIMAL(19,4),
@num2 DECIMAL(19,4),
@num3 DECIMAL(19,4),
@num4 DECIMAL(19,4)

SELECT
@mon1 = 100,
@num1 = 100, @num2 = 339, @num3 = 10000

SET @mon4 = @mon1/@num2*@num3
SET @num4 = @num1/@num2*@num3

SELECT @mon4 AS moneyresult,
@num4 AS numericresult

Kết quả trong kết quả chính xác:

Moneyresult numresult
--------------------- ----------------------------- ----------
2949,8525 2949,8525

moneylà tốt miễn là bạn không cần nhiều hơn 4 chữ số thập phân và bạn chắc chắn rằng số vô hướng của mình - không đại diện cho tiền - là decimals.

Mọi thứ đều nguy hiểm nếu bạn không biết mình đang làm gì

Ngay cả các loại thập phân có độ chính xác cao cũng không thể lưu trong ngày:

declare @num1 numeric(38,22)
declare @num2 numeric(38,22)
set @num1 = .0000006
set @num2 = 1.0
select @num1 * @num2 * 1000000

1,000000 <- Nên là 0,6000000

Các moneyloại là số nguyên

Các đại diện văn bản của smallmoneyvà decimal(10,4)có thể trông giống nhau, nhưng điều đó không làm cho chúng có thể thay thế cho nhau. Bạn co rúm người khi nhìn thấy ngày được lưu trữ dưới dạng varchar(10)? Đây là điều tương tự.

Đằng sau hậu trường, money/ smallmoneychỉ là một bigint/ int Dấu thập phân trong biểu diễn văn bản moneylà lông tơ trực quan, giống như dấu gạch ngang trong một ngày yyyy-mm-dd. SQL không thực sự lưu trữ những thứ đó trong nội bộ.

Về decimalvs money, chọn bất cứ điều gì phù hợp với nhu cầu của bạn. Các moneyloại tồn tại vì lưu trữ giá trị kế toán dưới dạng bội số nguyên của 1/10000 đơn vị là rất phổ biến. Ngoài ra, nếu bạn đang xử lý tiền thực tế và các phép tính ngoài phép cộng và trừ đơn giản, bạn không nên làm điều đó ở cấp cơ sở dữ liệu! Thực hiện ở cấp ứng dụng với thư viện hỗ trợ Làm tròn Ngân hàng (IEEE 754)

Tôi nhận ra rằng WayneM đã tuyên bố rằng anh ta biết rằng tiền dành riêng cho SQL Server. Tuy nhiên, anh ta đang hỏi liệu có bất kỳ lý do nào để sử dụng tiền trên số thập phân hoặc ngược lại không và tôi nghĩ một lý do rõ ràng vẫn phải được nêu và đó là sử dụng số thập phân có nghĩa là một điều ít phải lo lắng hơn nếu bạn phải thay đổi DBMS của mình - điều đó có thể xảy ra.

Làm cho hệ thống của bạn linh hoạt nhất có thể!

Vâng, tôi thích MONEY! Đó là một byte rẻ hơn DECIMALvà các tính toán thực hiện nhanh hơn bởi vì (dưới vỏ bọc) các phép toán cộng và trừ về cơ bản là các phép toán số nguyên. Ví dụ của SQLMenace là một cảnh báo tuyệt vời cho việc không biết rằng có thể áp dụng tương tự cho các INTví dụ, trong đó kết quả sẽ bằng không. Nhưng đó không phải là lý do để không sử dụng số nguyên mà phù hợp .

Vì vậy, nó hoàn toàn 'an toàn' và phù hợp để sử dụng MONEYkhi những gì bạn đang giải quyết MONEYvà sử dụng nó theo các quy tắc toán học mà nó tuân theo (giống như INTeger).

Sẽ tốt hơn nếu SQL Server thúc đẩy sự phân chia và nhân của MONEYs thành DECIMAL(hoặc FLOATs?) - có thể, nhưng họ đã không chọn làm điều này; họ cũng không chọn quảng bá INTcho người khác đến FLOATs khi chia chúng.

MONEYkhông có vấn đề chính xác; việc DECIMALcó một loại trung gian lớn hơn được sử dụng trong quá trình tính toán chỉ là một 'tính năng' của việc sử dụng loại đó (và tôi thực sự không chắc chắn rằng 'tính năng' đó kéo dài bao xa).

Để trả lời câu hỏi cụ thể, một "lý do thuyết phục"? Chà, nếu bạn muốn hiệu suất tối đa tuyệt đối ở một SUM(x)nơi xcó thể DECIMALhoặc MONEY, thì MONEYsẽ có lợi thế.

Ngoài ra, đừng quên người anh em họ nhỏ hơn, điều SMALLMONEYchỉnh 4 byte, nhưng nó tối đa hóa ở mức 214,748.3647- khá nhỏ đối với tiền ăn tiền và vì vậy thường không phù hợp.

Để chứng minh điểm xung quanh bằng cách sử dụng các loại trung gian lớn hơn, nếu bạn chỉ định rõ ràng trung gian cho một biến, thì cũng DECIMALgặp phải vấn đề tương tự:

declare @a decimal(19,4)
declare @b decimal(19,4)
declare @c decimal(19,4)
declare @d decimal(19,4)

select @a = 100, @b = 339, @c = 10000

set @d = @a/@b

set @d = @d*@c

select @d

Sản xuất 2950.0000(được, vì vậy, ít nhất là DECIMALđược làm tròn chứ không phải MONEYcắt ngắn giống như một số nguyên.)

Chúng ta vừa gặp một vấn đề rất giống nhau và giờ đây tôi rất là +1 vì không bao giờ sử dụng Tiền ngoại trừ trong bản trình bày cấp cao nhất. Chúng tôi có nhiều bảng (hiệu quả là một chứng từ bán hàng và hóa đơn bán hàng), mỗi bảng chứa một hoặc nhiều trường Tiền vì lý do lịch sử và chúng tôi cần thực hiện một phép tính pro-rata để tính ra tổng số hóa đơn Thuế có liên quan đến mỗi dòng trên chứng từ bán hàng. Tính toán của chúng tôi là

vat proportion = total invoice vat x (voucher line value / total invoice value)

Điều này dẫn đến việc tính toán tiền / tiền trong thế giới thực, gây ra lỗi quy mô trên phần phân chia, sau đó nhân lên thành một tỷ lệ không chính xác. Khi các giá trị này được thêm vào sau đó, chúng tôi sẽ kết thúc bằng một tỷ lệ tỷ lệ không cộng với tổng giá trị hóa đơn. Nếu một trong các giá trị trong ngoặc là một số thập phân (tôi sắp bỏ một trong số chúng như vậy) thì tỷ lệ vat sẽ chính xác.

Khi các dấu ngoặc không có ở đây ban đầu được sử dụng để làm việc, tôi đoán vì các giá trị lớn hơn có liên quan, nó đã mô phỏng hiệu quả ở quy mô cao hơn. Chúng tôi đã thêm dấu ngoặc vì nó thực hiện phép nhân trước tiên, trong một số trường hợp hiếm hoi thổi độ chính xác có sẵn cho phép tính, nhưng điều này hiện đã gây ra lỗi phổ biến hơn nhiều này.

Như một điểm đối với lực đẩy chung của các câu trả lời khác. Xem nhiều lợi ích của loại dữ liệu tiền Money! trong Hướng dẫn về công cụ quan hệ của SQLCAT

Cụ thể tôi sẽ chỉ ra những điều sau đây

Làm việc trên các triển khai của khách hàng, chúng tôi đã tìm thấy một số con số hiệu suất thú vị liên quan đến loại dữ liệu tiền. Ví dụ: khi Dịch vụ phân tích được đặt thành loại dữ liệu tiền tệ (từ gấp đôi) để khớp với loại dữ liệu tiền của SQL Server, tốc độ xử lý (hàng / giây) được cải thiện 13%. Để có được hiệu suất nhanh hơn trong Dịch vụ tích hợp máy chủ SQL (SSIS) để tải 1,18 TB trong vòng ba mươi phút, như đã lưu ý trong SSIS 2008 - hiệu suất ETL kỷ lục thế giới, người ta đã quan sát thấy việc thay đổi bốn cột thập phân (9,2) với kích thước là 5 byte trong bảng LINECEM của TPC-H thành tiền (8 byte) đã cải thiện tốc độ chèn hàng loạt thêm 20% ... Lý do cho sự cải thiện hiệu suất là do giao thức Luồng dữ liệu dạng bảng (TDS) của SQL Server, có nguyên tắc thiết kế chính để truyền dữ liệu ở dạng nhị phân nhỏ gọn và càng gần với định dạng lưu trữ nội bộ của SQL Server. Theo kinh nghiệm, điều này đã được quan sát trong SSIS 2008 - thử nghiệm hiệu suất ETL kỷ lục thế giới bằng cách sử dụng Kernrate; giao thức giảm đáng kể khi loại dữ liệu được chuyển sang tiền từ số thập phân. Điều này làm cho việc chuyển dữ liệu hiệu quả nhất có thể. Một kiểu dữ liệu phức tạp cần phân tích cú pháp và chu kỳ CPU bổ sung để xử lý hơn kiểu chiều rộng cố định.

Vì vậy, câu trả lời cho câu hỏi là "nó phụ thuộc". Bạn cần cẩn thận hơn với các thao tác số học nhất định để duy trì độ chính xác nhưng bạn có thể thấy rằng các cân nhắc về hiệu suất làm cho điều này đáng giá.

Tôi muốn đưa ra một cái nhìn khác về TIỀN so với SỐ, chủ yếu dựa vào chuyên môn và kinh nghiệm của riêng tôi ... Quan điểm của tôi ở đây là TIỀN, vì tôi đã làm việc với nó trong một thời gian dài và chưa bao giờ thực sự sử dụng SỐ MỘT .. .

KIẾM TIỀN:

• Kiểu dữ liệu gốc . Nó sử dụng kiểu dữ liệu riêng ( số nguyên ) giống như thanh ghi CPU (32 hoặc 64 bit), vì vậy phép tính không cần chi phí không cần thiết để nó nhỏ hơn và nhanh hơn ... TIỀN cần 8 byte và SỐ (19, 4 ) cần 9 byte (lớn hơn 12,5%) ...

  TIỀN nhanh hơn miễn là nó được sử dụng cho nó có nghĩa là (như tiền). Nhanh như thế nào? SUMThử nghiệm đơn giản của tôi trên 1 triệu dữ liệu cho thấy TIỀN là 275 ms và NUMERIC 517 ms ... Nhanh gấp đôi ... Tại sao thử nghiệm SUM? Xem điểm Pro tiếp theo

• Tốt nhất cho tiền . TIỀN là tốt nhất để lưu trữ tiền và thực hiện các hoạt động, ví dụ, trong kế toán. Một báo cáo có thể chạy hàng triệu bổ sung (SUM) và một vài phép nhân sau khi thao tác SUM được thực hiện. Đối với các ứng dụng kế toán rất lớn, nó nhanh gần gấp đôi và nó cực kỳ quan trọng ...
• Độ chính xác thấp của tiền . Tiền trong cuộc sống thực không cần phải rất chính xác. Ý tôi là, nhiều người có thể quan tâm khoảng 1 cent USD, nhưng khoảng 0,01 cent USD thì sao? Trên thực tế, ở nước tôi, các ngân hàng không còn quan tâm đến xu (chữ số sau dấu phẩy thập phân); Tôi không biết về ngân hàng Hoa Kỳ hoặc quốc gia khác ...

KIẾM TIỀN:

• Độ chính xác hạn chế . TIỀN chỉ có bốn chữ số (sau dấu phẩy), do đó, nó phải được chuyển đổi trước khi thực hiện các thao tác như chia ... Nhưng một lần nữa money, không cần phải chính xác và được sử dụng như tiền, không chỉ là một con số...

Nhưng ... Lớn, nhưng đây thậm chí là ứng dụng của bạn liên quan đến tiền thật, nhưng không sử dụng nó trong nhiều hoạt động SUM, như trong kế toán. Thay vào đó, nếu bạn sử dụng nhiều phép chia và phép nhân thì bạn không nên sử dụng TIỀN ...

Tất cả các bài viết trước mang lại điểm hợp lệ, nhưng một số không trả lời chính xác câu hỏi.

Câu hỏi là: Tại sao ai đó thích tiền hơn khi chúng ta đã biết đây là loại dữ liệu ít chính xác hơn và có thể gây ra lỗi nếu được sử dụng trong các phép tính phức tạp?

Bạn sử dụng tiền khi bạn không thực hiện các phép tính phức tạp và có thể đánh đổi độ chính xác này cho các nhu cầu khác.

Ví dụ: khi bạn không phải thực hiện các tính toán đó và cần nhập dữ liệu từ các chuỗi văn bản tiền tệ hợp lệ. Chuyển đổi tự động này chỉ hoạt động với loại dữ liệu TIỀN:

SELECT CONVERT(MONEY, '$1,000.68')

Tôi biết bạn có thể tạo thói quen nhập khẩu của riêng bạn. Nhưng đôi khi bạn không muốn tạo lại thói quen nhập với các định dạng ngôn ngữ cụ thể trên toàn thế giới.

Một ví dụ khác, khi bạn không phải thực hiện các phép tính đó (bạn chỉ cần lưu trữ một giá trị) và cần lưu 1 byte (tiền mất 8 byte và thập phân (19,4) mất 9 byte). Trong một số ứng dụng (CPU nhanh, RAM lớn, IO chậm), như chỉ cần đọc lượng dữ liệu khổng lồ, điều này cũng có thể nhanh hơn.

Bạn không nên sử dụng tiền khi bạn cần nhân / chia trên giá trị. Tiền được lưu trữ giống như cách một số nguyên được lưu trữ, trong khi số thập phân được lưu trữ dưới dạng dấu thập phân và chữ số thập phân. Điều này có nghĩa là tiền sẽ giảm độ chính xác trong hầu hết các trường hợp, trong khi thập phân sẽ chỉ làm như vậy khi được chuyển đổi trở lại quy mô ban đầu. Tiền là điểm cố định, vì vậy quy mô của nó không thay đổi trong quá trình tính toán. Tuy nhiên, vì đó là điểm cố định khi nó được in dưới dạng chuỗi thập phân (trái ngược với vị trí cố định trong chuỗi cơ sở 2), các giá trị lên tới thang 4 được thể hiện chính xác. Vì vậy, để cộng và trừ, tiền là tốt.

Một số thập phân được biểu thị trong cơ sở 10 bên trong và do đó, vị trí của dấu thập phân cũng dựa trên số 10 cơ sở. Điều này làm cho phần phân số của nó thể hiện chính xác giá trị của nó, giống như với tiền. Sự khác biệt là các giá trị trung gian của số thập phân có thể duy trì độ chính xác lên tới 38 chữ số.

Với số dấu phẩy động, giá trị được lưu trữ dưới dạng nhị phân như thể nó là một số nguyên và vị trí của điểm thập phân (hoặc nhị phân, ahem) có liên quan đến các bit đại diện cho số. Vì là dấu thập phân nhị phân, 10 số cơ sở mất độ chính xác ngay sau dấu thập phân. 1/5 hoặc 0,2, không thể được trình bày chính xác theo cách này. Cả tiền và thập phân đều không bị giới hạn này.

Thật dễ dàng để chuyển đổi tiền thành số thập phân, thực hiện các tính toán và sau đó lưu trữ giá trị kết quả trở lại vào một trường hoặc biến tiền.

Từ POV của tôi, tôi muốn những thứ xảy ra với những con số chỉ xảy ra mà không cần phải suy nghĩ quá nhiều về chúng. Nếu tất cả các tính toán sẽ được chuyển đổi thành số thập phân, thì với tôi tôi chỉ muốn sử dụng số thập phân. Tôi sẽ tiết kiệm trường tiền cho mục đích hiển thị.

Kích thước khôn ngoan Tôi không thấy đủ sự khác biệt để thay đổi suy nghĩ của mình. Tiền mất 4 - 8 byte, trong khi số thập phân có thể là 5, 9, 13 và 17. 9 byte có thể bao gồm toàn bộ phạm vi mà 8 byte tiền có thể. Index-khôn ngoan (so sánh và tìm kiếm nên được so sánh).

Tôi tìm thấy một lý do về việc sử dụng số thập phân hơn tiền trong chủ đề chính xác.

DECLARE @dOne   DECIMAL(19,4),
        @dThree DECIMAL(19,4),
        @mOne   MONEY,
        @mThree MONEY,
        @fOne   FLOAT,
        @fThree FLOAT

 SELECT @dOne   = 1,
        @dThree = 3,    
        @mOne   = 1,
        @mThree = 3,    
        @fOne   = 1,
        @fThree = 3

 SELECT (@dOne/@dThree)*@dThree AS DecimalResult,
        (@mOne/@mThree)*@mThree AS MoneyResult,
        (@fOne/@fThree)*@fThree AS FloatResult

DecimalResult> 1.000000

MoneyResult> 0,9999

FloatResult> 1

Chỉ cần kiểm tra nó và đưa ra quyết định của bạn.

Tôi vừa thấy mục blog này: Tiền so với số thập phân trong SQL Server .

Về cơ bản nói rằng tiền có vấn đề chính xác ...

declare @m money
declare @d decimal(9,2)

set @m = 19.34
set @d = 19.34

select (@m/1000)*1000
select (@d/1000)*1000

Đối với moneyloại, bạn sẽ nhận được 19,30 thay vì 19,34. Tôi không chắc chắn nếu có một kịch bản ứng dụng chia tiền thành 1000 phần để tính toán, nhưng ví dụ này không phơi bày một số hạn chế.