求求，别在sql里格式化数据了

在shigen之前的文章《为什么我们总是被追赶着走》这篇文章中提到了很多的设计乱象，设计的恶心之处至今让我呕吐。其中的sql我说了动辄上百行，而一些略长的部分竟然就是为了一件事——格式化。我直接一个ca，格式化不能用一个VO去处理吗？后来人改代码，也只能在sql上堆了。

先来看看当时需要的场景，从数据库中存储的number类型读取格式化：

注：数据库：oracle，数据类型：num-> bigDecimal

1. 格式化成人民币显示

SELECT '¥' || TO_CHAR(12345.67, 'FM9,999,999.99') AS formatted_amount FROM DUAL;
1

2. 格式化千分位

SELECT TO_CHAR(12345.67, 'FM9,999,999.99') AS formatted_amount FROM DUAL;
1

以上就是shigen当时遇到的常见的，换谁在数据库的sql里看到这些都是恶心到家。好好地数据查询和格式化，整成这样！你至少得整一个VO吧，在vo里用工具类格式化不好吗？

---

希望自此不要再看到这么恶心的代码，也希望不会再写出这样的代码！今天，shigen写了一个工具类，直接拿来就用。代码地址在这里。

先来看看代码怎么写的：

这个工具类就是巧妙的借助于java.text.NumberFormat;里自带的类库进行格式化，在我们的vo进行格式化转换的时候，直接调用方法使用即可。

运行的效果是这样的：

别告诉我说：我传入的数字是9位，变成人民币就两位，元角分整明白再说吧！存储那么的位数，有实际的意义吗？

其实其他的场景也是很类似的，比如时间戳的格式化、日期的格式化、字典的格式化……不要在sql里做了。

shigen在这里也结合chatGPT的分析总结一下：

在 SQL 中进行格式化操作，主要是因为 SQL 是用于数据查询和处理的语言，数据库系统提供了一系列的内置函数和操作符，方便对数据进行处理和转换。

然而，对于一些更加复杂或灵活的格式化操作，SQL 的能力可能受到限制。例如，在 SQL 中对日期进行特定的格式化或对字典进行格式化，可能需要编写复杂的 SQL 语句或嵌套的函数调用。这增加了 SQL 查询的复杂性，导致代码难以理解和维护。

编程语言提供了丰富的库和函数，可以轻松地进行日期时间格式化、字符串格式化等操作。此外，编程语言通常还具有更好的控制流和逻辑处理能力，代码复用能力，使得格式化操作可以更加简洁和可读。

因此，将格式化操作从 SQL 中移至编程语言中，可以使代码更加易读、易维护，并且具备更高的灵活性。

---

好了，以上就是《求求，别在sql里格式化数据》的全部内容了，觉得不错的话，记得支持一下哈。

与shigen一起，每天不一样！