我有一个应用程序，它基本上是由许多较小的应用程序构建的。每个应用程序都有自己的个人偏好，但它们都共享相同的 5 个偏好，例如，应用程序是否显示在导航中，是否公开，是否应生成报告等。
Web 应用程序中的任何页面都需要知道所有这些常见的偏好，因为导航是由它构建的。所以最初我将所有这些偏好放在一个表中。然而，随着应用程序数量的增长（现在 10 个，最终大约 30 个），列数最终将达到 150-200 个左右。这些列中的大多数只是布尔值，但它仍然让我担心一张表中有这么多列。另一方面，如果我要将它们分成单独的表（每个应用程序的首选项），每次我需要查看首选项时我都必须将它们全部连接在一起，那么为什么不把它们全部放在一起呢？
在应用程序中，我可以将首选项分解为更小的对象，以便它们更易于使用，但从数据库的角度来看，它们是一个单一的实体。是把它们放在一张大桌子上更好，还是把它们分成更小的桌子，但每次请求时都强制进行许多连接？
您使用的是哪个数据库引擎？通常，您会在数据库引擎中找到有关每个表的推荐列数的一些建议。主要是行大小限制，这应该可以保证您的安全。
其他选项和建议包括：
以整数形式为每个配置键分配一个位，并使用逻辑“与”运算仅显示在给定时间点您感兴趣的键。从 DB 读取单个值，每次读取配置键时进行一次快速逻辑操作。
在内存中缓存首选项，减少到数据库服务器的往返次数，根据更改频率，您可能还必须在更新每个首选项时清除它的缓存。
为什么不将列转换为行并使用以下内容：
这是维护设置值列表的典型方法。
该APP_SETTING表包含设置的值。该SETTING表为您提供了设置的上下文。
有一些方法可以扩展它以添加信息，例如哪些设置适用于哪些应用程序，以及特定设置的可能值是否限制在特定列表中。
那么 CommonPreferences 和 ApplicationPreferences 肯定会有意义，甚至可能在代码中将它们隔离（两个查询而不是一个连接）。
之后，每个应用程序的表将更有意义。
另一种方法是沿着 Joel Brown 建议的路线前进。
第三种方法不是每个设置都有单独的列或行，而是将所有不常见的列填充到 xml 片段中或从首选项类中序列化。
您做出的决定取决于您的应用程序如何（或可以使用数据）。如果您按照设置表的方式获取应用程序设置作为一行将是非常痛苦的。沿着 xml 片段路由和跨应用程序查询设置将比几个连接更痛苦。
没有办法说你应该从这里妥协。我想我会先去 CommonPreferences，然后看看我在哪里。