我在 asp.net mvc 中做一个 web 应用程序。现在我正在处理大量文本信息，例如帮助文本、eula、隐私政策等。我意识到我不确定存储这些文本的最佳方式是什么。 1.直接在aspx页面 2. 在文本文件中，然后通过 ViewData[] 将文本加载到 aspx 文件中 3.在我的sql数据库中
如果使用选项 3，我将如何设计数据库，例如eula = 表 x，隐私策略 = 表 y？
我想我只需要一些关于上述选项的优缺点的说明。
【问题讨论】：
标签： database text administration
直接在 ASPX 页面中 -> 不！ .您必须为每次更改重新编译和发布。太可怕了。
文本文件将使您能够使用更轻松的缓存，以防此数据不经常更改，但文本文件在许多不同方面都很糟糕。最后，您将拥有数十/数百个文本文件，并且不知道什么引用了什么。 （因此，无论如何您都必须保留一个带有指向文件的指针的数据库表）。
这导致了这里唯一可能的解决方案，将所有内容保存在数据库中。您还可以使用缓存，如果不是很多，甚至可以将所有内容存储在应用程序变量中，该变量将在每次 iisreset 时重新索引。
对此没有太多经验，但使用 LocalResources 可能是个好主意。这将使您（如果需要）进一步支持多种语言。
【讨论】：
如果您的应用程序非常小，将文本保留在页面中可能没问题，但是一旦应用程序及其背后的团队成长，这可能会成为一个问题。当文本与您的代码混合时，诸如将文本交给专业作家、翻译、律师校对之类的事情会很麻烦
将文本存储在简单的文本文件中对于大多数应用程序来说应该没问题。这里唯一的问题可能是应用程序的一部分实际更改了文本。在这些情况下，将它们存储在数据库中可能是个好主意。
在数据库中存储文本大部分时间都是多余的。数据库主要提供结构化数据上的 ACID 事务和索引的好处。但是，如果您的文本没有通过应用程序更改，那么 ACID 属性就没有多大用处。如果这些只是要在应用程序中使用的文本片段，您将能够直接指定片段/文件的名称，因此按数据进行的索引也没有任何好处。但是数据库也有成本：大量数据可能会使缓存对于真正属于数据库的数据效率低下。事务处理会导致性能下降。因此，如果您不必这样做，则不应使用数据库。
【讨论】：
如果这些文件已经存在，并且预计以后会更改，那么最好通过文件名从数据库中引用它们。
另一方面，如果您希望文本本身存在于数据库中，那么拥有一个“页面内容”表可以很好地处理每个表示单独文本的元组：一个属性是文本的标识符，一个属性是全文本身。
无论您选择哪种方式，我都建议您关注DRY principle：选择一个易于管理的规范位置，并在整个应用程序中坚持使用该位置。
【讨论】：