MSTR中Numeric、Big Decimal、Long prompt的区别及位数设置疑问

三类Prompt的核心差异 #

很多人会把三者的差异简单等同于长度不同，实际上三者的底层类型映射、精度规则、校验逻辑、适用场景是完全独立的，长度只是规则落地的表象：

• Numeric Prompt：适配常规业务数值输入场景，标称15位的长度上限覆盖整数、带少量小数的混合输入格式，内部计算路径走双精度浮点逻辑，支持正负号、小数点、常规数值格式输入，没有刚性的小数位限制。
• Big Decimal Prompt：适配财务、高精度计量类的无误差计算场景，标称38位的长度上限支持最高38位有效数字的定点存储，所有计算走定点运算逻辑，完全规避浮点计算带来的精度偏移问题，不允许使用任何带精度损失的数值表示方式。
• Long Prompt：适配纯整数类输入场景，标称10位的长度上限仅支持正负号、纯数字字符输入，内部计算走整数算术路径，从底层锁死小数输入的可能性，不触发任何浮点转换流程。

15位长度的Numeric Prompt存在的前提下，为什么还要保留10位长度的Long Prompt？ #

不少新手开发者会觉得，Numeric Prompt的长度比Long Prompt长，覆盖范围应该更大，Long Prompt属于冗余设计，但实际上两者的能力边界完全不重叠，不存在谁替代谁的关系，保留Long Prompt的核心原因有三点：

• 从源头减少输入错误：Numeric Prompt的校验规则是宽松的，只要不超15位、格式符合常规数值要求就允许提交，即便业务上要求用户输入纯整数（比如员工ID、SKU编号、短流水号），也挡不住用户误输小数点、科学计数法标识的操作，后续会引发维度匹配失败、过滤逻辑报错的问题。Long Prompt从底层校验逻辑上就禁止非纯整数的输入，在提交环节就拦住错误输入。
• 降低SQL执行的性能损耗：Long Prompt传递的参数是纯整数类型，生成的过滤条件可以直接匹配数据库侧的整数索引，不会触发类型隐式转换。如果用Numeric Prompt传递同范围的整数，会因为内部的浮点存储逻辑，让数据库端执行“整数列转浮点数再匹配”的隐式转换，直接导致索引失效，大幅拉慢报表查询速度。
• 规避浮点精度带来的匹配异常：Numeric Prompt的双精度浮点存储路径，在处理数值时会存在精度边界，比如传入的整数会被转成带微小小数偏差的浮点数，和数据库侧存储的纯整数维度值无法精确匹配，哪怕数值长度没超过15位，也会出现过滤结果为空的问题。Long Prompt走纯整数存储和传递路径，完全不存在这类精度偏差。

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