SQL Server'da PARA veya DECIMAL (x, y) veri türlerini seçmeli misiniz?

moneyVeri türü ve benzeri bir şey arasında gerçek bir fark olup olmadığını merak ediyorum decimal(19,4)(paranın dahili olarak kullandığı şey , inanıyorum).

moneySQL Server'a özgü olduğunun farkındayım . Birini diğerinden seçmek için zorlayıcı bir neden olup olmadığını bilmek istiyorum; En SQL Server örnekleri (örn AdventureWorks veritabanı) kullanımı moneyve decimalfiyat bilgileri gibi şeyler için.

Para veri tipini kullanmaya devam etmeli miyim yoksa ondalık kullanmanın bir yararı var mı? Para yazmak için daha az karakter var, ancak bu geçerli bir neden değil :)

Asla para kullanmamalısınız. Kesin değildir ve saf çöptür; her zaman ondalık / sayısal kullanın.

Ne demek istediğimi görmek için bunu çalıştırın:

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

Çıktı: 2949.0000 2949.8525

Parayı paraya bölmediğinizi söyleyen bazı insanlara:

İşte korelasyonları hesaplamak için sorgularımdan biri ve bunu paraya çevirmek yanlış sonuçlar veriyor.

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, paranın tam olmadığını söyledi. Ama parayı parayla çarpmaz / bölmezsiniz! 3 dolar 50 sent ne kadar? 150 dolar mı? Parayı ondalık olması gereken skalerlerle çarpıyorsunuz / bölüyorsunuz.

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

Sonuçlar doğru sonuç:

moneyresult sayısal sonuçlar
--------------------- ----------------------------- ----------
2949.8525 2949.8525

money4'ten fazla ondalık basamağa ihtiyacınız olmadığı sürece iyidir ve parayı temsil etmeyen skalerlerinizin decimals olduğundan emin olun .

Ne yaptığını bilmiyorsan her şey tehlikelidir

Yüksek hassasiyetli ondalık türler bile günü kurtaramaz:

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

1.000000 <- 0.6000000 olmalıdır

moneyTürleri tam sayılardır

Metin temsili smallmoneyve decimal(10,4)benzer görünebilir, ancak bu onları değiştirilebilir yapmaz. Tarihlerin depolandığını gördüğünüzde küfür ediyor musunuz varchar(10)? Bu aynı şey.

Sahnelerin arkasında, money/ smallmoneysadece a bigint/ y'nin int metin temsilindeki ondalık noktası moneygörsel tüylerdir, tıpkı yyyy-aa-gd tarihindeki çizgiler gibi. SQL bunları dahili olarak saklamaz.

decimalVs ile ilgili moneyolarak, ihtiyaçlarınıza uygun olanı seçin. moneyBiriminin 1/10000 tam katı olarak muhasebe değerleri depolamak çok yaygın olduğu için tipleri vardır. Ayrıca, basit toplama ve çıkarma ötesinde gerçek para ve hesaplamalar ile uğraşıyorsanız, bunu veritabanı düzeyinde yapmamalısınız! Bankacı Yuvarlamasını destekleyen bir kütüphane ile uygulama düzeyinde yapın (IEEE 754)

WayneM'in paranın SQL Server'a özgü olduğunu bildiğini belirttiğini anlıyorum. Ancak, ondalık üzerinde para kullanmak için herhangi bir neden olup olmadığını soruyor ya da tam tersi ve bence açık bir neden hala belirtilmelidir ve ondalık kullanmak DBMS'nizi değiştirmek zorunda kalırsanız endişelenmeniz gereken daha az şey anlamına gelir. - bu olabilir.

Sistemlerinizi mümkün olduğunca esnek hale getirin!

Sevdim MONEY! Bu değerden daha ucuz bir bayttır DECIMALve hesaplamalar daha hızlı gerçekleşir, çünkü (kapakların altında) toplama ve çıkarma işlemleri esasen tamsayı işlemleridir. @ SQLMenace'in - habersiz için büyük bir uyarı olan INTörneği, sonucun sıfır olacağı egers'e eşit olarak uygulanabilir . Ama bu integers- kullanmak için hiçbir neden var uygun .

