Pavel hat ganz recht, ich möchte es nur kurz erklären.
Angenommen, Sie meinen eine Leistungsbeeinträchtigung im Vergleich zu Gleitkomma- oder Festkomma-Offset-Ganzzahlen (d. H. Speichern von Tausendstel Cent als Ganzzahl):Ja, es gibt sehr starke Leistungsbeeinträchtigungen. PostgreSQL und nach den Klängen von MySQL speichern Sie DECIMAL / NUMERIC in binär codierter Dezimalzahl. Dieses Format ist kompakter als das Speichern der Ziffern als Text, aber es ist immer noch nicht sehr effizient damit zu arbeiten.
Wenn Sie nicht viele Berechnungen in der Datenbank durchführen, beschränkt sich die Auswirkung auf den größeren Speicherplatzbedarf für BCD im Vergleich zu Integer- oder Gleitkommazahlen und damit auf die breiteren Zeilen und langsameren Scans, größeren Indizes usw. Vergleichsoperationen in b -tree-Indexsuchen sind auch langsamer, aber nicht genug, um eine Rolle zu spielen, es sei denn, Sie sind bereits aus einem anderen Grund CPU-gebunden.
Wenn Sie viele Berechnungen mit dem DECIMAL durchführen / NUMERIC Werte in der Datenbank, dann kann die Performance wirklich darunter leiden. Dies fällt zumindest in PostgreSQL besonders auf, da Pg nicht mehr als eine CPU für eine bestimmte Abfrage verwenden kann. Wenn Sie eine Menge Divisionen und Multiplikationen, komplexere Mathematik, Aggregation usw. mit Zahlen durchführen, können Sie in Situationen, in denen Sie niemals einen Float- oder Integer-Datentyp verwenden würden, CPU-gebunden finden. Dies macht sich besonders bei OLAP-ähnlichen (Analyse-)Workloads und bei der Berichterstellung oder Datentransformation während des Ladens oder Extrahierens (ETL) bemerkbar.
Trotz der Tatsache, dass es gibt eine Auswirkung auf die Leistung (die je nach Arbeitslast von vernachlässigbar bis ziemlich groß variiert), sollten Sie im Allgemeinen numeric verwenden / decimal wenn es der am besten geeignete Typ für Ihre Aufgabe ist - d. h. wenn sehr hohe Bereichswerte gespeichert werden müssen und/oder Rundungsfehler nicht akzeptabel sind.
Gelegentlich lohnt es sich, einen Bigint- und Festkomma-Offset zu verwenden, aber das ist ungeschickt und unflexibel. Die Verwendung von Gleitkommawerten ist sehr selten die richtige Antwort, da es schwierig ist, zuverlässig mit Gleitkommawerten für Dinge wie Währungen zu arbeiten.
(Übrigens, ich bin ziemlich aufgeregt, dass einige neue Intel-CPUs und IBMs Power 7-Reihe von CPUs Hardwareunterstützung für IEEE 754-Dezimal-Gleitkomma enthalten. Wenn dies jemals in CPUs der unteren Preisklasse verfügbar wird, wird dies ein großer Gewinn für Datenbanken sein .)
