是拥有一张大桌子更好还是应该使用几张桌子？
我正在构建一个新应用程序，其中包含许多数据对象，每个数据对象都需要“历史记录”或注释。过去，我刚刚创建了一个名为 notes 的数据库表，并将许多外键附加到不同的对象。这次我想听听其他人的想法。使用一张具有不断增加的 auto_inc ID 的表是一种良好的做法/效率吗？还是应该维护不同的 [object]_notes 类型表？
注意：Notes 对象本身始终相同，主题、文本、日期等。
I'm building a new application that has a number of data objects and each one needs "history" or notes. In the past I have just created one database table called notes and had a number of foreign keys attached to the different objects. This time I would like others thoughts. Is it good practice/efficient to use one table with ever increasing auto_inc IDs or should I maintain different [object]_notes type tables?
N.B. The Notes object itself would always be the same, subject, text, date etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我只用一张桌子。我想我们不是在谈论无数的历史笔记？
如果没有的话，1张桌子就可以了
I'd use only 1 table. I assume we're not talking gazillions of history notes?
If not, then 1 table is just fine
我认为您要问的问题是，自动递增 ID 是否与复合自然键或由 2 个实体组成的键一样好作为主键。
除非你有充分的理由这样做，否则我会坚持使用自动增量主键，它有一个唯一的索引，因此针对读取查找进行了优化。您仍然可以对复合键进行索引。有些人实际上更喜欢这种方式，因为可以说它使关系更加清晰并且更容易。通过在每个表上没有额外的列来更干净，但对于小型应用程序和数据集，我不担心这一点，只需使用自动增量选项。
I think the question you are asking is if an auto incrementing ID is as good a primary key as composite natural keys, or a key composed of 2 entities.
Unless you have a good reason to do so, I would stick to the autoincrement Primary Key, it has a unique index thus optimized for read lookups. You can do still do an index on composite keys. Some actually prefer it that way as it can be argued that it makes the relationships clearer & clenaer by not having the extra column on each table, but for small applications and datasets I don't worry about that and just use the autoincrement option.