Yani, mükemmel bir şekilde 'güvenli' ve MONEYuğraştığınız zaman MONEYkullanmak ve onu takip eden matematiksel kurallara göre kullanmak için uygundur ( INTeger ile aynı ).

SQL Server MONEY'ın bölünmesini ve çoğaltılmasını DECIMALs (veya FLOATs'ye) yükseltmesi daha iyi olurdu , ama bunu yapmayı seçmediler; ne de INTböldüklerinde egleri FLOATs'ye yükseltmeyi seçmediler .

MONEYhassas bir sorunu yoktur; Bu DECIMALhesaplamalar sırasında kullanılan daha büyük bir ara tür olsun sadece bu tür kullanmanın bir 'özellik' (ve aslında bu 'özellik' ne kadar uzandığından emin değilim).

Belirli bir soruyu cevaplamak için “zorlayıcı bir neden” mi? Peki, bir SUM(x)yerde mutlak maksimum performans istiyorsanız xya DECIMALda olabilir MONEY, o MONEYzaman bir kenarı olacaktır.

Ayrıca, daha küçük kuzen olduğunu unutmayın SMALLMONEY- sadece 4 bayt, ancak maksimumda 214,748.3647- para için oldukça küçüktür - ve genellikle iyi bir uyum değildir.

Etraftaki noktayı daha büyük ara türler kullanarak kanıtlamak için, DECIMALaracıyı bir değişkene açıkça atarsanız , aynı sorunla karşılaşırsınız:

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

Üretir 2950.0000(tamam, en azından kesilmiş DECIMALyerine en azından yuvarlak - MONEYtamsayı ile aynıdır.)

Çok benzer bir sorunla karşılaştık ve şimdi üst düzey sunum dışında asla Money kullanmamaya + 1'im. Tarihsel nedenlerden ötürü her biri bir veya daha fazla Para alanı içeren birden fazla tablonuz (etkin bir satış fişi ve satış faturası) var ve her bir Verginin toplam tutarının ne kadarıyla alakalı olduğunu hesaplamak için orantılı bir hesaplama yapmamız gerekiyor fişi üzerine yazılır. Bizim hesaplama

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

Bu, bölünme kısmında ölçek hatalarına neden olan ve daha sonra yanlış bir KDV oranına çarparak gerçek bir dünya para / para hesaplaması ile sonuçlanır. Bu değerler daha sonra eklendiğinde, toplam fatura değerine eklenmeyen KDV oranlarının toplamı ile sonuçlanır. Parantez içindeki değerlerden biri bir ondalık sayı olsaydı (bunlardan birini böyle dökmek üzereyim) KDV oranı doğru olurdu.

Köşeli parantezler başlangıçta bu işe yaramadıysa, daha büyük değerler nedeniyle, daha yüksek bir ölçeği etkili bir şekilde simüle ediyordu. Köşeli parantezleri ekledik, çünkü ilk önce çarpımı gerçekleştiriyordu, bu da bazı nadir durumlarda hesaplama için kullanılabilir hassasiyeti üfledi, ancak şimdi bu çok daha yaygın bir hataya neden oldu.

Karşılık olarak diğer cevapların genel itişine işaret eder. Paranın Birçok Avantajına Bakın … Veri Türü! içinde İlişkisel Veri Yönetim Sistemi'ne SQLCAT Kılavuzu

Özellikle aşağıdakilere dikkat çekerim

