- 主题:double类型可以用来做形式主键吗?
你这里会写这种格式么? where pk_col = 124.55;
怎么保证外面调用的时候压进来的参数(如果是用double压)不会变成124.54999999
如果是用string压进来的,我觉得你这直接存varchar2好像也差不多
【 在 misslost 的大作中提到: 】
: 这里我强调的是 形式主键,不是业务主键。所以,一般不存在数学运算的情况。
--
FROM 183.157.72.*
确是如此的。默认就是将int64转成字符串,而且也没有选项可以调节的。如果要改似乎只能改源码,而且改了之后因为不符合规范,是无法跟外部系统对接的。其实仔细考虑,我能够理解protobuf的这种设计理念。
我觉得这个锅应该是json来背。多少年了,落后了毫无升级。
【 在 ble 的大作中提到: 】
: pb转json的int64默认是字符串吗?难道不应该用户主动设置才会转字符串?
: 发自「今日水木 on 钛星」
--
FROM 120.245.130.*
这样的where字句肯定很多。
我用到的主键值都是整型转的,就是1.0 2.0之类的 小数位都是零。
是否存在你说的这种奇怪的转换问题,还真不知道呢。
【 在 vmx 的大作中提到: 】
: 你这里会写这种格式么? where pk_col = 124.55;
: 怎么保证外面调用的时候压进来的参数(如果是用double压)不会变成124.54999999
: 如果是用string压进来的,我觉得你这直接存varchar2好像也差不多
--
FROM 120.245.130.*
然。
没道理因为用pb影响数据库设计
【 在 poggy 的大作中提到: 】
: ⅰU庠诤芏嗟胤骄湍咽芰耍娲⒑捅冉希判蚨蓟嵊形侍狻K钥悸怯胐ouble规避这个问题。)
: 如果数据库为啥不用int64, BIGINT, 至于数据传输,序列化这根本不是问题, 无非就是序列化过程做一下处理, 序列化本来也就是做这个工作的, 这是本分。
: 至于protobuf或者json支持不支持64, 这根本不是问题, 无论用字符串传输, 或者干脆弄成两个int传输都很容易。
: ...................
--
FROM 61.145.150.*
你要用double存整数啊?
那感觉问题不大,就是有点浪费,因为用double的安全整数只有52+1位,浪费了64-53=11位 (这些尾数都设置为0了)
【 在 misslost 的大作中提到: 】
: 关于数学运算。我感觉主键主要是比较关系运算,不需要对主键进行数学运算。所以好像没什么影响?
: 因为主键的值是很规范的很普通的浮点值,也不会有NaN等问题?
: 占用空间确实是8字节。其实本来是希望用int64 但是因为某种奇怪的外部原因 不能选择这个类型。(其实这个奇怪原因也可以解释一下,是无关话题。因为用到protobuf定义数据结构和json规范。而protobuf认为json的局限性导致没有int64的完善支持,所以会把int64转换为字符串存储。这在很多地方就难受了,存储和比较,排序都会有问题。所以考虑用double规避这个问题。)
: ...................
--
FROM 183.95.135.*
1. 数据库里double做主键不是好选择,主键比对就是个很大的问题
2. pb里设置成string,数据库里设置成number(64,0),是不是问题也不大?
3. 数据库里,设置为string,对性能影响其实也不大,我看很多项目已经用uuid做主键了(uuid做主键其实是个不好的选择)
【 在 misslost 的大作中提到: 】
: 最近一个小项目里面,因为某种不足评论的原因,在考虑用double做表的形式主键。是业务系统内部生成的唯一递增的值。
: 虽然是觉得荒谬。但还是想认真请教一下,这么做有没有大的弊端?是否可行?
--
FROM 124.64.23.*
json已经支持int64类型。
【 在 misslost 的大作中提到: 】
: 关于数学运算。我感觉主键主要是比较关系运算,不需要对主键进行数学运算。所以好像没什么影响?
: 因为主键的值是很规范的很普通的浮点值,也不会有NaN等问题?
: 占用空间确实是8字节。其实本来是希望用int64 但是因为某种奇怪的外部原因 不能选择这个类型。(其实这个奇怪原因也可以解释一下,是无关话题。因为用到protobuf定义数据结构和json规范。而protobuf认为json的局限性导致没有int64的完善支持,所以会把int64转换为字符串存储。这在很多地方就难受了,存储和比较,排序都会有问题。所以考虑用double规避这个问题。)
: ...................
--
FROM 221.221.48.*