MSSql跟PostgreSQL的查询结果的小数点差异（求助）

Question

有问题把，应该是0.2吧，我试了一下：
create table table1 (col1 numeric(14,2))insert into table1
values(20)select (col1/ 100) from table1
/*
0.200000
*/

Answer 1

最好使用标准SQL，并保证数据类型的一致

Answer 2

我试了一下，跟numberic 同样问题，希望老大再帮想想办法，谢谢！

Answer 3

你是想在mssqlserver变成20还是20.00？

Answer 4

也变成 20但是也有有小数点的时候，那时候也要跟postgre一样，
如上面 0.2

Answer 5

PostgreSQL使用了numeric，但是为什么会是0呢？

Answer 6

不知道啊 默认把无意义的0都去掉了吧其实要真是把无意义的0去掉，到也没什么关系。我建议你先试试，看把PostgreSQL的数据，导出后，再导入sql server后，会不会有什么异常，你得自己测试一下。

Answer 7

无意义是你觉得的，DBMS不知道啊

Answer 8

不知道啊 默认把无意义的0都去掉了吧其实要真是把无意义的0去掉，到也没什么关系。我建议你先试试，看把PostgreSQL的数据，导出后，再导入sql server后，会不会有什么异常，你得自己测试一下。数据导入没问题，几千万的数据导入都没问题。

Answer 9

just do it但我现在得到的结果确实是这样，有点迷茫，我想写个私有函数 尝试一下

Answer 10

不知道啊 默认把无意义的0都去掉了吧其实要真是把无意义的0去掉，到也没什么关系。我建议你先试试，看把PostgreSQL的数据，导出后，再导入sql server后，会不会有什么异常，你得自己测试一下。数据导入没问题，几千万的数据导入都没问题。那就没问题了，因为不同的数据库，肯定有很多不同的地方，比如上面的numeric数据类型，内部表示还是一样的，只是显示的时候不同。

Answer 11

不知道啊 默认把无意义的0都去掉了吧其实要真是把无意义的0去掉，到也没什么关系。我建议你先试试，看把PostgreSQL的数据，导出后，再导入sql server后，会不会有什么异常，你得自己测试一下。数据导入没问题，几千万的数据导入都没问题。那就没问题了，因为不同的数据库，肯定有很多不同的地方，比如上面的numeric数据类型，内部表示还是一样的，只是显示的时候不同。问题是显示的不一样  抽出的结果也跟着不一样了  
SELECT COALESCE((SELECT 5.12345 WHERE 1=2),0) AS COL1
这个SQL文
postgre:

Answer 12

问题是显示的不一样  抽出的结果也跟着不一样了  
SELECT COALESCE((SELECT 5.12345 WHERE 1=2),0) AS COL1
这个SQL文
postgre:0
sqlserver:.00000sqlserver自动匹配了该字段所有可能的类型，0也给设定成 可能的小数位数。00000

Answer 13

不知道啊 默认把无意义的0都去掉了吧其实要真是把无意义的0去掉，到也没什么关系。我建议你先试试，看把PostgreSQL的数据，导出后，再导入sql server后，会不会有什么异常，你得自己测试一下。数据导入没问题，几千万的数据导入都没问题。那就没问题了，因为不同的数据库，肯定有很多不同的地方，比如上面的numeric数据类型，内部表示还是一样的，只是显示的时候不同。问题是显示的不一样  抽出的结果也跟着不一样了  
SELECT COALESCE((SELECT 5.12345 WHERE 1=2),0) AS COL1
这个SQL文
postgre:这个语句的结果是 null把

Answer 14

这个倒是没关系，只要目标的数据类型是numeric，应该也不会有什么问题的，只是表示方式不同，一个是0，一个是0.0000

Answer 15

这个倒是没关系，只要目标的数据类型是numeric，应该也不会有什么问题的，只是表示方式不同，一个是0，一个是0.0000对于值来讲没有什么问题，怕的是 将这种数据写入到CSV或是TXT的时候怕出问题啊！
一些批处理，会按位截取数据，就怕这种情况，因为要确定的地方很多，所以怕出问题。

Answer 16

这个倒是没关系，只要目标的数据类型是numeric，应该也不会有什么问题的，只是表示方式不同，一个是0，一个是0.0000对于值来讲没有什么问题，怕的是 将这种数据写入到CSV或是TXT的时候怕出问题啊！
一些批处理，会按位截取数据，就怕这种情况，因为要确定的地方很多，所以怕出问题。但是就算截断数据，这个应该也不会有什么问题的吧。你的整个处理流程是怎么样的？是先把postgre中的数据导出成txt，然后再导入到sql server吗？

Answer 17

