一种实用的方法来存储几乎没有变化的“大量”数据？

从预先计算的查找表或其他方面考虑。在什么时候使用数据库而不是对应用程序中的值进行硬编码更有意义？这些值不会改变，并且很好地与维护开发人员隔离开来。100个值，1k，10k，100k？我想存储约40k值。现在，这是机器生成的switch语句（VS2010不满意）。

编辑：

如果有人好奇，这就是我的处理方法：我的数据可存储在两个100k元素的浮点数组中，所以我就是这样做的。大约花了20秒钟来生成数据，因此我做了一次，然后使用BinaryFormatter将其序列化为嵌入式资源。在应用程序启动时，解压缩数据大约需要5毫秒，并且比我正在替换的数据库实现（这些硬编码的值之前存储在其中）的性能要好45,000倍。

我的建议是将数据保留在文件表或数据库表中。如果速度不是问题，请在运行时查询文件或数据库（数据库更好）。如果内存不是问题，但是您希望提高速度，则在程序启动时将数据加载到内存中。在C＃中，您可以使用并排列，列出或（最佳选择）哈希表，并具有一种在运行时返回所需数据的方法（即getDataValue（string keyToValue））。

我建议您不要使用switch语句，因为这将很难维护并且会导致较大的exe占用空间。

哈希表，例如http://support.microsoft.com/kb/309357

就我个人而言，我可以存储任何硬编码到应用程序中的数据，直到不需要针对一个特定的部署或修补程序对其进行调整为止。

但是，使用C＃switch语句存储和访问数据是相当不好的做法，因为在紧密耦合数据存储和数据访问模型的同时，仅暗示一种方法访问方法（通过switch参数）。

我希望将数据存储在Hashtable或Dictionary中，并提供用于检索数据的单独类，并一次填充查找字典。

最近，我发现实施小型DSL来指定业务规则（SiteMap的流利接口或用于规则定义的税务计算器访谈问题检查“ calc”方法）非常方便，然后为查询这些规则提供了单独的对象。该技术将很好地适用于开关案例。

这种分解的好处之一是，您可以在数据上实现多个视图，而无需触摸定义该数据的XXXk行blob。

40k行切换语句有点可疑。我认为您仍然需要执行查询操作，对吗？您是否尝试过封装数据？然后使用LINQ对集合执行查询操作以测试性能。通过使用StopWatch之类的计时器运行单元测试来获得一些具体的时间。然后，如果您认为它可能会起作用。查看用户是否可以接受性能。

我有两次这样的要求。这些应用程序设计为独立的，无需数据库设置/访问。在这两种情况下，我都使用XML文件存储数据。在第一个2.0框架中，我使用了旧式XML解析调用来查找数据。对于较新的版本，在3.5 Framework上，我使用LINQ to XML查找所需的内容。在这两种情况下，对数据的访问都封装在类中。

这里的关键是要确保您的公共接口封装了您的实现-但这不是您的问题，也没有理由认为您没有。除此之外，这只是性能与悲伤的问题（性能差异可能不值得关注）。作为一个实用的解决方案，对于VS 2010问题，您始终可以将case语句分解为case语句的层次结构-顶层可以调用其他10种方法之一，例如，每种方法都具有4000个case语句。如果需要，您可以将10个文件中的每个文件放入自己的文件中。有点丑陋，但无论如何您都是在生成代码。

至于切换到数据库的数量-每当不使用数据库就成为问题。

您可以使用类似SQL Compact的东西。将数据放在表中，并将数据库文件保留在项目中。表比switch语句更适合该数量的数据。

我认为这里的关键词是“很难”

如果数据从不改变（例如，预先计算的数学值，颜色常数等），则可以确定，只要您可以控制大小，就将其保存在代码中。请注意，如果性能是一个问题，与其他选项相比，case / switch语句将非常慢。

如果数据几乎不变，例如电话区号，国家边界等，我可能会考虑以某种方式将数据保留在外部。特别是当它开始变得超过几十个值时。

如果将大量数据存储到应用程序中，则程序加载速度可能会变慢，并且可能会使代码面临风险，以防某些人可能会使用二进制文件或可执行文件。

另外，如果程序被多次编辑，谁知道呢，可能是由于错误地输入数字或由于change命令而导致输入错误而引起的错误。

将来可能有人要求对数据运行查询，例如有人可能要求对某列进行平均，在这种情况下，您将不得不更改应用程序并添加一种方法来计算用户出现的每个查询，然后执行所有步骤以将您的代码推广到生产环境。这真的不好。

分离数据和代码是一种好习惯，特别是在数据量较大的情况下。