ISBN 用作主键，现在我想将非书籍内容添加到数据库中 - 我应该迁移到 EAN 吗？
我建立了一个库存数据库，其中 ISBN 编号是商品的主键。这在一段时间内非常有效，因为这些物品是书籍。现在我想添加非书籍。有些非书籍有 EAN 或 ISSN，有些则没有。
它位于 PostgreSQL 中，带有用于前端的 django 应用程序和 JSON api，以及一些用于管理的支持 python 命令行工具。涉及的物品主要是书籍和艺术家印刷品，其中一些是自行出版的。
使用 ISBN 作为主键的好处是，除了关系完整性之外，您还可以获得许多方便的实用程序来验证 ISBN、自动查找有关图书项目的缺失或附加信息等，其中许多我都利用过。有些这样的工具是现成的（PyISBN、PyAWS 等），有些是手工制作的——我试图让所有这些部分保持良好和解耦，但你知道事情会如何发展。
我在网上找不到任何有关“私人 ISBN”或“自分配 ISBN”的信息，但这正是我感兴趣的事情。我怀疑这就是我会做出的决定，因为 ISBN 号码已经出现了明显的挤兑现象。
我应该重新调整 EAN 编号的所有内容，还是将 ISBN 迁移为一般主键？如果有人有使用这些系统的经验，我很想听听，非常欢迎您的建议。
I built an inventory database where ISBN numbers are the primary keys for the items. This worked great for a while as the items were books. Now I want to add non-books. some of the non-books have EANs or ISSNs, some do not.
It's in PostgreSQL with django apps for the frontend and JSON api, plus a few supporting python command-line tools for management. the items in question are mostly books and artist prints, some of which are self-published.
What is nice about using ISBNs as primary keys is that in on top of relational integrity, you get lots of handy utilities for validating ISBNs, automatically looking up missing or additional information on the book items, etcetera, many of which I've taken advantage. some such tools are off-the-shelf (PyISBN, PyAWS etc) and some are hand-rolled -- I tried to keep all of these parts nice and decoupled, but you know how things can get.
I couldn't find anything online about 'private ISBNs' or 'self-assigned ISBNs' but that's the sort of thing I was interested in doing. I doubt that's what I'll settle on, since there is already an apparent run on ISBN numbers.
should I retool everything for EAN numbers, or migrate off ISBNs as primary keys in general? if anyone has any experience with working with these systems, I'd love to hear about it, your advice is most welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不知道 postgres，但通常 ISBM 是唯一索引键，但不是主键。最好使用整数作为主键/外键。这样，您只需将新字段 EAN/ISSN 添加为可为空即可。
I don't know postgres but normally ISBM would be a unique index key but not the primary. It's better to have an integer as primary/foreign key. That way you only need to add a new field EAN/ISSN as nullable.
我同意 the_lotus 的观点，尤其是因为 ISBN 对于主键
数据来说是一个糟糕的选择，它可能不够唯一。如果聚集，它会非常宽且非数字
示例< /a>
I agree with the_lotus, not least because ISBN is a poor choice for primary key
Data wise, it may not be unique enough. If clustered, it's quite wide and non-numeric
Example
如果您使用的是 ISBN-10，那么您绝对应该迁移到其他内容，因为这些内容已经被弃用。您可以轻松地将 ISBN-10 转换为 ISBN-13（请参阅 wikipedia），这我认为是 EAN 兼容的（再次参见 wikipedia），但正如 the_lotus 所建议的那样，它可能是最好使用某种没有外部含义的自动递增整数作为主键，然后在 EAN/ISBN/等上建立索引。
If you're using ISBN-10s, then you definitely should migrate to something else, as those are already deprecated. You can easily take ISBN-10s and turn them into ISBN-13s (see wikipedia), which I think are EAN-compatible (again, see wikipedia), but as the_lotus suggests, it's probably better to have some sort of auto-incrementing integer with no external meaning as the primary key and then index on the EAN/ISBN/etc.
一个简单的解决方案（尽管可以说是否好）是使用 (isbn,title) 或 (isbn,author) ，这几乎可以保证唯一性。意识形态固然重要，但实用性也有其目的。
A simple solution (although arguably whether good) would be to use (isbn,title) or (isbn,author) which should pretty much guarantee uniqueness. Ideology is great but practicality also serves a purpose.