我遇到过很多情况，我只想要一个包含大约500到1000个字符串的简单数据库，每个字符串大约有100个字符而不需要更新，而且我最终使用数据库。 突然之间，我想知道我是否可以使用字符串/文本文件资源。有人曾尝试过这个吗？我假设这应该比普通的物理数据库更快，但我想知道内存含义/性能成本是什么样的。有什么建议？感谢。
答案 0 :(得分：1)
这取决于字符串的使用方式。如果它们永远不会改变并且永远不会暴露给用户，那么在代码本身中将它们设置为常量就足够了。这里的记忆负担很小。
如果这些是用户将看到但不会被应用程序更新的标签或消息，则字符串表是合适的。这也允许您将来本地化您的应用程序。这里所需的内存至少与字符串常量一样多，加上资源框架内置的管道的一些开销。
如果这些字符串将由应用程序（或其用户）更新，则需要在代码中为此设置条件，方法是在外部存储字符串 - 无论是在数据库中，还是在您（de）的XML文件中序列化，纯文本文件或其他方式。这里谈论内存负担比较困难，因为你有很多不同的实现选择。
关于这些字符串的内存负担：你已经声明你（最多）有大约1000个字符串。让我们慷慨，称之为1500，以防万一。每个字符串长度约为100个字符。 .NET中的字符是UTF-16，这意味着每个字符占用两个字节。有了这些假设，我们可以说你的字符串将占用至少300,000个字节 - 大约300 KB，允许字符串对象本身占用的内存。鉴于您正在使用.NET框架，这种内存通常不值得讨论。
编辑：性能影响
考虑一下你的CPU为上述每项工作做了多少工作。
对于常量，它基本上是加载一个指针。
对于文件，您现在正在讨论加载文件名，指示操作系统打开文件，将其内容读入内存，处理内容以及查找所需的字符串。那是更多的工作！
现在想象一下简单地连接到数据库可能涉及的内容，更不用说从中获取信息了。
你永远不会因速度而击败常数。数据库肯定会慢一个数量级，除非你真的需要它们的功能，否则不应该考虑它们。使用文件比使用数据库要快得多，但仍然比使用常量更慢，更容易出错。