我想处理两种全局配置设置：
- 用户可以更改的设置，例如是否发送某些事件的通知邮件。
- 与特定产品版本相关的设置，例如禁用免费版本中的功能，该功能仅在商业版本中可用。
存储这些设置的最佳方式是什么？数据库、配置文件、硬编码在源代码中，...？
对于这两种情况的数据库。您将对多个人/产品使用相同的结构，因此这是有意义的。它还允许您在不重新启动服务器的情况下进行更改。
我过去是这样处理的：
对于特定于用户的设置，我创建了一个 UserSettings 模型/表，它与用户具有一对一的关系。这样做的原因是，我涉及用户的大多数操作不需要加载这些设置，因此它们仅在我需要时才包含在来自数据库的用户加载中。
当我这样做时，我通常会对列名称进行分组，以便我可以编写根据名称动态创建的帮助程序。这意味着我不必修改视图来合并新设置，除非我添加具有不同命名方案的视图。
对于特定于产品的设置，这取决于您的操作方式。有几种方法可以解释你的问题。
我的理解是你想决定产品级别。用户可以覆盖或禁用用户的设置的哪些设置。并可能定义一些产品特定的设置。
我会使用一对多产品来设置关系。设置表会很简单（product_id、setting_name、setting_default_value、allow_user_change）
这有很多作用。它允许您为不同的产品提供可变的设置列表（非常适合您提供许多不同的产品而不是不同的服务访问级别的情况）。它还允许您定义用户可以/不能更改哪些设置，并为该产品类型提供值。可以从管理员视图更改该设置，而无需重新启动应用程序。它也与用户设置无关，如果用户没有在product_settings 中列出设置，则不会出现问题。
缺点是此表中将有多个常用设置。我会将每个产品具有不同值的设置移动到产品表中的字段。
您还必须编写验证，以确保用户不会更改其产品规定不能更改的设置。您还必须编写辅助方法来合并产品和用户端的设置。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
