将大量静态数据放入代码而不是数据库？答案

【问题标题】：Having a big list of static data into code instead of a database?将大量静态数据放入代码而不是数据库？
【发布时间】：2013-07-03 15:03:31
【问题描述】：

我们目前有一个应用程序，它的数据库有点大，只有静态数据（只读）。

我们正在考虑以编译程序集的形式部署数据，模型对象构造填充集合。一个简单的例子：

public Model()
{
    this.Property1 = new List<AClass>();
    this.Property1.Add(new AClass(1,2));
    this.Property1.Add(new AClass(4,3));
    this.Property1.Add(new AClass(2,6));
}

人们主要担心的是他们从未见过有人这样做。您以前见过/使用过这种方法吗？

主要好处是您不再需要数据访问层，而且性能更快。

编辑：只读数据库当前由工具生成，因此代码也将由工具生成。

【问题讨论】：

是.Net，抱歉。但在这种情况下，语言可能并不重要。
嗯，确实如此。如果.net 有枚举，那么我会使用它
枚举不能有对象，只有值。我们会将整个数据模型存储在代码中。
@OP 我还是不明白为什么你必须这样做。如果数据库是不可能的，您是否考虑过 xml 文件？如果你使用xml，你可以将数据保存在那里，并轻松地将其序列化为你需要的对象。
我认为您的方法没有问题。如果您的工具将创建正确的语法，那么就去做吧。为什么要从 XML 文件中读取？为什么用户有机会入侵 XML 文件？

标签： .net database design-patterns architecture

【解决方案1】：

实际上它们是两种不同类型的列表：

数据列表/主数据

这是存储在数据库中的列表。通常列表很大，对代码逻辑的影响很小。例如 Country / Nation、字体列表等。这应该放在数据库中。如果对代码逻辑有影响（例如，如果国家是美国，则显示 Zip 框），配置应放在数据库中（如IsShowZip）。如果存储在应用程序/程序集中，这将没有任何好处。
应用列表

这是一个对代码逻辑影响很大的列表。通常它会显着影响业务流程（工作流程），或者具有特定的数据库模式。例如，支付类型信用卡/Paypal 等互联网商务。它将影响工作流程（如果来自贝宝可能需要等待验证）和输入（信用卡号/贝宝号）。如果存储在数据库中，这只有一个好处，因为它可以作为输入的约束（因此除了Paypal / Credit Card 中的Payment Type 之外，它不会是其他值）。但是，这取决于您的数据库访问方式，它可以在应用程序和数据库之间创建隐藏的依赖关系。

更新：

我错过了readonly database 部分。为了清楚起见，使用readonly database 的优缺点参考上面的第 1 点：

优点：

可以利用索引和查询优化。这适用于过滤数据
如果数据库是集中式的或使用服务器-客户端架构（可能不适用于本期），您可以修改数据库而无需更改每个客户端
不提供更新数据的代码修订历史记录。

缺点：

查询数据库时的开销（性能影响）。
额外的可避免依赖 -（YAGNI - 你不需要它）

【讨论】：

"如果存储在应用程序/程序集中，这没有任何好处"
我想知道它是什么类型的应用程序的真实用例吗？是使用数据库进行交易还是使用本地保存为文件进行存储？
正如我在问题中所说，数据绝对是只读的，所以根本没有交易，只是读取数据。
好吧，我误读了readonly 数据库。这是我第一次看到将数据库用于只读的应用程序。绝对可以去掉无用的依赖，除非列表中存储了大量数据（100k++），因为没有索引和初始化。

【解决方案2】：

我已经多次嵌入了应用程序内部数据库中的数据。没有 XML 文件，没有纯文本文件，没有数据库。

我通常只对我认为永远不会改变的少量数据这样做。

原因总是懒惰。我不想制作数据库、架构、编写数据访问代码等。在这种情况下，即使是制作 XML 文件对于少量数据来说也是太多工作。

如果所有数据都是只读的，我认为部署程序集而不是实际数据库是一个有趣的想法。正如你所说，它消除了一个非常可能有问题的依赖。

我能想到的唯一缺点是，当您进行查询时，程序集可能必须将大量数据加载到内存中。只要你有某种延迟加载功能，我认为它会很好用。

【讨论】：