一张销售订单表里，订单号看起来全是数字，金额也由数字组成，创建时间则常常显示成一串字符。可是在数据库眼里，这三列不能因为外观相似就按同一种方式处理。订单号用于识别业务对象，金额需要参与精确计算，创建时间需要比较先后、计算时间差。列的数据类型，决定了值可以怎样存储、比较和运算；写进 SQL 的常量，则决定了数据库如何理解查询里那个固定的值。这种差别在排查问题时尤其明显。把订单号当成整数，可能丢掉有意义的前导零；把金额交给二进制浮点数，可能碰到舍入差异；把日期写成普通字符串，则把原本明确的时间语义交给了转换规则。SAP HANA 的数据类型看似是一张名称清单，实际连接着业务含义、SQL 表达式和应用程序之间的数据传递。SAP HANA 的类型体系包含日期时间类型、数值类型、布尔类型、字符类型、二进制类型、大对象类型、多值类型、空间类型，以及向量类型。还有一个贯穿所有类别的特殊值NULL，表示某个值缺失。理解这套体系，可以从我们每天处理的一张订单表开始。订单创建日期适合用DATE表示，创建时刻若需要保留日期与时间，可以使用TIMESTAMP。只有一天中的钟点而不涉及具体日期时，TIME才符合它的含义。SECONDDATE也同时包含日期和时间，但精度到秒。选择哪一种，取决于业务究竟记录了什么，而不是界面准备显示什么。假定报表只关心订单属于哪一天，DATE足够清楚。审计记录若需要区分同一秒内先后发生的操作，就应评估TIMESTAMP。反过来，若原始系统只提供秒级时间，把它放进能够表达更细精度的列，也不会凭空产生更