2010-03-22 5 views
3

je dois convertir un nombre qui donne décimaux au format factoré pour décimaux,convertir nombre en décimal dans factoré SQL Server

à savoir 11,16 est de 11,5 en décimal. C'est parce que 16 est en base de 32 et 11.16 devrait être lu comme 11 + 16/32 = 11.5

Je reçois 11.16 sous forme de chaîne et j'ai besoin de le changer en 11.5 comme numérique dans une base de données SQL Server 2005.

Un moyen plus court de faire cela plutôt que de séparer les chaînes, convertir en numérique, maths, convertir en chaîne, concaténer, puis convertir en numérique?

Répondre

1

En fonction qui ne nécessite pas de fractionnement chaîne:

CREATE FUNCTION MyFunc 
(
@value varchar(10) 
) 
RETURNS float 
AS 
BEGIN 
    declare @dValue float 
    declare @fraction float 

    Select @dvalue = convert(float, @value) 
    Select @fraction = @dvalue - Convert(int, @dvalue) 
    Select @dvalue = (@dvalue - @fraction) + ((@fraction * 100)/32) 

RETURN @dvalue 
END 

REMARQUE: Cela suppose que « 8/32 » est représenté 0,08, et non 0,8

Vous devez ajuster la "varchar (10)" pour correspondre à ce dont vous avez réellement besoin.

+0

Merci, c'est moins encombrant que la méthode que je pensais – LSB

1

Typiquement le genre de données décrites dans la question provient des données financières de diverses données nature et ces actions souvent deux caractéristiques:

  • plusieurs millions de lignes et
  • relativement peu de valeurs distinctes.

Une stratégie possible pour en vrac convertir certaines de ces données, peut être d'établir une liste de valeurs distinctes trouvées dans les données, pour convertir ces valeurs, le stockage et la valeur dans un résultat [relativement faible] look- en haut de la table. Une telle table peut alors être indexé et utilisé dans une requête de mise à jour similaire à la

suivante
UPDATE myOriginialTable 
SET DecValue = F2D.DecVal 
FROM myOriginalTable T 
JOIN FactoredToDecimalTable F2D on T.FValue = F2D.FValue 

Que ce soit l'affaire ci-dessus avec une table de consultation est utilisé, la conversion de factoré à décimal peut également se faire en regardant la fraction de la valeur d'entrée dans un tableau tel que le

CREATE TABLE Factored32ToDec 
(F32 DECIMAL decimal(12,2), 
    Dec10 DECIMAL (12,2) 
) 

INSERT INTO Factored32ToDec VALUES (0, 0) 
INSERT INTO Factored32ToDec VALUES (0.01, 1.0/32) 
INSERT INTO Factored32ToDec VALUES (0.02, 2.0/32) 
INSERT INTO Factored32ToDec VALUES (0.03, 3.0/32) 
INSERT INTO Factored32ToDec VALUES (0.04, 4.0/32) 
-- etc. (24 rows omitted) 
INSERT INTO Factored32ToDec VALUES (0.30, 30.0/32) 
INSERT INTO Factored32ToDec VALUES (0.31, 31.0/32) 

UPDATE myOriginialTable 
SET DecValue = FLOOR(FValue) + F2D.Dec10 
FROM myOriginalTable T 
JOIN Factored32ToDec F2D ON F2D.F32 = (FValue - FLOOR(FValue)) 

suivant essentiellement cette idée suppose que la recherche dans la table Factored32ToDec [évidemment en cache] sera plus rapide que l'opération de division correspondante. Je ne suis pas sûr que ce soit le cas ... cela devrait être profilé/testé. D'autre part, j'ai vu la première approche de recherche (pour toutes les valeurs distinctes), en cours d'utilisation. Cela peut être une manière assez efficace de résoudre le problème, mais le kilométrage que vous en obtenez varie en fonction du nombre total de lignes et du nombre de valeurs distinctes (ainsi que de la présence/absence de divers index et d'autres considérations) comme la mise à jour d'une seule colonne par rapport à deux colonnes séparées, etc.).

Remarque: l'utilisateur de FLOOR() implique que la valeur disponible est numérique; dans certains cas, les données d'entrée sont simplement une chaîne (qui est "utile" ... ne me demandez pas pourquoi ... pour stocker les valeurs sans zéro, c'est-à-dire "X.1" est X + 1/32 alors "X.10" est X + 10/32). En fonction de la situation, il peut donc être nécessaire de séparer la chaîne au point décimal plutôt que d'utiliser FLOOR. BTW, quand codé en tant que chaînes (".1" contre .01), l'approche de petite table de recherche économise beaucoup de tests par rapport à une approche arithmétique.

+0

Simple et élégant.Faites le vrai travail une fois, puis mettez à jour. Dans mon expérience passée, cette approche peut être plus rapide d'un ordre de grandeur pour les grands ensembles de données que pour un calcul ligne par ligne. – DaveE

+0

Merci, Quand et si j'ai un peu de temps va essayer de faire les deux sens et voir l'efficacité et poster ici. Oui, j'ai affaire à un très grand nombre de lignes. – LSB

Questions connexes