在shigen
之前的文章《为什么我们总是被追赶着走》这篇文章中提到了很多的设计乱象,设计的恶心之处至今让我呕吐。其中的sql我说了动辄上百行,而一些略长的部分竟然就是为了一件事——格式化。我直接一个ca,格式化不能用一个VO去处理吗?后来人改代码,也只能在sql上堆了。
先来看看当时需要的场景,从数据库中存储的number类型读取格式化:
注:数据库:oracle,数据类型:num-> bigDecimal
- 格式化成人民币显示
SELECT '¥' || TO_CHAR(12345.67, 'FM9,999,999.99') AS formatted_amount FROM DUAL;
- 格式化千分位
SELECT TO_CHAR(12345.67, 'FM9,999,999.99') AS formatted_amount FROM DUAL;
以上就是shigen
当时遇到的常见的,换谁在数据库的sql里看到这些都是恶心到家。好好地数据查询和格式化,整成这样!你至少得整一个VO吧,在vo里用工具类格式化不好吗?
希望自此不要再看到这么恶心的代码,也希望不会再写出这样的代码!今天,shigen
写了一个工具类,直接拿来就用。代码地址在这里。
先来看看代码怎么写的:
这个工具类就是巧妙的借助于java.text.NumberFormat;
里自带的类库进行格式化,在我们的vo进行格式化转换的时候,直接调用方法使用即可。
运行的效果是这样的:
别告诉我说:我传入的数字是9位,变成人民币就两位,元角分整明白再说吧!存储那么的位数,有实际的意义吗?
其实其他的场景也是很类似的,比如时间戳的格式化、日期的格式化、字典的格式化……不要在sql里做了。
shigen
在这里也结合chatGPT的分析总结一下:
在 SQL 中进行格式化操作,主要是因为 SQL 是用于数据查询和处理的语言,数据库系统提供了一系列的内置函数和操作符,方便对数据进行处理和转换。
然而,对于一些更加复杂或灵活的格式化操作,SQL 的能力可能受到限制。例如,在 SQL 中对日期进行特定的格式化或对字典进行格式化,可能需要编写复杂的 SQL 语句或嵌套的函数调用。这增加了 SQL 查询的复杂性,导致代码难以理解和维护。
编程语言提供了丰富的库和函数,可以轻松地进行日期时间格式化、字符串格式化等操作。此外,编程语言通常还具有更好的控制流和逻辑处理能力,代码复用能力,使得格式化操作可以更加简洁和可读。
因此,将格式化操作从 SQL 中移至编程语言中,可以使代码更加易读、易维护,并且具备更高的灵活性。
好了,以上就是《求求,别在sql里格式化数据》的全部内容了,觉得不错的话,记得支持一下哈。
与shigen
一起,每天不一样!