Typ double w sql server

0

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)?

0

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.

0

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.

0

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

0

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.

0

Ź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)

0

dzięki

0

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

0

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

0

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ć?

0

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

0

dobra druga liczba to cyfry po przecinku

0

Zmienić typ na decimal(8,6)

0
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ść.

0

decimal(8,6) ?

1
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ń.

0
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.

0
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).

0
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ć".

0

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.

0

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

0
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.

0
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.

0
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

1 użytkowników online, w tym zalogowanych: 0, gości: 1