代码之家 › 专栏 › 技术社区 › colithium

如何管理用户可修改的查找表

lookup-tables sql-server c#

1

colithium · 技术社区 · 16 年前

我们的数据库中有一个表,它的作用非常类似于标准查找表(id,description)。但是,这个特定的不是静态的,客户机希望能够动态地添加条目。一些预填充的条目是“特殊的”,因为将有代码检查它们(各种业务规则)。

通常,我创建表时不会自动递增i d,这样就可以安全地知道镜像表中条目的枚举总是匹配的。然后只需要检查这个对象的id是否与我要检查的枚举值匹配。

我可以尝试同样的方法,使用不自动递增的id和只覆盖动态添加的条目的枚举。当用户添加一个新条目时,我们很快就会遇到下一个id的问题。基本上在代码中重新实现数据库的自动增量特性。

如果我切换到使用标识列,则会出现与枚举值不同步的整个问题。

当然,我总是可以匹配文本的“description”属性,但这显然是不好的。

有什么好办法处理这种事情吗? This question 不是真的给我答案。

5 回复 | 直到 16 年前

1

5

Cade Roux 16 年前

除了这里给出的解决方案之外,始终有可能对所有查找外键使用完全无意义的标识,但也有一个列将查找链接到业务逻辑的枚举值:

lkpTable
PK Identity
Description
FK LogicEnum NULL

lkpLogic
PK EnumValue
LogicParamColumns

在这种情况下,逻辑是由用户提供的,而不是由用户更改的。新的查找甚至可以路由到使用任何现有的逻辑规则-因此您可以使用不同的设置,这些设置的行为与现有的硬编码业务规则相同,但显示方式不同。

2

3

Joshua Cauble 16 年前

为什么不用两张桌子呢?一个表保存您为其编码的枚举值。另一个处理所有用户可配置的项。

除非是这样,否则您也将基于客户端输入的值创建新的枚举。如果是这样的话,为什么不将主键迁移到guid,并使用带有静态字符串成员的静态类(类似于虚拟枚举)。那么您就不必担心惟一性了,因为guid很难复制,除非您是故意这样做的。

我们使用guid psuedo enum方法,因为我们必须维护同一数据库的多个副本,它们很容易失去同步。guid在这方面有帮助。

3

2

Mitch Wheat 16 年前

1)为客户端分配一个大于应用程序所需值的范围,例如1000000。添加一个触发器以强制只允许该范围以上的新值。

2)使用auto increment并从数据库的本地副本生成枚举。

4

1

Josh 16 年前

根据米奇的回答:

您可以在identity列中植入较大的值,并且在用预定的标识填充表时,可以将identity insert设置为on。

CREATE TABLE dbo.Table_1
(
    ID int NOT NULL IDENTITY (1000000, 1),
    Label nvarchar(50) NOT NULL
)  ON [PRIMARY]
GO

SET IDENTITY_INSERT dbo.Table_1 ON
GO

INSERT INTO dbo.Table_1(ID, Label) VALUES (1, 'First');
INSERT INTO dbo.Table_1(ID, Label) VALUES (2, 'Second');

5

1

Mark Gibaud 16 年前

老实说,这听起来像是一个服务于两个不同需求的问题。

我将它分为两个表,类似于applicationlookups和customlookups,然后从代码和db的角度对它们进行不同的处理是很直观的。