最近，一位读者给我发信提问，信中，他想了解如何按照我们通常引用货币的格式来显示货币的数量。（我意识到这个问题可能是全球化的，所以我尝试着用全球通用的方式来回答这个读者的问题。）
我们使用Northwind来作为实验案例。试看下面的SQL查询请求：
这个查询请求会生成一个和列表A（仅仅是一个简单列表）类似的结果。这产生的是一个正确的结果，但却还不是你想要的格式。我们可以改变货币列的外观，但是这样会带来排序的开销。举例说明，列表B中的语句产生了我们想要的输出（例如，数量以货币格式来显示）
这位读者还想了解如何把货币值指定为预先定义的数量。例如：$1,320.00。在列表B中给出了修改过的语句后，这并不难办到，就如同下面你看到的：
USE Northwind
GO
SELECT Quantity,'$' + CONVERT(varchar(12), Unitprice, 1) AS Unitprice, '$' +
CONVERT(varchar(12), Quantity * UnitPrice, 1) AS Amount
FROM [Order Details]
列表C展示了我们想要的显示格式是怎么样的。我应当添加一个额外的隐含限制条件。格式1仅仅在数据格式为货币或者是小额货币时起作用。
CONVERT(varchar, CONVERT(money, YourFieldName), 1)
为什么要用货币格式来显示货币数值呢？现在我们已经达到了那位读者所要求的结果，你可能会问自己：为什么你需要用货币格式来显示货币的数值呢？
假设输出的对象是Query Analyzer，那么这样做可以让你的格式看起来更加有吸引力。但是在你的组织中有多少人会真正实用Query Analyzer来进行他们的工作呢？我猜不会超过五个。大多数的用户会选择用Microsoft Access, .NET, Excel或者Delphi编写的应用程序，这些程序的格式化功能远远超过了T-SQL。T-SQL的设计出发点不是为了更详尽和全面的格式化，而是为了高效率的输出底层数据。
尽管如此，你可能有一个让数据以这种格式输出的正当理由；如果这样，程序会存在排序的开销。输出的列不再是货币甚至也不是数值，所以不能在里面使用任何数值相关的函数（例如average, sum, min, max等等）。如果你需要这样的操作，你不得不将存储实际数据的行加入到SELECT语句中，然后再在这一行上执行相应的操作。
为什么给出服务端代码而不是客户端代码？
T-SQL为以上所阐述的格式显示问题提供了解决方案，但这些解决方案对于你所处的环境是不是恰当的呢？这里给出的底线是将前端与后端分离。
在大多数情况下，你对这个问题的解决方案会存在于客户端代码而不是SQL代码。但是，我认识到在许多情况下，在服务端代码中处理是最佳选择。举例说明， Access, VB, 以及 .NET都提供了Format()函数，它能够很好的处理这个问题。但这并非总能够有效，例如，你可能需要将一个文本文件输入到一些程序，这些程序期望货币数值以这种精确的方式来显示。
所以，如果你需要的正是服务端代码，那现在你已经有解决方案了。但在你实现它之前，请意识到上面所描述的开销。
