我有一个当前在 Windows Azure 上运行的自定义 ASP.NET 4 Web 应用程序。有一大组数据（数千个条目，每个条目都有一个“关键”值和一个 1-3 句描述）变化非常少（过去 25 年中两次），我需要能够将其显示为应用程序（在下拉控件、网格等中）。
我认为将数据存储在数据库中是没有意义的，因为它几乎不需要更改，并且在每次重新加载页面时都会发送几个句子。我正在评估通过 LINQ-to-XML 访问的 XML 文件或资源文件。可能需要对字符串进行本地化（我认为这会转向资源文件），但是由于涉及到业务逻辑，我有时还需要根据各种属性（特定的“键”值或其他属性，我相信使用 LINQ 会更容易）。
有人对在这里使用什么有任何想法吗？可能还有其他选择，我当然也会招待这些……谢谢！
【问题讨论】：
标签： c# asp.net azure linq-to-xml
我不会仅仅因为数据没有改变就排除数据库 - 假设 Azure 允许，像 SQL CE 或 SQLite 这样的轻量级数据库可能工作得很好。
也就是说，您提到的其他因素（从键映射到短字符串、本地化潜力、显示为 UI 的一部分）使资源文件看起来是最好的选择。
基于资源字符串运行查询似乎有点奇怪，但是 - 我相信这是可能的（请参阅 this question），但是运行任何类型的查询，如“给我所有包含 'foo' 的资源字符串”都会打破这一刻你本地化了任何东西。
【讨论】：
您可以使用 Windows Azure 表。它快速可靠，并且部分支持 LINQ。 Here 是可用于 Azure 上的 LINQ 的查询运算符。此外，如果您需要本地化，那么您可以使用与 PartitionKey 相同的表和区域性。此外，在扩大或缩小规模时，您不会有任何问题，因为存储对所有节点都是通用的。
Windows Azure 表的一个选项可能是带有通过 LINQ-to-XML 访问的 XML 文件的专用容器。但我更喜欢第一个变体。
【讨论】：
为什么不在资源中存储 XML 文件？这将使您同时获得以下好处：简单打包、快速访问、LINQ 和本地化。
但是，如果您已经在那里托管了数据库，我不排除 SQL Azure。访问它的速度很快，并且您无需支付任何额外费用（前提是您已经部署了数据库），无论您连接到它的频率如何。 ATS 稍微慢一些（尽管更具可扩展性），但只要您去 ATS 做几乎任何事情，它都会花费您一分钱。
总的来说，有十几种方法可以做到这一点，而且都可以。如果性能是您最关心的问题，那么通过资源将其嵌入到应用程序中可能是最好的方法。如果灵活性和部署是您最关心的问题，SQL Azure 可能是最好的方法。
【讨论】：