2

我在 asp.net mvc 中做一个 web 应用程序。现在我正在处理大量文本信息，例如帮助文本、eula、隐私政策等。我意识到我不确定存储这些文本的最佳方式是什么。1.直接在aspx页面中 2.在文本文件中然后通过ViewData[]加载文本到aspx文件中 3.在我的sql数据库中

如果使用选项 3，我将如何设计数据库，例如 eula = table x，privacypolicy=table y？

我想我只需要一些关于上述选项的优缺点的说明。

4

3 回答 3

1

  1. 直接在 ASPX 页面中 -> 不！. 您必须为每次更改重新编译和发布。这太可怕了。

  2. 如果此数据不经常更改，文本文件将使您能够使用更轻松的缓存，但文本文件在许多不同方面都很糟糕。最后，您将拥有数十/数百个文本文件，并且不知道什么引用了什么。（因此，无论如何您都必须保留一个带有指向文件的指针的数据库表）。

  3. 这导致了这里唯一可能的解决方案，将所有内容保存在数据库中。您还可以使用缓存，甚至，如果不是很多，将所有内容存储在 Application 变量中，该变量将在每次 iisreset 时重新索引。

  4. 对此没有太多经验，但也许使用 LocalResources 将是一个好主意。这将使您（如果需要）进一步支持多语言。

于 2010-03-21T06:00:57.367 回答
0

如果您的应用程序非常小，将文本保留在页面中可能没问题，但是一旦应用程序及其背后的团队发展壮大，这可能会成为一个问题。当文本与您的代码混合时，诸如将文本交给专业作家、翻译、由律师校对之类的事情会很麻烦

对于大多数应用程序来说，将文本存储在简单的文本文件中应该就可以了。这里唯一的问题可能是应用程序的一部分实际更改了文本。在这些情况下，将它们存储在数据库中可能是个好主意。

大多数时候，在数据库中存储文本是多余的。数据库主要提供结构化数据上的 ACID 事务和索引的好处。但是，如果您的文本没有通过应用程序更改，那么 ACID 属性就没有多大用处。如果这些只是要在应用程序中使用的文本片段，您将能够直接指定片段/文件的名称，因此按数据进行的索引也没有任何好处。但是数据库也有成本：大量数据可能会使缓存对于真正属于数据库的数据效率低下。事务处理会导致性能下降。因此，如果您不必这样做，则不应使用数据库。

于 2010-03-21T06:17:38.707 回答
0

如果这些文件已经存在，并且预计稍后会更改，那么通过文件名从数据库中引用它们可能是一个好主意。

另一方面，如果您希望文本本身存在于数据库中，那么拥有一个“页面内容”表可以很好地处理每个表示单独文本的元组：一个属性是文本的标识符，一个属性是全文本身。

无论您选择哪种方式，我都建议您遵循DRY 原则：选择一个易于管理的规范位置，并在整个应用程序中坚持这一点。

于 2010-03-21T06:19:32.153 回答