0

您对此有何看法？我正在整合一些以制表符分隔的文本格式的新数据，并且所有小数列都保存为单个整数；为了确定小数，您需要将数字乘以 0.01。它针对百分比、重量和定价信息等信息执行此操作。例如，一个项目的价格3259在数据文件中表示，当我想显示它时，我需要将它相乘以获得“真实”数量32.59。

你认为这是个好主意还是坏主意？我应该保持我的数据结构与供应商提供的数据结构相同，还是应该将数据库列设为真正的小数并使用 SSIS 或某种 ETL 过程自动将整数列乘以它们的十进制等值？在这一点上，我还没有决定是否要使用 ORM 或存储过程或什么来检索数据，所以我试图从长远来看并决定使用哪种方法。我也可以轻松地在 DTO 或类似的代码中处理这个问题，类似于：

public class Product
{
    // ...
    private int _price;
    public decimal Price
    {
        get
        {
            return (this._price * .01);
        }
        set
        {
            this._price = (value / .01);
        }
    }
}

但这似乎是班级的额外和不必要的工作。您将如何处理这个问题，请记住，数据是由供应商以整数格式提供的，您将经常需要从中获取更新。

4

4 回答 4

4

“你认为这是个好主意还是坏主意？”

坏的。

“我应该保持我的数据结构与供应商提供的相同吗？”

不。

“我应该让数据库列真正的小数吗？”

是的。

做正确的事要简单得多。目前，数据传输时没有“.”。将整数与小数分开；这没有任何实际意义。

数据为十进制。十进制数学有效。使用您的语言和数据库提供的十进制数学。不要发明自己的十进制算术版本。

于 2009-02-10T20:14:43.820 回答
1

就个人而言，我更希望将数据正确存储在我的数据库中，并且每次更新时都进行简单的转换。

于 2009-02-10T20:13:59.483 回答
0

迂腐地：它们也没有被保存为整数。它们是需要解析的字符串。

从哲学上讲：您在文件中有信息，您应该将数据写入数据库。这意味着以任何必要的方式转换信息以使其有意义/有用。如果您不预先进行此转换，那么您将注定要在数据库的所有使用者中重复转换。

在某些情况下，您不允许转换数据，例如能够回答以下问题：“文件中有什么？”。这些场景需要将数据写入字符串 - 如果解析失败，您将无法获得文件的准确表示。

于 2009-02-10T20:13:54.087 回答
0

在我看来，在这种情况下使用 Decimal over Int 最重要的方面是可维护性。

存储在表中的数据应该是有意义的，无需任意操作。如果需要操作，则应该清楚地表明它是（例如从字段名称）。

我最近处理了一周中的几天存储为值 2-8 的数据。你无法想象这造成的后果（由于各种原因测试没有显示问题，但现场使用确实引起了政治爆炸）。

如果您确实遇到过这种情况，我绝对可以确保在不使用存储过程或视图的情况下无法将数据写入表或从表中读取数据。这使您能够确保执行和记录必要的操作。如果你没有这两个，将来跟随你的一些可怜的草皮会诅咒你的名字。

于 2009-02-10T23:32:55.730 回答