Question

我相信我们所有人都以这种或那种形式看到了这种设计要求。

软件需要为用户提供多种问题/设置的答案选项。这些选项位于数据库中。在一个大项目中，许多此类问题很容易超过50个。

现在

是否可以拥有50多张具有相同设计的桌子？

CREATE TABLE [dbo].[Setting1]
(
    [ID] uniqueidentifier NOT NULL,
    [Name] varchar(max) NOT NULL
)

CREATE TABLE [dbo].[Setting2]
(
    [ID] uniqueidentifier NOT NULL,
    [Name] varchar(max) NOT NULL
)

等

然后将这些表通过外键链接，如下所示：

CREATE TABLE [dbo].[UserSettings]
(
    [UserID] uniqueidentifier NOT NULL,
    [Setting1ID] uniqueidentifier NOT NULL,
    [Setting2ID] uniqueidentifier NOT NULL
)

或者创建一个“主”选项表是否更明智？

CREATE TABLE [dbo].[Setting]
(
    [ID] uniqueidentifier NOT NULL,
    [Name] varchar(max) NOT NULL
    [SettingCode] int NOT NULL
)

除了必须在第一种情况下将具有相似结构的表相乘并且在另一种情况下没有完整性约束之外，有哪些优点和缺点？

Answer 1

我会选择最后一个选项，即查找表，但命名方案略有不同......

“设置”是存储设置的各种名称/描述的位置，每个名称/描述都有一个主键。然后，将用户绑定到另一个表中的设置。无限制设置，无限制的用户/设置关系。

设置

SettingID - 主键
SettingName

UserSetting

用户名
SettingID

Answer 2

嗯，我认为为X设置创建X表是一个非常糟糕的解决方案。

我喜欢这样解决这个问题：

Users(UserID, ...)
Settings(SettingID, SettingFieldName, ...)
UserSettings(UserdID, SettingID, Value)

但我不知道这在理论上是否是正确的解决方案。我通常这样做，我认为这很好。

Answer 3

这样的问题总是会有主观的答案，但就个人而言，我可能会做一些横向的事情，比如将它们存储在XML文件中并将其保存到与用户链接的数据库中（使用BLOB类型）字段，所以你不要碰到任何varchar长度限制）。

通过这种方式，您可以将其加载，将其反序列化为配置对象，并且可以对编程设置进行良好的编程访问，而无需每次都要编写大量SQL或者在每次要检查时都使用DB。

数据库设计：多个“选项”表与单个表

3 个答案:

设置

UserSetting