将两个整数存储为小数

Question

将两个整数存储为小数有什么缺点？

我将资产详细信息存储在表中，每种资产类型都有自己的表（每种资产都非常不同）并使用另一个表来定义资产表，因此每个资产表都有一个整数 id，每个资产也有一个整数 id。

我有两种不同的场景，这可能很方便：

1. 有一个“审计”表，其中存储如下信息：这个用户对那个项目做了这个

2. 有人被指派处理这种类型的资产。我正在考虑将它存储为 assetType.assetID，因此资产类型 5 和 id 99 将是十进制 5.99

我很少需要根据 5.99 进行选择，我只会查询存储 5.99 的记录，然后将其拆分并使用函数转到表 5 的记录 99。

我无法将资产 ID 绑定到特定表；assetType 是表中引用资产表的条目的 id（定义表名、主键列等内容），因此似乎我无法以任何方式使用外键约束。

有很多资产表，例如asset_tmv和asset_backflow。资产根据它所在的表分配类型，因为要为每个资产存储的数据差异很大。

我意识到我可以使用 2 个整数字段来实现这一点。我想知道的是：缺点是什么？

Answer 1

_{注意：为了展示通过其专用（逻辑级）列处理每个离散数据点的优势，此答案仅基于以下摘录：}

_{…有人被指派处理这种类型的资产。我正在考虑将它存储为 assetType.assetID，因此资产类型 5 和 id 99 将是十进制 5.99……}

_{为了全面分析场景（每个实体类型、属性和相关关联），对您正在处理的特定业务领域的所有信息需求的描述是必不可少的；换句话说，人们必须知道适用的业务规则，这在当时此编辑，都没有被提供。}

_{如果您想提供所需的所有信息以及所有相关细节，请告诉我，我很乐意分享我对整个场景的看法。}

您通过评论澄清了您的意图是构建一个关系数据库，因此在同一列中保留两条不同的信息将意味着多个缺点，例如：

• 所考虑的数据库的逻辑抽象级别不会以所需的精度表示相应的概念模式。

• 以声明方式设置逻辑级约束（值验证）将更加困难（或不可能）（必须求助于陈旧的、次优的、程序化的方法来保护数据完整性）。

• 逻辑级别的数据操作变得不必要地繁琐。

• 数据库管理系统必须在物理级别执行以优化甚至支持逻辑操作的工作变得多余地复杂。

• 数据库的使用通常会变得不必要地更加困难，因为数据库结构和约束会让 DBA、应用程序程序员以及更重要的是最终用户（在某些环境中，有访问数据库的高级用户无需应用程序帮助）感到困惑。

该资产例子

我们以资产实体类型的场景为例。所以，从概念层面开始分析，可以说：

• 的资产主要是由它的区分标识
• 一个资产是交替正好一区分名称
• 一个资产正好由一分类型。
• A Type分类零一或多个资产

因此，该特定业务领域的信息需求需要跟踪两个不同的数据点，即Asset.Id和Asset.Type，每个数据点都有确切的含义；因此，在这个阶段很清楚他们每个人：

• 需要一组特定的约束；和
• 有可能单独进行操作。

随后可以通过以下逻辑级 SQL-DDL 布局来表示所述概念元素：

CREATE TABLE asset_type ( 
    asset_type_id INT      NOT NULL,
    name          CHAR(30) NOT NULL,
    --
    CONSTRAINT asset_type_PK PRIMARY KEY (asset_type_id),
    CONSTRAINT asset_type_AK UNIQUE      (name) -- ALTERNATE KEY.
); 

CREATE TABLE asset ( 
    asset_id      INT      NOT NULL,
    name          CHAR(30) NOT NULL,
    asset_type_id INT      NOT NULL,
    -- 
    CONSTRAINT asset_PK PRIMARY KEY               (asset_id),
    CONSTRAINT asset_AK UNIQUE                    (name), -- ALTERNATE KEY.
    CONSTRAINT asset_to_asset_type_FK FOREIGN KEY (asset_type_id)
        REFERENCES asset_type (asset_type_id)
);

正如所演示的，每个数据都将保存在其专用列中，并且采用这种安排：

• 可以asset.asset_id声明性地将其约束为asset表的 PRIMARY KEY ，这可以防止在此类列中接受重复值的可能性。多年来，数据库管理系统程序员一直致力于优化在“幕后”执行的相关物理级流程。

• 被声明为 PRIMARY KEY，该asset.asset_id列现在可以从一个或多个 FOREIGN KEY 约束中“用作目标”，以防万一。

• 通过在asset.asset_type_id列上声明 FOREIGN KEY 约束，引用asset_type.asset_type_id.

• 在数据操作操作中，您不必求助于访问列值子部分的函数（如非原子组合列的情况），无论是 INSERT、SELECT、UPDATE、DELETE 还是它们的组合。函数会 (1) 增加物理级别的处理时间，以及 (2) 会降低代码可读性。

• (a) 逻辑布局精确地反映了 (b) 概念模式，这有助于所有相关方在解释数据结构和结果集时。编写查询本身要简单得多，因为每一列都代表一条清晰且独立的信息。

• 在物理级别，拥有一个单独的asset.asset_type_id列允许为该表修复一个（或多个）单列或多列索引，这可以加快逻辑查询的执行，例如，将该列作为条件包含在WHERE 子句。

因此，鉴于上述所有内容，我的主要观点是：每个感兴趣的数据点都应在逻辑级别由其相应的——正确类型和适当约束的——单独列表示。

我建议您自己重新彻底分析场景，从 (i) 概念层面开始，然后继续 (ii) 相应的逻辑设计，因为该方法有助于获得精确的映射，并且您将能够避免不必要的直接破解。

审计追踪

您在问题中提到您有兴趣为有问题的数据库启用某种审计跟踪，因此，有鉴于此，我建议遵循我在此答案和其他答案中公开的方法（两者都是关于当然，时间能力）具有相关的适应性。

Answer 2

2. 有人被指派处理此类资产。我正在考虑像 assetType.assetID 一样存储它，因此资产类型 5 和 id 99 将是十进制 5.99

但用户没有在工作assetID=99，用户正在工作assetID=990。我确信 MySQL 会匹配5.99两者。

您应该将两个不同的值存储在两个不同的列中。