Typ double w sql server

Jeśli chcę w sql serverze mieć takie dane jak np.: 14,14 lub 17,231. Czyli dwie liczby przed przecinkiem i dwie albo trzy liczby po przecinku to po prostu uzyc typu decimal(2,3)?

Tak, decimal będzie tu najbezpieczniejszym wyjściem. Teoretycznie można też użyć float lub real, ale maja one pewne ograniczenia związane z tym, że nie przechowują one dokładnej wartości tylko przybliżenie. Gołym okiem różnica jest niezauważalna, ale może być to problematyczne kiedy będziesz chciał użyć tej kolumny w warunku where lub przy jakimś zaokrąglaniu albo porównywaniu.

decimal(2,3) jednak nie działa, napisane jest ze maksymalnie moge dac 2 po przecinku. Ale juz jak dam wieksza liczbe przed przecinkiem to po przecinku tez moze byc wieksza.

Właśnie potrzebuje dokładnych wartości. Jakiś pomysł jak to rozwiązać?

Bo pierwsza liczba to ilość wszystkich cyfr przechowywanych w typie, a druga to ilość cyfr po przecinku, więc powinieneś użyć decimal(5,3).

Właśnie potrzebuje dokładnych wartości. Jakiś pomysł jak to rozwiązać?

Tak jak pisałem wyżej - użyj decimal, on przechowuje dokładne wartości.

Źle używasz typu decimal. Pierwsza liczba oznacza precyzję - czyli liczbę ogółem przechowywanych cyfr dziesiętnych, a druga liczba oznacza skalę - czyli ile liczb po przecinku. W związku z tym, jeżeli chcesz przechowywać 2 liczby przed przecinkiem i 2 po przecinku to musisz zadeklarować: decimal(4,2), jeżeli chcesz 2 przed przecinkiem, a 3 po przecinku to deklarujesz: decimal(5,3)

dzięki

Widzę, że powrócił najtrudniejszy problem matematyki w IT: czym się różni cyfra od liczby i liczba od ilości.

Najważniejsze, że się dogadaliśmy :D

Jednak jeśli dam typ decimal(8,2) i dodam do tej kolumny taka liczbę: 52,990980. To potem ona zostaje zaokrąglona do 52.99, a ja chce mieć dokładnie to liczbę jako podawałem. Jak to zrobić?

Dział matematyki numerycznej się kłania,
Dziękuje za uwagę.

dobra druga liczba to cyfry po przecinku

Zmienić typ na decimal(8,6)

Ogrodnik32 napisał(a):

Jednak jeśli dam typ decimal(8,2) i dodam do tej kolumny taka liczbę: 52,990980. To potem ona zostaje zaokrąglona do 52.99, a ja chce mieć dokładnie to liczbę jako podawałem. Jak to zrobić?

Użyj typu bigint + baza - jeśli możesz.
Jeśli nie to zostaje varchar.

Wszystkie zmienno- i stało-przecinkowe będą Ci przekłamywać wartość.

decimal(8,6) ?

vpiotr napisał(a):

Wszystkie zmienno- i stało-przecinkowe będą Ci przekłamywać wartość.

DECIMAL i NUMERIC nie będzie nic przekłamywać. Nie należy tego typu mylić z FLOAT/REAL. DECIMAL/NUMERIC będzie trzymał dokładnie taką dokładność jaką zadeklarowano. W bazie MSSQL może przechowywać liczby składające się do 38 cyfr, więc jest to wystarczająca precyzja do większości zastosowań.

Haskell napisał(a):

vpiotr napisał(a):

Wszystkie zmienno- i stało-przecinkowe będą Ci przekłamywać wartość.

DECIMAL i NUMERIC nie będzie nic przekłamywać. Nie należy tego typu mylić z FLOAT/REAL. DECIMAL/NUMERIC będzie trzymał dokładnie taką dokładność jaką zadeklarowano. W bazie MSSQL może przechowywać liczby składające się do 38 cyfr, więc jest to wystarczająca precyzja do większości zastosowań.

Oczywiście że będzie. Jak każdy typ o ograniczonej precyzji.

vpiotr napisał(a):

Haskell napisał(a):

vpiotr napisał(a):

Wszystkie zmienno- i stało-przecinkowe będą Ci przekłamywać wartość.

DECIMAL i NUMERIC nie będzie nic przekłamywać. Nie należy tego typu mylić z FLOAT/REAL. DECIMAL/NUMERIC będzie trzymał dokładnie taką dokładność jaką zadeklarowano. W bazie MSSQL może przechowywać liczby składające się do 38 cyfr, więc jest to wystarczająca precyzja do większości zastosowań.

Oczywiście że będzie. Jak każdy typ o ograniczonej precyzji.

Wg tej logiki każdy typ danych ma ograniczoną precyzję. Nawet varchar(max).

Haskell napisał(a):

vpiotr napisał(a):

Haskell napisał(a):

vpiotr napisał(a):

Wszystkie zmienno- i stało-przecinkowe będą Ci przekłamywać wartość.

DECIMAL i NUMERIC nie będzie nic przekłamywać. Nie należy tego typu mylić z FLOAT/REAL. DECIMAL/NUMERIC będzie trzymał dokładnie taką dokładność jaką zadeklarowano. W bazie MSSQL może przechowywać liczby składające się do 38 cyfr, więc jest to wystarczająca precyzja do większości zastosowań.

Oczywiście że będzie. Jak każdy typ o ograniczonej precyzji.

Wg tej logiki każdy typ danych ma ograniczoną precyzję. Nawet varchar(max).

No to nie pisz "nie będzie nic przekłamywać".

Typ DECIMAL nie będzie "przekłamywać" w taki sposób jak typy zmiennoprzecinkowe. Bigint w żaden sposób nie będzie lepszy od decimal. Szczególnie, że w MSSQL bigint jest na 8 bajtach, a decimal na nawet 17.

To co lepiej do przekazywania takich liczb uzyc varchara? I potem ewentualnie już w c# parsować to na floaty lub coś innego

Haskell napisał(a):

Typ DECIMAL nie będzie "przekłamywać" w taki sposób jak typy zmiennoprzecinkowe.

Zgadza się. Będzie zaokrąglać, czyli też tracić informację tylko w sposób inaczej nazwany.

Bigint w żaden sposób nie będzie lepszy od decimal.

Zgadza się, nie spojrzałem że BigInt w MS SQL to tylko 8 bajtów czyli max 9 cyfr, decimal to 38 cyfr.

Kangur napisał(a):

To co lepiej do przekazywania takich liczb uzyc varchara? I potem ewentualnie już w c# parsować to na floaty lub coś innego

W przypadku sql server typ decimal jest najlepszym wyborem do przechowywania danych z określoną precyzją i skalą. Powszechie używa się tego typu do przechowywania np. kwot pieniędzy.

Kangur napisał(a):

To co lepiej do przekazywania takich liczb uzyc varchara? I potem ewentualnie już w c# parsować to na floaty lub coś innego

Nie, nigdy tak nie rób. Stosuj się do tej tabelki: https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql-server-data-type-mappings