【问题标题】:Getting Sum of milligram, grams, and kilograms in MYSQL在 MYSQL 中获取毫克、克和公斤的总和
【发布时间】:2016-06-26 05:53:17
【问题描述】:

我使用数据类型 decimal(10,3),现在我尝试获取所有列的 SUM,它的返回取决于所有单位的 SUM。

例如:

0.789 mg
98.057 g
5.008 kg

查询是自动计算的,但是如何计算呢?

我试过了:

SELECT CONCAT(SUM(prod_name,'-',prod_quantity,' ',
    CASE WHEN prod_unit = 'mg' THEN 'g' 
         ELSE prod_unit 
    END)) AS shortName 
FROM prod_table;

答案是错误的,我不知道添加质量或体积的公式是什么。

【问题讨论】:

  • 表结构是什么?
  • 您可能应该以最小公分母的重量存储所有项目。在您的情况下,这将是 mg 中的所有产品。因此,重量为 5.008 公斤的物品的重量值为 5008000(等于产品重量,单位为毫克)。当你想显示一个产品的重量时,很容易通过一个简单的函数将5008000转换为"5.008 kg"。这将使您的许多事情变得更容易。例如,您可以轻松地按重量排序或对许多物品的重量求和,而无需预先转换单位。 简答:修正你存储数据的方式,你的问题就会消失。
  • 或者作为另一个例子,这更容易通过产品价格之类的东西看到。价格(作为一个例子)可以由美元和美分组成。存储一些具有美分价值的产品而另一些具有美元价值的产品将是愚蠢的。以美分表示所有产品(INT 类型)或以美元表示所有产品(DECIMAL 类型)。做出选择并使其保持一致。这是最重要的部分。
  • 我还强烈建议您将这些存储在一个通用单元中,以避免意外混淆单元的严重混乱。这很有可能发生故障,有人认为他们正在运输 10 公斤的材料,而实际上它是 10 吨。

标签: mysql sql select sum


【解决方案1】:

这个问题有两个部分。首先,您应该正确添加权重,这意味着在将它们转换为相同单位后将它们全部添加。为避免丢失精度,我们以毫克为单位添加它们:

SELECT SUM(prod_quantity * CASE prod_unit WHEN 'mg' THEN 1
                                          WHEN 'g'  THEN 1000
                                          WHEN 'kg' THEN 1000000
                           END) sum_milligrams
FROM   prod_table;

这将以毫克为单位给出结果。现在,我们可以通过决定以哪些单位显示输出来美化输出。例如,我们可以决定任何重量为 1 kg 或以上的东西都以 kg 显示,1 gr 到 1 kg 之间的任何东西都以 g 显示,任何小于 1 kg 的东西都以 mg 显示:

SELECT CASE WHEN s > 1000000 THEN CONCAT(s/1000000.0, ' kg')
            WHEN s BETWEEN 1000 AND 1000000 THEN CONCAT(s/1000, ' g')
            ELSE CONCAT(s, ' mg')
       END
FROM   (SELECT SUM(prod_quantity * CASE prod_unit WHEN 'mg' THEN 1
                                                  WHEN 'g'  THEN 1000
                                                  WHEN 'kg' THEN 1000000
                                   END AS s
        FROM   prod_table) t;

【讨论】:

  • 那么,我需要做的就是将我的数据类型更改为 decimal(10,2) ?我是对的?
  • @ArnoldZurbito 你怎么看?
  • @ArnoldZurbito,作为一个拥有约 100K 声誉的用户,您能否教育新手用户而不是给他们意大利面条 SQL 以允许他/她的不良模式继续存在?我知道真正教育一个人更难,但请努力。
  • @naomik 我不同意你的分析,你的观点是事实。我认为这个模式或多或少是好的。 OP 应考虑将单位及其转换因子存储在单独的表中。那么解决方案将涉及一个简单的连接。
  • 这里提供的SQL并不是一团糟。
猜你喜欢
  • 2021-02-23
  • 1970-01-01
  • 1970-01-01
  • 2010-12-22
  • 2022-08-06
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-09-23
相关资源
最近更新 更多