存储enum MongoDB

use*_*702 27 enums mongodb

我正在为Mongo数据库中的每个用户存储排名(管理员,主持人,用户...)和成就等枚举的枚举.据我所知,Mongo没有枚举数据类型,这意味着我必须使用其他类型存储它.

我曾想过使用整数来存储它,我认为这些整数使用的空间比存储字符串的空间少,因为它可以很容易地表示为整数.我看到使用整数的另一个好处是,如果我想重命名成就或排名,我可以轻松地更改它,甚至无需触摸数据库.我看到使用字符串的好处是数据在使用之前需要较少的处理,并且更易于阅读,这有助于追踪错误.

有没有更好的方法在Mongo中存储枚举?是否有充分的理由使用整数或字符串?(试图远离一个更好的问题)

mne*_*syn 29

TL; DR:字符串可能是更安全的选择,性能差异应该可以忽略不计.对于必须对枚举进行索引的大型集合,整数​​才有意义.因人而异.

我曾想过使用整数来存储它,我认为这些整数使用的空间比存储字符串的空间少,因为它可以很容易地表示为整数

真正.

我看到使用整数的其他优点是,如果我想重命名成就或排名,我可以轻松地更改它,甚至不必触摸数据库.

在我看来,这是整数的关键优势.但是,它还要求您确保相关的值enum不会更改.如果你搞砸了,你几乎肯定会造成严重破坏,这是一个巨大的劣势.

我看到使用字符串的好处是数据在使用之前需要较少的处理

如果您实际使用的是枚举数据类型,那么它可能是内部的某种整数,因此整数应该需要较少的处理.无论哪种方式,开销都应该可以忽略不计.

是否有充分的理由使用整数或字符串?

我重复了很多已经说过的话,但也许这有助于其他读者.加起来:

  • 混合枚举值映射会造成严重破坏.想象一下你的Declined状态突然被解释为Accepted,因为Declined它的值为'2'而现在是Accepted因为你重新排序枚举而忘记手动赋值......(颤抖)
  • 字符串更具表现力
  • 整数占用的空间更少.通常,磁盘空间无关紧要,但索引空间会占用昂贵的RAM.
  • 整数更新不会调整对象的大小.字符串,如果它们的长度变化很大,可能需要重新分配.但是,字符串填充和填充因子应该可以缓解这个问题.
  • 整数可以是标志(尚不可查询(还),遗憾的是,参见SERVER-3518)
  • 可以通过$gt/ 来查询整数,$lt因此您可以有效地实现复杂的$or查询,尽管这是一个相当晦涩的要求,$or查询没有任何问题......

  • 有没有人做过与此相关的任何性能测量?比较字符串比比较整数要慢.这可能会影响查询以及插入和索引(重新)构建,尽管索引确实会显着减少所需的比较次数.如果没有基准,请不要对性能提出任何要求. (4认同)