使数据库ID一致且"可读"的优缺点

Question

使数据库ID一致且"可读"的优缺点

gMa*_*ale 5 database database-design data-driven

题

数据库ID"无意义"是一个很好的经验法则吗？相反,以一种可以一目了然地识别ID的方式构建ID是否会带来显着的好处？优缺点都有什么？

背景

我和我的同事就我们数据库中ID的一致性进行了辩论.我们有一个利用spring的数据驱动应用程序,因此我们很少需要更改代码.这意味着,如果出现问题,数据更改通常就是解决方案.

我的论点是,通过使ID保持一致和可读,我们可以节省大量时间和长期头痛.一旦设置了ID,它们就不必经常更改,如果做得对,未来的更改也不会很困难.我的同事的立场是ID永远不会重要.将信息编码到ID中会违反数据库设计策略并使其有序保持需要额外的工作,"我们没有时间." 我在网上找不到任何支持这两个职位的东西.所以我转向SA的所有大师!

例

想象一下这个简化的数据库记录列表,表示杂货店中的食物,第一组表示具有ID编码含义的数据,而第二组不表示:

ID含义:

Type
1 Fruit
2 Veggie

Product
101 Apple
102 Banana
103 Orange
201 Lettuce
202 Onion
203 Carrot

Location
41 Aisle four top shelf
42 Aisle four bottom shelf
51 Aisle five top shelf
52 Aisle five bottom shelf

ProductLocation
10141 Apple on aisle four top shelf
10241 Banana on aisle four top shelf
//just by reading the ids, it's easy to recongnize that these are both Fruit on Aisle 4

Run Code Online (Sandbox Code Playgroud)

ID无意义:

Type
1 Fruit
2 Veggie

Product
1 Apple
2 Banana
3 Orange
4 Lettuce
5 Onion
6 Carrot

Location
1 Aisle four top shelf
2 Aisle four bottom shelf
3 Aisle five top shelf
4 Aisle five bottom shelf

ProductLocation
1 Apple on aisle four top shelf
2 Banana on aisle four top shelf
//given the IDs, it's harder to see that these are both fruit on aisle 4

Run Code Online (Sandbox Code Playgroud)

摘要

保持ID可读和一致的优缺点是什么？您通常喜欢哪种方法？为什么？是否有公认的行业最佳实践？

--------编辑( 以下评论中有用的背景信息 ):--------

在我们的表中,主键始终是包含唯一整数的ID字段.起初,该整数是任意的.随着时间的推移,其中一些ID在开发人员/测试人员中自然具有意义.在最近的重构期间,某些开发人员也花时间让所有ID更容易识别.它使每个人的工作变得更容易100倍.由于理论上的原因,一些人(实际上并没有使用数据/代码)强烈反对.在实践中,没有一个反对意见是正确的.此外,所有使用这些数据的开发人员都认为它现在更容易维护.

我正在寻找(但没有看到)反对在以数据为中心的环境中使用可立即识别的ID的防御性论点.

Answer 1

Can*_*ice 20

Con:我刚刚将"Aisle Five top shelf"更改为"Aisle Six top shelf",所以现在我必须将其ID更改为61,现在我必须将"Grapes on Aisle five top shelf"的ProductLocation ID更改为10461并且哦,上帝在我的数据库中ID的架子位置ID字符串显示在哪里哦上帝谁设计ID携带意义应该是在早上四点拍摄,一切都疯了,为什么"过道七底架"有一个ID 41个模具模具.

@gmale:变量/函数名称(设计为人类阅读,传授语义信息)和行ID(不是为了人类阅读,也不是为了传授语义信息)之间存在差异. (8认同)
@gmale:你还没有解决"41并不意味着'第4架底部'不再意味着'第5架顶''问题,因此"10141并不代表你认为它意味着什么"的问题,并且因此你无论如何都要去Shelf表找出41的意思.真的,听起来你有这个想法在你的数据库中有语义ID,你跟的每个人都试图告诉你这不是一个好主意,但你坚信你是对的.好吧,有时候规范是有原因的常态. (3认同)
@gmale:你的解释没有意义.如果您正在尝试修复数据问题,请编写公开此信息的查询.您现在只会通过编码id中的信息来加剧问题.如果您愿意,数据库将帮助您保持完整性.如果您设计自己的metaschema,您可能允许对数据进行目视检查,但是您失去了验证机器的能力. (2认同)
@gmale:如果值*可以*改变,那么我们回到问题"为什么101编码到ID中对人类更有用,而不是存储在另一列中的值101(或简称为1)这行,假设下次可能是102？" 人工调试器总是必须交叉引用. (2认同)

Answer 2

Mar*_*c B 5

好吧，鉴于您的10141“苹果在第四过道”，当您最终将产品10放在1货架上的过道时会发生什么41？或者该产品是1在014货架上的过道中，还是因为不在货架上而位于地板上的过道中的1产品？10141

一旦开始像这样混合数据，您通常会失去可靠提取组件的能力。人类可读的密钥固然很好，但你永远不会破坏人类形态所基于的各个 ID。

Answer 3

ale*_*ntd 5

使用数据库ID编码有关行的信息有几个问题.如果您希望胡萝卜的"ID"为203,则应添加一product_id列(例如)并将此信息放在那里.为什么？

通过自定义ID,您必须添加管理ID的特定于域的代码,并且不能依赖自动递增或UUID等数据库功能.
如果您必须更改分类,则会破坏您的表格关系,浏览器书签,搜索引擎结果等.
这不常见 - 因此当您将特定于应用程序或域的数据放入ID字段时,许多人会认为这是无意义的信息,而不是.您将需要一个数据字典(并且您必须确保人们阅读数据字典)以注意这是有价值的信息.

ID唯一需要的目的是唯一标识表中的行.如果它可以提供良好的查找性能,这是一个奖励,如果它可以紧凑存储,那是另一个奖励.但它不应包含有关其标识的行中的实体的任何信息,除了该实体的唯一标识符.

归档时间：	14 年，7 月前
查看次数：	2404 次
最近记录：	9 年，8 月前