DynamoDB单表设计中用实体名称作ID的安全性与最佳实践疑问

在AWS DynamoDB单表设计中，我原本使用UUID作为实体ID，但创建时为了保证唯一性，需要扫描数据库校验名称，既麻烦又成本高昂。后来调整方案：不再用UUID，而是将实体名称替换空格为下划线后作为ID（例如Company#Dell、Company#The_Facebook），查询时直接使用名称。

现在有两个疑问：

1. 仅用名称作为ID是否存在安全问题？或是一种反模式？
2. 另一种方案是用基于名称生成可复现ID的简单哈希函数（如下方代码），依托DynamoDB条件表达式通过PK/SK保证唯一性，这种方案是否可行？

function hashCode(s) {
    for(var i = 0, h = 0; i < s.length; i++)
        h = Math.imul(31, h) + s.charCodeAt(i) | 0;
    return h;
}

一、直接用名称作为ID的风险与适用性 #

安全问题 #

• 可预测性风险：如果ID在API、前端等公开场景暴露，攻击者可以通过枚举常见名称（如Company#Apple、Company#Microsoft）获取所有实体信息，若实体包含敏感数据，会导致信息泄露。
• 特殊字符处理风险：如果名称包含#、/等你用来分隔PK/SK的特殊字符，仅替换空格为下划线可能破坏键的格式，引发查询或存储错误。不过只要提前统一处理所有特殊字符（比如转义或替换），这个问题可以规避。

是否属于反模式？ #

不是绝对反模式，属于语义化ID，在特定场景下非常实用：

• 优势：无需额外存储名称字段，减少数据冗余；查询时直接用名称构造PK/SK，逻辑更直观，避免额外的查询条件。
• 劣势：
  • 名称变更成本极高：如果实体名称需要修改（比如The_Facebook改为Facebook），所有依赖该ID的关联数据（如其他表的外键、缓存记录、客户端存储）都需要同步更新，维护成本陡增。
  • 唯一性冲突：若存在同名实体（如不同地区的两家“ABC公司”），仅靠名称无法区分，必须在ID中加入额外维度（如Company#ABC_US）才能保证唯一性。

二、基于名称的可复现哈希函数方案分析 #

优势 #

• 保留了可复现性：创建实体时可以通过attribute_not_exists(PK)条件表达式直接校验唯一性，无需扫描全表，解决了UUID方案的成本问题。
• 比UUID更紧凑：哈希值（尤其是示例中的32位整数）存储成本略低，且可预测性比直接用名称低，一定程度上降低枚举风险。

劣势 #

• 哈希冲突风险：示例中的hashCode是32位整数，不同名称生成相同哈希的概率远高于SHA-256等长哈希算法，一旦发生冲突，会导致合法实体无法创建（条件表达式误判为已存在）。
• 无语义性：查询时需要先计算名称的哈希值才能构造PK/SK，不如直接用名称直观；若名称变更，同样面临ID与名称脱节或同步更新的问题。

三、推荐方案 #

1. 如果实体名称满足以下条件：全局唯一、不会变更、非敏感数据 → 直接用名称作为ID，是最简洁高效的选择。
2. 如果名称可能变更或存在同名风险：
   • 保留UUID/哈希作为ID，同时单独存储name字段，创建时用条件表达式attribute_not_exists(PK) AND attribute_not_exists(name)保证名称唯一。
   • 或者采用前缀#名称#额外维度的ID格式（如Company#Dell#US），通过额外维度规避同名冲突，同时保留语义化查询的优势。
3. 若选择哈希方案：替换示例中的简单哈希为SHA-256等稳健的哈希算法，并添加冲突处理逻辑（如冲突时在哈希值后追加序号）。

内容的提问来源于stack exchange，提问作者stevevar