Müşteri uygulamaları üzerinde çalışırken, para veri türü ile ilgili bazı ilginç performans sayıları bulduk. Örneğin, Analysis Services, SQL Server para veri türüyle eşleşmesi için para birimi veri türüne (çiftten) ayarlandığında, işlem hızında (satırlar / sn)% 13'lük bir iyileşme oldu. SSIS 2008 - dünya rekoru ETL performansında belirtildiği gibi, SQL Server Entegrasyon Hizmetleri'nde (SSIS) otuz dakikadan kısa bir sürede 1,18 TB yüklemek için daha hızlı performans elde etmek için, dört ondalık (9,2) sütununun TPC-H LINEITEM tablosundaki 5 bayt paraya (8 bayt) toplu ekleme hızını% 20 artırdı ... Performans artışının nedeni SQL Server'ın Tablo Veri Akışı (TDS) protokolü, verileri kompakt ikili biçimde ve SQL Server'ın dahili depolama biçimine mümkün olduğunca yakın aktarmak için anahtar tasarım ilkesine sahiptir. Ampirik olarak bu, Kernrate kullanılarak yapılan SSIS 2008 - dünya rekoru ETL performans testi sırasında gözlemlenmiştir; veri türü ondalıktan paraya çevrildiğinde protokol önemli ölçüde düştü. Bu, veri aktarımını mümkün olduğunca verimli hale getirir. Karmaşık bir veri türünün işlenmesi için sabit genişlikli bir türden daha fazla ayrıştırma ve CPU döngüsü gerekir.

Yani sorunun cevabı "duruma bağlıdır". Hassasiyeti korumak için belirli aritmetik işlemlere daha dikkatli olmanız gerekir, ancak performansla ilgili hususların bunu değerli kıldığını görebilirsiniz.

MONEY'a karşı NUMERICAL'a farklı bir bakış açısı vermek istiyorum, büyük ölçüde kendi uzmanlığımı ve deneyimimi esas aldım ... Burada benim görüşüm MONEY, çünkü onunla uzun bir süre çalıştım ve gerçekten NUMERICAL'i çok kullanmadım .. .

PARA Pro:

• Yerel Veri Türü . CPU kaydı (32 veya 64 bit) ile aynı yerel veri türü ( tamsayı ) kullanır , bu nedenle hesaplama gereksiz ek yüke ihtiyaç duymaz, bu yüzden daha küçük ve daha hızlıdır ... MONEY 8 bayt ve NUMERICAL (19, 4) gerektirir ) 9 bayta (% 12.5 daha büyük) ihtiyaç duyar ...

  PARA (para olarak) olması gerektiği sürece kullanıldığı sürece daha hızlıdır. Ne kadar hızlı? SUM1 milyon verideki basit testim, PARA'nın 275 ms ve NUMERIC 517 ms olduğunu gösteriyor ... Bu neredeyse iki kat daha hızlı ... Neden SUM testi? Bir sonraki Pro noktasına bakın

• Para için en iyisi . PARA, örneğin muhasebe alanında para depolamak ve işlemler yapmak için en iyisidir. TOPLA işlemi yapıldıktan sonra tek bir rapor milyonlarca ekleme (SUM) ve birkaç çarpma gerçekleştirebilir. Çok büyük muhasebe uygulamaları için neredeyse iki kat daha hızlıdır ve son derece önemlidir ...
• Düşük Para Hassasiyeti . Gerçek hayatta paranın çok kesin olması gerekmez. Yani, birçok insan yaklaşık 1 cent USD umurunda olabilir, ama 0.01 cent USD hakkında ne dersiniz? Aslında, ülkemde bankalar artık sentleri umursamıyor (ondalık virgülden sonraki rakam); ABD bankasını veya başka bir ülkeyi bilmiyorum ...

PARA Con:

• Sınırlı Hassasiyet . MONEY'in yalnızca dört basamaklı (virgülden sonra) hassasiyeti vardır, bu nedenle bölme gibi işlemler yapmadan önce dönüştürülmelidir ... Ama sonra tekrar o moneykadar hassas olmak zorunda değildir ve sadece bir değil, para olarak kullanılması gerekir numara...

Ama ... Büyük, ama burada uygulamanız bile gerçek para ile ilgili, ancak muhasebe gibi birçok SUM işleminde kullanmayın. Bunun yerine çok sayıda bölme ve çarpma kullanırsanız, PARA kullanmamalısınız ...

Önceki tüm gönderiler geçerli puanlar getiriyor, ancak bazıları soruyu tam olarak cevaplamıyor.

Soru şudur: Neden daha az kesin bir veri türü olduğunu ve karmaşık hesaplamalarda kullanılırsa hatalara neden olabileceğini bildiğimizde neden para tercih edilmeli?

Karmaşık hesaplamalar yapmayacağınız zaman para kullanırsınız ve bu hassasiyeti diğer ihtiyaçlarınız için takas edebilirsiniz.

