应用程序中的键值数据
管理其他表中使用的键值数据的最佳方法是什么？
每个新类型的表还是一个包含区分不同类型的附加属性的表？
What is the best way to manage key-value data which is used in other tables.
Every table for new type or one table which contains additional attribute which distinguish between different types?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
每种类型一个表 - 请参阅 OTLT 和 EAV ：所有初学者都会犯的两个重大设计错误，因为我对一张表的所有查找的看法。
A table per type - see OTLT and EAV: the two big design mistakes all beginners make for my views on one table for all lookups.
我不会不同意托尼·安德鲁斯的观点（并且我赞成他的答案），但我想说，与大多数数据库设计问题一样，答案是“视情况而定”。
在这种情况下，这取决于您在这里讨论的值类型。如果系统的键值部分非常通用，并且可能用于保存几乎所有内容，尤其是重要的业务事实，那么托尼针对 OTLT 的警告就值得接受。
另一方面，如果您正在查看相对受限的键和值域，即可能出现在各种主表或事务表中的状态代码列表，那么 OTLT 的危险并不严重。事实上，当您的系统需要国际化并且您的键根据当前语言选择为您提供不同的值时，OTLT 对于这些类型的代码查找很有帮助。请记住，这些可接受的场景并不是真正的“OTLT”，因为您的多用途查找表不是所有用途。将范围限制为特定代码查找就可以了。尝试用 EAV 和 OTLT 替换 DMBS 是一个坏主意，原因托尼在他的博客中描述。
I wouldn't disagree with Tony Andrews (and I upvoted his answer) but I would say that as with most database design questions, the answer is "it depends".
In this case, it depends on what type of values you are talking about here. If the key-value portion of your system is very generic and could potentially be used to hold almost anything, especially important business facts, then Tony's warnings against OTLT are very well taken.
If, on the other hand, you are looking at a relatively restricted domain of keys and values, i.e. a list of status codes that might appear in a variety of master tables or transaction tables, then the dangers of OTLT are not severe. In fact, OTLT can be helpful for these types of code lookups when your system requires internationalization and your keys give you different values depending on the current language selection. Keep in mind that these acceptable scenarios are not truly "OTLT", insofar as you're multiple purpose lookup table is not all purpose. Limiting the scope to specific code lookups is fine. Trying to replace your DMBS with EAV and OTLT is a bad idea for the reasons Tony described in his blog.