在数据库中存储资源 ID？答案

【问题标题】：Store resource IDs in database?在数据库中存储资源 ID？
【发布时间】：2020-06-20 11:35:44
【问题描述】：

想象一个包含不同食物项目的数据库表，例如牛奶。我希望翻译产品名称。我想将翻译与表格分开，并改用字符串资源。所以我的表格可能是这样的：

ID product_name stringRes
1  milk         ???

在我的应用程序中，我有 @string/milk 用于翻译。我将如何在数据库中存储对@string/milk 的引用？ R.id.milk 在不同的编译中可能并不总是相同的 ID 值，所以把 ?表中的 R.id.milk` 不是个好主意？

【问题讨论】：

【解决方案1】：

将您自己的标识符存储在数据库中，并在您的应用中使用代码将该标识符映射到其文本表示。今天，该文本表示可能来自资源。下个月，它可能来自您下载的翻译。一个月后，它可能来自用户提供的标签。

【讨论】：

好吧，但是如果我有 1000 个产品，我需要一个大的 when 语句或一个大的 hashset 左右。
@stefan.at.wpf：很有可能。没有什么能阻止您将标识符作为资源名称的字符串表示形式（例如，milk），然后在 Resources 上使用 getIdentifier() 来查找翻译。但是，如果/当需要时，您仍然可以灵活地将文本表示查找策略更改为其他策略。
谢谢，我喜欢getIdentifier() 的想法。知道与将翻译存储在第二个表中相比性能如何（如 androCoder 的答案）吗？考虑返回 100 行的查询。
@stefan.at.wpf: getIdentifier() 使用反射，所以这不是在紧密循环中要做的事情，如果相当方便，维护缓存会很好。如果你想走那条路，在数据库中有翻译很好，但你的问题表明你现在想使用字符串资源，所以我没有真正考虑过。数据库连接可能比内存中的反射查找慢，只是因为它执行更多的磁盘 I/O，但这只是有根据的猜测，而不是实际测试的结果。

【解决方案2】：

你是对的，资源 ID 并不总是相同的。因此，通过资源 ID 引用 db 列并不是一个好主意。然后，对于翻译，理想情况下，如果您有动态产品/项目，则永远不应该预先打包翻译。因此，为了引用回数据库，理想情况下，您应该有一个不同的表，您可以在其中映射翻译，如下所示：

id | product_fk | translated_name | translated_source_iso

【讨论】：