Lösung einiger Probleme bei der Konvertierung von Gleitkommatypen in Zeichentypen in MySQL

Typkonvertierung ist eine Anforderung, auf die wir in der täglichen Entwicklung häufig stoßen. Bei der Konvertierung von Gleitkommatypen sind wir auf ein Problem gestoßen, daher werde ich es Ihnen im folgenden Artikel kurz vorstellen Bei Bedarf finden Sie relevante Informationen zu den Problemen, die bei der Konvertierung von Gleitkommazahlen in Zeichen in MySQL auftreten können.

Vorwort

Dieser Artikel führt Sie hauptsächlich in ein Problem ein, das bei der Konvertierung von Gleitkommazahlen in Zeichen in MySQL auftritt. Er dient als Referenz für alle Ich werde nicht viel mehr sagen, werfen wir einen Blick auf die ausführliche Einführung.

Eine Beschreibung des Problems

Heute musste ich Daten aktualisieren, d. h. das Gewicht des Produkts (Feldtyp) ändern ist Float), geändert Nach dem Gewicht des Produkts muss es in der Protokolltabelle aufgezeichnet werden (Feldtyp ist Varchar). Die Tabellenstruktur ist wie folgt:

Aktualisieren Sie das vorübergehend Datentabelle:

CREATE TABLE `temp_170830` (
 `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
 `goods_sn` varchar(255) NOT NULL DEFAULT '' COMMENT '产品编码',
 `goods_weight` float(9,4) NOT NULL DEFAULT '0.0000' COMMENT '产品重量',
 `actual_weight` float(9,4) NOT NULL DEFAULT '0.0000' COMMENT '实际重量',
 `new_actual_weight` float(9,4) NOT NULL DEFAULT '0.0000' COMMENT '新的实际重量',
 `create_user` varchar(30) NOT NULL DEFAULT '' COMMENT '创建人',
 PRIMARY KEY (`id`),
 KEY `idx_goods_sn` (`goods_sn`)
) ENGINE=InnoDB AUTO_INCREMENT=8192 DEFAULT CHARSET=utf8 COMMENT='临时刷重量表';

Protokolltabelle:

CREATE TABLE `log_weight` (
 `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
 `goods_sn` varchar(50) NOT NULL DEFAULT '' COMMENT '产品编码',
 `which_col` varchar(100) NOT NULL DEFAULT '' COMMENT '修改字段',
 `old_value` varchar(50) NOT NULL DEFAULT '0.00' COMMENT '更新前值',
 `new_value` varchar(50) NOT NULL DEFAULT '0.00' COMMENT '更新后值',
 `update_user` varchar(100) NOT NULL DEFAULT '' COMMENT '创建人',
 `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
 `wh_update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '记录修改时间',
 PRIMARY KEY (`id`),
 KEY `idx_goods_sn` (`goods_sn`),
 KEY `idx_update_user` (`update_user`),
 KEY `wh_update_time` (`wh_update_time`)
) ENGINE=InnoDB AUTO_INCREMENT=14601620 DEFAULT CHARSET=utf8 COMMENT='重量修改日志';

Wie in der oben erstellten Tabelle gezeigt, muss ich die Felder „actual_weight“ und „new_actual_weight“ der Tabelle „temp_170830“ in die Felder „old_value“ und „new_value“ der Tabelle „log_weight“ einfügen. Die SQL-Anweisung lautet wie folgt:

INSERT INTO log_weight(goods_sn, which_col, old_value, new_value, update_user)
SELECT goods_sn,'actual_weight',actual_weight,new_actual_weight,create_user FROM temp_170830;

Ich dachte, ich wäre hier fertig, schließlich habe ich nur einige Protokolldatensätze eingefügt. Später stellte ich zur einfachen Überprüfung fest, dass etwas mit den Daten nicht stimmte, wie in der Abbildung unten gezeigt:

Screenshot der temporären Tabellendaten:

Screenshot der Protokolltabellendaten:

Der Vergleich zeigt, dass die eingefügten Protokolldaten am Ende viele zusätzliche Bits haben, ohne dass ich weiß, woher die Dezimalstellen kommen Das liegt daran, dass die ursprünglichen Gleitkommadaten nicht in Varchar konvertiert werden können. Es ist vorerst nicht sehr gut, ich werde es später nach der Bestätigung hinzufügen Habe vorübergehend eine Methode zum Konvertieren von Varchar in Concat gefunden und sie wie folgt angepasst:

INSERT INTO log_weight(goods_sn, which_col, old_value, new_value, update_user)
SELECT goods_sn,'actual_weight',concat(actual_weight,''),concat(new_actual_weight,''),create_user FROM temp_170830;

Das Protokollierungsproblem wurde erfolgreich gelöst.

Die Zusammenfassung lautet wie folgt:

1 Versuchen Sie beim Aufzeichnen numerischer Preis- und Gewichtsfelder keine Gleitkommatypen zu verwenden! ! ! Es gibt viele Fallstricke bei Gleitkommazahlen (z. B. können Gleitkommatypen nicht als gleich beurteilt werden!!!). Wenn im Geschäftsleben Dezimalzahlen angezeigt werden müssen, ist es am besten, sie zu verwenden Die entsprechende Anzahl von Ziffern, z. B. 99,98 Yuan, sollte gespeichert werden, und beim Auslesen wird sie als 9998/100 angezeigt.

2 Wenn Sie Float in Varchar konvertieren, sollten Sie Float zuerst mit der Concat-Funktion in Varchar konvertieren und es dann im Varchar-Feld speichern.

Das obige ist der detaillierte Inhalt vonLösung einiger Probleme bei der Konvertierung von Gleitkommatypen in Zeichentypen in MySQL. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!