【问题标题】:Any reason to have a numerical ID in a database?有什么理由在数据库中有一个数字 ID?
【发布时间】:2013-02-05 11:51:14
【问题描述】:

我基本上有很多不同的数据库,它们组合成一个 SOLR 存储。必须这样,我无法改变。

我给每个数据库中的每个项目一个唯一的 ID,但是当我将数据库合并到 SOLR 中时,我发现我有多个具有相同 ID 的项目,例如:

Database A
Itemid: 1

Database B
Itemid: 1

SOLR:
Itemid: 1
Itemid: 1

相反,我现在的主 ID 前面带有数据库名称,如下所示:

Database A
Itemid: A1

Database B
Itemid: B1

SOLR:
Itemid: A1
Itemid: B1

我的问题是,拥有非数字 ID 是否有任何正当理由,我还能根据这些 ID 进行排序吗?

【问题讨论】:

  • 显示更多代码!原始数据库的数据库模式是什么?你是如何合并它们的?

标签: database linux postgresql solr


【解决方案1】:

如果您关心性能而不是坚持使用数字 ID。 (见Database Design Primay Key, ID vs String

但为了完成您的任务,我会在数据导入阶段将数据库名称前缀添加到 Solr ID。所以你会有:

Database A
Itemid: 1

Database B
Itemid: 1

SOLR:
Itemid: A1
Itemid: B1

【讨论】:

  • 如何在每个数据库中指定前缀,以便交叉引用它们?例如,如果我想从我的数据库连接到 Solr,我如何将字母 (A) 与特定数据库相关联?
  • 基本上我只是想以某种方式将标签放在数据库上,说这是数据库“A”,所以当在 solr 上交叉引用时,它应该是“A
  • 这取决于您的架构。如果您有一个“了解”所有数据库并负责所有跨数据库和 Solr 通信的服务层,那么在代码中的某处维护一些枚举或映射以将标签分配给数据库就足够了。或者,如果您愿意(或可以),您可以在所有数据库中添加一个小表来存储元数据(例如 MY_INFO_TABLE)并将标签存储在那里。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2013-05-06
  • 2012-08-17
  • 2010-10-02
  • 2011-04-18
  • 2019-12-17
  • 2019-07-21
  • 2010-10-01
相关资源
最近更新 更多