这个倒是没关系，只要目标的数据类型是numeric，应该也不会有什么问题的，只是表示方式不同，一个是0，一个是0.0000对于值来讲没有什么问题，怕的是 将这种数据写入到CSV或是TXT的时候怕出问题啊！
一些批处理，会按位截取数据，就怕这种情况，因为要确定的地方很多，所以怕出问题。但是就算截断数据，这个应该也不会有什么问题的吧。你的整个处理流程是怎么样的？是先把postgre中的数据导出成txt，然后再导入到sql server吗？不是这样的，数据从 postgre 导入到 sql server 只是转换的过程。以后就是sql server处理自己的数据了，就是这两个数据库用的程序是同一个，现在是在做一个SQLSERVER版本的。现在程序中用到SQL文的地方实在太多了，从根源改工作量应该是最少的。从sql server里取出数据按照一定的处理，写入TXT文件，这个TXT文件发送给别的系统用，因为有的是按照位数截断的，好比我给了这个字段15位（numeric(14,2)）,现在SQLSERVER查询的结果带了好多个0，（123456789012.1234000000）在不改动现有程序的情况下，可能会出问题的。

Answer 18

这个倒是没关系，只要目标的数据类型是numeric，应该也不会有什么问题的，只是表示方式不同，一个是0，一个是0.0000对于值来讲没有什么问题，怕的是 将这种数据写入到CSV或是TXT的时候怕出问题啊！
一些批处理，会按位截取数据，就怕这种情况，因为要确定的地方很多，所以怕出问题。但是就算截断数据，这个应该也不会有什么问题的吧。你的整个处理流程是怎么样的？是先把postgre中的数据导出成txt，然后再导入到sql server吗？不是这样的，数据从 postgre 导入到 sql server 只是转换的过程。以后就是sql server处理自己的数据了，就是这两个数据库用的程序是同一个，现在是在做一个SQLSERVER版本的。现在程序中用到SQL文的地方实在太多了，从根源改工作量应该是最少的。从sql server里取出数据按照一定的处理，写入TXT文件，这个TXT文件发送给别的系统用，因为有的是按照位数截断的，好比我给了这个字段15位（numeric(14,2)）,现在SQLSERVER查询的结果带了好多个0，（123456789012.1234000000）在不改动现有程序的情况下，可能会出问题的。哦，你的意思是，把数据导入sql server，其他系统在处理数据时，可能会截断数据是吧

Answer 19

这个倒是没关系，只要目标的数据类型是numeric，应该也不会有什么问题的，只是表示方式不同，一个是0，一个是0.0000对于值来讲没有什么问题，怕的是 将这种数据写入到CSV或是TXT的时候怕出问题啊！
一些批处理，会按位截取数据，就怕这种情况，因为要确定的地方很多，所以怕出问题。但是就算截断数据，这个应该也不会有什么问题的吧。你的整个处理流程是怎么样的？是先把postgre中的数据导出成txt，然后再导入到sql server吗？不是这样的，数据从 postgre 导入到 sql server 只是转换的过程。以后就是sql server处理自己的数据了，就是这两个数据库用的程序是同一个，现在是在做一个SQLSERVER版本的。现在程序中用到SQL文的地方实在太多了，从根源改工作量应该是最少的。从sql server里取出数据按照一定的处理，写入TXT文件，这个TXT文件发送给别的系统用，因为有的是按照位数截断的，好比我给了这个字段15位（numeric(14,2)）,现在SQLSERVER查询的结果带了好多个0，（123456789012.1234000000）在不改动现有程序的情况下，可能会出问题的。哦，你的意思是，把数据导入sql server，其他系统在处理数据时，可能会截断数据是吧是的
就是这个系统出个数据文件，传给其他系统处理，可能会出现这种情况。最好的办法就是让这两个数据库的SQL文查询的结果一样，因为我们的SQL文都是写在外部的文件中，用DBFulte编译成DLL来使用，所以我们修改外部的SQL文文件是最省事的，我已经做了一个工具，就是根据SQL文到各自的数据库去查数据，然后比较结果，我现在查出来有43个这种小数点位数不一样造成的不一致。这43个SQL文如果去调查都什么地方使用了，是否两个数据库程序跑的结果一样，影响的地方确实太多了……

Answer 20

暂时找到一个解决的办法，还在尝试是否可行。CAST(COL1 AS FLOAT) 这样得到的结果就跟Postgre的结果一样了，我正在验证跟DBFlute有没有类型冲突，如果没问题，这个问题就算解决了，谢谢各位了，我先去验证，一会回来说结果！

Answer 21

谢谢各位了，这两个数据库还真不一样。
通过 CAST(COL1 AS FLOAT) ，查询器里虽然查看是一样，但是在后台程序取到的确实不一样。postgre:
select col1 from table1
union ALL
select 0  as col1
查询器结果：
20
0
真实结果：
20.00
0sqlserver:
select col1 from table1
union ALL
select cast(0 as FLOAT)  as col1
查询器结果：
20
0
真实结果：
20
0可以发现postgre同一个字段可以得到不同精确度的值，而SQLSERVER不能，它只能获得优先级最高的类型和精确度。

Answer 22

你说的对，sql server只会按照优先级最后的类型和精度，来转化 合并的。很多数据库都不同，包括：oracle和sql server也不同。

Answer 23

你说的对，sql server只会按照优先级最后的类型和精度，来转化 合并的。很多数据库都不同，包括：oracle和sql server也不同。是啊  呵呵 把这些搞清楚了，也不算浪费时间了！谢谢了！现在我又回到调查所有用到的地方，排除问题。