我是否应该使用Sharepoint数字列类型来存储货币值？

在SharePoint中，我可以创建“Number”类型的列表列。我需要存储货币金额，并且希望能够使用此列类型，而不必创建新的列类型

SharePoint是否存储和操作此类型的值（例如，在列表视图中求和值时）以防止精度损失（即，不是某种近似浮点类型）

---

我已经查看了货币列，但它们似乎强制显示货币单位，这在我的应用程序中没有意义（我怀疑它们在引擎盖下存储为“数字”。

数字就是这样使用的，是的。求和值时，您不应该有任何精度损失的问题。

尽管不是决定性的，但根据以下测试，SharePoint似乎以适合于货币计算的方式处理数字（至少在WSS 3.0/SQL Server 2005中），即使这些数字存储在近似值中。但是，具有超过15个有效数字的值可能会显示舍入误差：

货币存储和检索测试

三个数字列（

First

、

Second

和

Third

）分别包含3.7、3.65和0.05（.Net example from）和一个计算列（返回单行文本），公式如下：

=IF（First=Second+Third，“Success”、“Failure”）

。查看列表时，计算列显示Success

金钱计算测试

是/否计算列，公式为

=0.1+0.1+0.1=0.3

（.Net示例来自）。查看列表时，计算列显示Yes

货币存储和计算测试I

在名为

TestList

的列表中，自定义编号列（

CustomNumber

）包含304253.3251（来自的SQL Server示例）。这存储在

float

类型的数据库表

AllUserData

，列

float1

（SQL Server 2005）中

float

是一种近似的数据类型

运行以下查询：

DECLARE @ListName UNIQUEIDENTIFIER
SET @ListName = (SELECT tp_Id FROM AllLists WHERE tp_Title = 'TestList')

SELECT CAST(float1 as NUMERIC(18, 11)) AS CustomNumber 
FROM AllUserData 
WHERE tp_ListId = @ListName

SELECT float1 AS CustomNumber
FROM AllUserData 
WHERE tp_ListId = @ListName

给出了以下结果：

CustomNumber
304253.32510000002

CustomNumber
304253.3251

使用公式

=CustomNumber*10000000000

创建一个计算列，该公式可能会显示不正确的

3042533251000002

值，实际上显示正确的

3042533251000000.00000

（从用户角度看）。我假设这种行为是由于代码从数据库读取

float

值，并使用适当小的小数位数转换为

numeric

，然后使用.Net decimal类型操作内存中的值

但是，在这种情况下，SQL Server 2000上可能会出现计算错误，因为在不同版本之间，

float

值的行为发生了更改

货币存储和检索测试II

根据上一次测试的结果，将以下值添加到

CustomNumber

列：9999999999999

此16位有效数字值在列表（和编辑）视图中错误显示为100000000000000（使用15位数字的值正确显示）

检查

AllUserData

表表明，该值在数据库中存储不正确，并运行以下查询：

DECLARE @f FLOAT
SET @f = 9999999999999999
SELECT CAST(@f as NUMERIC(20, 0))

给出了结果：

10000000000000000

---

这表明SQL Server在插入时正在舍入该数字。

为什么不使用货币字段？我不想显示货币单位。我可以用一个货币字段来做这件事吗？你有确认这一点的参考（MSDN？）吗？孩子，你要让我为这个接受工作，不是吗！不，我找不到任何说明这一点的文件。我相信货币和数字都以双倍形式存储在SQLServer中。对于货币使用的值范围，如果有double支持，则不会遇到任何精度问题。但是，使用double表示货币通常是个坏主意（例如，请参见）。。。