单个首选项db表中的列太多了？

Question

我的应用程序基本上是由许多较小的应用程序构建的。每个应用程序都有自己的个人首选项，但它们共享相同的5个首选项，例如，应用程序是否显示在导航中，是否公开，是否应生成报告等。

所有这些常见首选项都需要通过Web应用程序中的任何页面来识别，因为导航是由它构建的。所以最初我将所有这些首选项放在一个表中。然而，随着应用程序数量的增加（现在10个，最终大约30个），列数最终将达到150-200左右。这些列中的大多数只是布尔值，但它仍然让我担心在一个表中有这么多列。另一方面，如果我将它们拆分成单独的表（每个应用程序的首选项），我每次需要查看首选项时都必须将它们全部加在一起，那么为什么不把它们全部放在一起呢？ / p>

在应用程序中，我可以将首选项分解为较小的对象，以便它们更易于使用，但从db角度来看，它们是单个实体。将它们放在一个巨大的桌子中，或者将它们拆分成较小的桌子，但是每次要求它们时强制进行多次连接会更好吗？

Answer 1

您使用的是哪个数据库引擎？通常，您会在数据库引擎中找到有关每个表的建议列数的建议。主要是行大小限制，这应该可以保证您的安全。

其他选项和建议包括：

1. 在整数中为每个配置键分配一个位，并使用逻辑“AND”操作仅显示您在给定时间点感兴趣的键。从DB读取单值，每次读取配置键一次快速逻辑操作。

2. 在内存中缓存首选项，减少到数据库服务器的往返次数，根据更改频率，您可能还必须在更新时清除每个首选项的缓存。

Answer 2

为什么不将列转换成行并使用如下内容：

这是维护设置值列表的典型方法。

APP_SETTING表包含设置的值。 SETTING表为您提供设置的上下文。

有一些方法可以扩展此功能，以添加信息，例如哪些设置适用于哪些应用程序，以及特定设置的可能值是否限制在特定列表中。

Answer 3

CommonPreferences和ApplicationPreferences肯定是有意义的，甚至可能在代码中分隔它们（两个查询而不是连接）。

之后每个应用程序的表格会更有意义。

另一种方式是走下乔尔布朗建议的路线。

第三个不是每个设置都有单独的列或行，而是将所有非常见的列填充到xml片段或来自首选项类的序列化。

您做出的决定围绕您的应用程序如何（或可以使用数据）。 如果您按下设置表的方法，将应用程序设置作为一行进行操作将会非常痛苦。沿着xml片段路由下来，查询跨应用程序的设置将比几个连接更痛苦。

没办法说出你应该从这里妥协。我想我先去看看CommonPreferences，看看之后我在哪里。