Örneğin, bu hesaplamaları yapmak zorunda olmadığınızda ve geçerli para birimi metin dizelerinden veri almanız gerektiğinde. Bu otomatik dönüşüm yalnızca MONEY veri türüyle çalışır:

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

Kendi ithalat rutininizi yapabileceğinizi biliyorum. Ancak bazen dünya çapında belirli yerel ayar biçimleriyle bir içe aktarma rutini yeniden oluşturmak istemezsiniz.

Başka bir örnek, bu hesaplamaları yapmanız gerekmediğinde (sadece bir değer depolamanız gerekir) ve 1 bayt kaydetmeniz gerektiğinde (para 8 bayt alır ve ondalık (19,4) 9 bayt alır). Bazı uygulamalarda (hızlı CPU, büyük RAM, yavaş IO), sadece büyük miktarda veri okumak gibi, bu da daha hızlı olabilir.

Değer üzerinde çarpma / bölme yapmanız gerektiğinde para kullanmamalısınız. Para bir tamsayının depolandığı şekilde saklanırken, ondalık basamak ondalık basamak ve ondalık basamak olarak saklanır. Bu, paranın çoğu durumda doğruluğu düşüreceği anlamına gelirken, ondalık yalnızca orijinal ölçeğine dönüştürüldüğünde bunu yapar. Para sabittir, bu nedenle hesaplamalar sırasında ölçeği değişmez. Bununla birlikte, ondalık bir dize olarak yazdırıldığında (bir temel 2 dizede sabit bir konumun aksine) sabit nokta olduğundan, 4 ölçeğine kadar olan değerler tam olarak temsil edilir. Toplama ve çıkarma için para iyidir.

Ondalık bir taban 10'da dahili olarak temsil edilir ve bu nedenle ondalık noktanın konumu da taban 10 numarasına dayanır. Bu da onun kesirli kısmını parayla olduğu gibi tam olarak değerini temsil eder. Fark, ondalık ara değerlerin 38 basamağa kadar hassasiyeti koruyabilmesidir.

Kayan nokta sayısı ile, değer bir tamsayı gibi ikili olarak saklanır ve ondalık (veya ikili, ahem) noktasının konumu, sayıyı temsil eden bitlere göredir. İkili ondalık noktası olduğundan, temel 10 sayıları ondalık noktadan hemen sonra kesinlik kaybeder. 1/5 veya 0,2 tam olarak bu şekilde temsil edilemez. Ne para ne de ondalık sayı bu sınırlamadan etkilenmez.

Parayı ondalığa dönüştürmek, hesaplamaları yapmak ve daha sonra elde edilen değeri bir para alanına veya değişkene geri depolamak yeterince kolaydır.

POV'umdan, sayılara olan şeylerin çok fazla düşünmek zorunda kalmadan gerçekleşmesini istiyorum. Tüm hesaplamalar ondalık sayıya dönüştürülecekse, o zaman bana sadece ondalık sayı kullanmak istiyorum. Para alanını görüntüleme amacıyla saklardım.

Boyut-bilge Fikrimi değiştirmek için yeterli bir fark görmüyorum. Para 4 - 8 bayt alırken, ondalık sayı 5, 9, 13 ve 17 olabilir. 9 bayt, 8 baytlık paranın yapabileceği tüm aralığı kapsayabilir. Endeks yönünden (karşılaştırma ve arama karşılaştırılabilir olmalıdır).

Doğruluk konusunda ondalık paranın kullanılması konusunda bir neden buldum.

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

Ondalık Sonuç> 1.000000

MoneyResult> 0.9999

FloatResult> 1

Sadece test edin ve kararınızı verin.

Bu blog girişini gördüm: SQL Server'da Money vs. Decimal .

Temel olarak paranın hassas bir sorunu olduğunu söylüyor ...

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

set @m = 19.34
set @d = 19.34

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

İçin moneytipi, sen 19,30 yerine 19,34 alacak. Hesaplama için parayı 1000 parçaya bölen bir uygulama senaryosu olup olmadığından emin değilim, ancak bu örnek bazı sınırlamaları ortaya koyuyor.