【问题标题】:Nicely managed lookup tables管理良好的查找表
【发布时间】:2015-04-17 06:41:45
【问题描述】:

我们有一个people 表,每个person 都有一个gendergender_id 定义到genders 表,

| people    |
|-----------|
| id        |
| name      |
| gender_id |

| genders |
|---------|
| id      |
| name    |

现在,我们希望允许人们使用漂亮的表单构建器自己创建表单。我们要添加的元素之一是选择list 和用户定义的options

| lists |
|-------|
| id    |
| name  |

| list_options |
|--------------|
| id           |
| list_id      |
| label        |
| value        |

但是,他们不能将genders 用作下拉列表,因为它位于不同的表中。他们可以使用与genders 相同的选项创建一个新列表,但这不是很好,如果添加了新性别,他们需要在多个位置添加它。

因此,我们希望将性别选项移动到用户可以随意编辑的列表中,并且在创建新人时也会反映出来。

genders 移动到listlist_options 同时在people 表中仍有gender_id(或类似)列的最佳方法是什么?到目前为止我的想法包括:

  1. 创建一个具有已知 id 的“神奇”列表,并始终假定其中包含性别选项。

    • 不太喜欢这个,因为这听起来像是在使用“魔术”数字。代码需要在系统级选择框及其含义之间建立某种“映射”
  2. 不要使用“魔法”列表,而是将其移到用户可以选择的选项中,以便他们可以选择包含性别的列表。

    • 这并没有太大的不同,但不会对 ID 进行硬编码。不过,这需要更多的工作来查看数据库表
  3. lists 表上有某种列,将其标记为从另一个表中提取其选项。
    • 可能需要更多(和更复杂)的代码才能完成这项工作。
  4. 某种多态表,我不确定它会如何工作,但我只是想了一下,想在忘记之前写下来。
    • 不知道这会如何工作,因为我只是有这个想法

【问题讨论】:

  • 1) 文字描述不够精确,无法理解。请清理干净,以便我们为您提供帮助。使用技术术语。 2) 陈述一个总体目标,即你想要达到的目标。全球性别列表加上每个人的性别列表?在那种情况下,谁会使用全局列表,它的用途是什么?
  • 您希望在最终的genders 表中存在多少行?
  • @wildplasser genders 可能只有约 3 个选项(除非用户想添加更多)。但解决方案适用于任何可能有已知数量的可能选择(性别、年龄范围、国家)的领域。理想情况下,这些都将存储在 1 个表中,该表可由系统定义的表(例如人员)以及用户通过系统生成的表单使用,允许我们在列表中添加 1 个额外的性别/县,并且它在任何地方都可见列表正在使用中。

标签: postgresql database-design


【解决方案1】:

最简单的解决方案是将您的list_options 表更改为视图。如果您有多个表,则需要一个下拉列表以从该表中提取,只需将 UNION 结果集放在一起即可。

SELECT 
   (your list id here) -- make this a part primary key
   id, -- and this a part primary key
   Name,
FROM dbo.Genders 

UNION 

SELECT 
   (your list id here) -- make this a part primary key
   id, -- and this a part primary key
   Name,
FROM dbo.SomeOtherTable

这样,只要数据发生变化,它就会自动更新。现在您将要对此进行测试,就好像它变大可能会变慢一样,您可以通过仅在应用程序中提取所有这些信息一次来解决此问题(或者说将其缓存 30 分钟,然后刷新以防万一) .

您的第二个选择是创建一个表list_options,然后创建一个过程(等),它会遍历所有其他查找表并提取信息来编译它。这会提高应用程序的性能,但需要您保持所有同步。处理这个问题的最简单方法是创建一系列触发器,当查找表中的某些内容发生更改时,这些触发器将重建部分(或整个)list_options 表。在这一个中,我建议不要创建自动生成的主键,而是使用复合键,就像我在视图中提到的那样。由于这将被重建​​,id 会改变,所以最好不要让任何东西认为这个值是稳定的。对于复合 (list_id,lookup_Id),无论该行插入表中多少次,它都应该始终相同。

【讨论】:

    猜你喜欢
    • 2013-12-05
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-07-26
    • 1970-01-01
    • 2013-01-08
    • 1970-01-01
    相关资源
    最近更新 更多