零件编号字段的原子性
在我们的内部库存应用程序中，我们存储三个值（在单独的字段中），这些值成为以下格式的打印“部件号”：PPP-NNNNN-VVVV（P = 前缀，N = 编号，V = 版本）。
例如，如果您有一个部件 010-00001-01，您就知道它是“010”类型部件的版本 1（假设是印刷电路板）。
因此，在创建零件的过程中，工程人员希望通过在多个前缀中保持“数字”组件（中间 5 位数字）相同的方式将零件分组在一起，如下所示：
001-00040-0001 - Overall assembly
010-00040-0001 - PCB
015-00040-0001 - Schematics
这似乎是有问题且令人沮丧的，因为它有时会为“数字”添加额外的含义”字段（但不一致，因为并非所有具有相同“数字”组件的部分都必须链接）。
我是一个纯粹主义者还是这样可以？ 1NF 在原子性方面非常模糊。我认为我最感到沮丧的是因为需要额外的逻辑来确保整个零件号的下一个“数字”部分是有效的并且可用于所有前缀。
In our internal inventory application, we store three values (in separate fields) that become the printed "part number" in this format: PPP-NNNNN-VVVV (P = Prefix, N = Number, V = version).
So for example, if you have a part 010-00001-01 you know it's version 1 of a part of type "010" (which let's say is a printed circuit board).
So, in the process of creating parts engineering wants to group parts together by keeping the "number" component (the middle 5 digits) the same across multiple prefixes like so:
001-00040-0001 - Overall assembly
010-00040-0001 - PCB
015-00040-0001 - Schematics
This seems problematic and frustrating as it sometimes adds extra meaning to the "number" field (but not consistently since not all parts with the same "number" component are necessarily linked).
Am I being a purist or is this fine? 1NF is awfully vague with regards to atomicity. I think I'm mostly frustrated because of the extra logic to ensure that the next "number" part of the overall part number is valid and available for all prefixes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
已有不少企业因“零件号综合症”而倒闭或濒临倒闭。您也许可以找到一些案例研究。 DEC 部件号有些混乱。
顾客并不总是对的，但顾客永远是顾客。
在这种情况下，在我看来，工程正在尝试使用单个数字来建模关系。我指的是整体装配、PCB 和 Scematics 之间的关系。最好将关系建模为关系。它可以让您在以后的道路上更加灵活。在这一点上，你可能很难推销工程技术。
There have been a number of enterprises that have foundered, or nearly foundered, on the "part number syndrome". You might be able to find some case studies. DEC part numbers were somewhat mixed up.
The customer is not always right, but the customer is always the customer.
In this case, it sounds to me like engineering is trying to use as single number to model a relationship. I mean the relationship between Overall assembly, PCB, and Scematics. It's better to model relationships as relations. It allows you more flexibility down the road. You may have a hard time selling engineering on this point.
根据我的经验，无论数据库规范规则如何，当客户/顾客/用户希望以某种方式完成某件事时，很可能有一个原因，而这个原因会为他们节省金钱（以某种方式）。有时，它可以通过减少步骤、减少培训成本或仅仅因为这就是它一直以来的方式来节省资金。无论出于什么原因，最终你都会这样做，因为他们付费才能完成它（除非它违反了会计规则）。
在这种情况下，这听起来像是对某些报告查询的额外排序标准，以及带有自动递增键的新“分配数量”表。这对我来说听起来还不错。有时问我有关数据库报告的信息，一位客户副总裁严格委托其以一种让其他副总裁在会议中看起来很糟糕的方式投射数据（并不是他事先告诉我的）。
In my experience, regardless of database normative rules, when the client/customer/user wants something done a certain way, there is most likely a reason for it, and that reason will save them money (in some fashion). Sometimes it will save money by reducing steps, by reducing training costs, or simply because That's The Way It's Always Been. Whatever the reason, eventually you'll end up doing it because they're paying to have it done (unless it violates accounting rules).
In this instance, it sounds like an extra sorting criteria on some queries for reports, and a new 'allocated number' table with an auto-incrementing key. That doesn't sound too bad to me. Ask me sometime about the database report a client VP commissioned strictly to cast data in such a fashion as to make a different VP look bad in meetings (not that he told me that up front).