On the uncertainty of float under sqlserver

Most of the time, as we all know, floating-point storage itself is an uncertain value, and you can never know whether it is 0 = 0.0000000000123 or 0 = 0.00000000000999. Maybe there is no problem when using it at first, but sometimes when you do statistics, you can see the clue.

To give a simple example, we know that unexpected effects may occur during statistics, resulting in the need for additional digital trade-offs in the code of the stored procedure or the receiving program, so here I actually recommend using Numeric instead of float for an alternative use to avoid a sum, and then look at each piece of data in detail, which is a normal 2jue, 3 decimal places, and a summary becomes 8pc9 digits

CREATE TABLE # T (ID INT IDENTITY,Va FLOAT) CREATE TABLE # T1 (ID INT IDENTITY Va NUMERIC (155.9)-INSERT INTO # T (Va) VALUES (0.60000000) INSERT INTO # T1 (Va) VALUES (0.60000000) GO 100SELECT SUM (Va) FROM # TSELECT SUM (Va) FROM # T1-- -60.0000000000001 (1 row affected)-60.000000000 (1 row affected)

Summary

The above is the whole content of this article about the uncertainty of float under sqlserver. I hope it will be helpful to you. Interested friends can refer to this site: a brief description of the difference between Redis and MySQL, ORACLE SQL sentence optimization technical points analysis, MySQL subquery and nested query optimization example analysis, etc., if you have any questions, you can leave a message at any time, the editor will reply to you in time. Thank you for your support!