Question

我有一个带有许多“选择列表”实体的应用程序（用于填充单选下拉选择框）。需要从数据库中提取这些实体。如何在数据库中保留这些实体？我应该为每个选择列表创建一个新表吗？有更好的解决方案吗？

Answer 1

过去我创建了一个包含列表名称和可接受值的表，然后查询它以显示列表。我还包含一个基础值，因此您可以返回列表的显示值，以及可能更加丑陋的绑定值（例如，规范化数据的小int）

CREATE TABLE PickList(
    ListName varchar(15),
    Value varchar(15),
    Display varchar(15),
    Primary Key (ListName, Display)
)

如果要手动定义显示顺序，可以添加sortOrder字段。

Answer 2

嗯，你可以这样做：

PickListContent

IdList  IdPick  Text  
1       1       Apples
1       2       Oranges
1       3       Pears
2       1       Dogs
2       2       Cats

和可选..

PickList

Id    Description
1     Fruit
2     Pets

Answer 3

这取决于各种各样的事情：

如果它们是不可变的和非关系的（想想“美国国家的名字”），可以说它们根本不应该在数据库中：毕竟它们只是简单地格式化（比如分配了两个字符代码）。这有一个额外的好处，你不需要往返数据库来获取永远不会改变的东西，以便填充组合框。

然后，您可以在代码中使用枚举，并在数据库中使用约束。如果是本地化显示，那么您需要为每种文化设置不同的格式，然后您可以使用XML文件或其他资源来存储文字。
如果它们是关系型的（想想“状态 - 资本”）我不是很有信心......但最近我一直在使用XML文件，数据库约束和javascript来填充。它工作得很好，在DB上也很容易。
如果它们不是只读但很少更改（即通常不能由最终用户更改，只能由某个编辑器或每日批处理更改），那么我仍然会考虑不将它们存储在数据库中的机会......这取决于具体情况。
在其他情况下，存储在DB中的方式（想想StackOverflow的标签......它们是“查找”但也可以由最终用户更改） - 如果需要可能还有一些缓存。它需要一些小心锁定，但它可以很好地工作。

Answer 4

我发现创建单个表是最好的主意。

我一直在尝试创建一个包含所有选择列表的主表，然后根据类型过滤掉。虽然它有效，但它总是让人头疼。例如，你可能会发现你认为是一个简单的选择列表的东西不是那么简单并需要一个额外的字段，你现在将这些数据拆分成一个附加表还是扩展你的主列表？

从数据库的角度来看，拥有单独的表可以更轻松地管理关系完整性，并且当您不使用应用程序时，可以更轻松地解释数据库中的数据

Answer 5

我们已经按照每个选择列表的新表的模式。例如：

表FRUIT具有列ID，NAME和DESCRIPTION 价值观可能包括：
15000，Apple，Red fruit
15001，香蕉，黄色和美味
......

如果您需要在另一个表中引用FRUIT，您可以调用FRUIT_ID列并引用FRUIT表中该行的ID值。

Answer 6

为列表创建一个表，为list_options创建一个表。

 # Put in the name of the list
 insert into lists (id, name) values (1, "Country in North America");

 # Put in the values of the list
 insert into list_options (id, list_id, value_text) values
   (1, 1, "Canada"),
   (2, 1, "United States of America"),
   (3, 1, "Mexico");

Answer 7

两张桌子。如果你试图将所有东西塞进一个表中，那么你就会破坏规范化（如果你关心它）。以下是示例：

LIST
---------------
LIST_ID (PK)
NAME
DESCR


LIST_OPTION
----------------------------
LIST_OPTION_ID (PK)
LIST_ID (FK)
OPTION_NAME
OPTION_VALUE
MANUAL_SORT

列表仅描述了一个选择列表。 list_选项表描述给定列表中的每个选项。因此，您的查询将始终知道您要填充的选择列表（通过名称或ID），您加入list_选项表以提取所有选项。如果您要强制执行除名称或值以外的特定订单，则会出现manual_sort列。（顺便说一句，每当我尝试发布与下划线连接的单词“list”和“option”时，预览窗口就会变得有些古怪。这就是我在那里放置空间的原因。）

查询看起来像：

select
  b.option_name,
  b.option_value
from
  list a,
  list_option b
where
  a.name="States"
and
  a.list_id = b.list_id
order by
  b.manual_sort asc

如果您认为您将在where子句中使用它，您还需要在list.name上创建索引。 pk和fk列通常会自动编入索引。

请不要为每个选择列表创建一个新表，除非您输入将在应用程序的其他地方使用的“关系相关”数据。您将完全避开数据库提供的关系功能。最好将选择列表静态定义为基类或属性文件中的常量（您可以选择如何为名称 - 值对建模）。

Answer 8

首先回答第二个问题：是的，在大多数情况下，我会为每个选择列表创建一个单独的表。特别是如果它们用于完全不同类型的值（例如州和城市）。我使用的一般表格格式如下：

id - identity or UUID field (I actually call the field xxx_id where xxx is the name of the table).  
name - display name of the item  
display_order - small int of order to display.  Default this value to something greater than 1

如果你想要，你可以添加一个单独的'value'字段，但我通常只使用id字段作为选择框值。

我通常使用首先按显示顺序排序的选项，然后按名称排序，这样您就可以按字母顺序排序，同时仍然添加自己的异常。例如，假设您有一个国家/地区列表，您希望按照字母顺序排列美国，然后将美国排在第二位，加拿大排在第二位，您可以说"SELECT id, name FROM theTable ORDER BY display_order, name" and set the display_order value for the US as 1, Canada as 2 and all other countries as 9.

您可以获得更好的感觉，例如拥有一个“活动”标志，以便您可以激活或停用选项，或设置'x_type'字段，以便您可以将选项，描述列分组以便在工具提示中使用等。但基本表适用于大多数情况。

Answer 9

根据您的需要，您可以拥有一个选项表，其中包含列表标识符和列表值作为主键。

select optionDesc from Options where 'MyList' = optionList

然后你可以用一个订单栏等来扩展它。如果你有一个ID字段，那就是你可以引用你的答案的方法......如果它经常变化，你只需将答案值复制到答案表。

Answer 10

如果您不介意使用字符串作为实际值，您可以简单地为每个列表赋予不同的list_id值，并使用以下内容填充单个表：

item_id：int

list_id：int

text：varchar（50）

除非每个列表项需要多个内容，否则似乎最简单

Answer 11

我们实际上创建了实体来处理简单选择列表。我们创建了一个Lookup表，其中包含所有可用的选择列表，以及一个LookupValue表，其中包含Lookup的所有名称/值记录。

当我们需要简单时，对我们很有用。

Answer 12

我以两种不同的方式做到了这一点： 1）每个列表的唯一表 2）列表的主表，其中包含特定的视图

我倾向于选择初始选项，因为它使更新列表更容易（至少在我看来）。

Answer 13

尝试转动问题。为什么需要从数据库中提取它？是不是您的模型的数据部分，但您真的想要将其保留在数据库中？您可以使用像LINq2sql或nhibernate这样的OR映射器（假设您在.net世界中）或者根据您可以将它们手动存储在每个表中的数据 - 有些情况下将它全部放入其中是很有意义的同一张桌子，但只有当你觉得它真的很有道理时才考虑这个。通常将不同的数据放在不同的表中会使（稍后）了解正在发生的事情变得更加容易。

Answer 14

这里有几种方法。

1）每个选择列表创建一个表。每个表都有ID和Name列;用户选择的值将根据所选项目的ID进行存储。

2）创建一个包含所有选择列表的表。专栏：ID;列表ID（或列表类型）;名称。当您需要填充列表时，请执行查询“选择列表ID = ...”的所有项目。这种方法的优点：真的很容易添加选择列表;缺点：编写逐个样式的查询要困难一些（例如，给我选择值X的记录数。“

我个人更喜欢选项1，对我来说似乎“更清洁”。

Answer 15

您可以为每个（我的首选）使用单独的表，也可以使用具有类型列的常见选项列表表，您可以使用该表从应用程序中进行过滤。一般来说，我不确定一个人会比另一个人有多大的好处。

如果你有超过25个左右，从组织上来说，使用单表解决方案可能会更容易，因此你没有几个选项列表使你的数据库混乱。

如果您的列表很长，那么对于每个表使用单独的表，性能可能会更好，但如果您的索引设置正确，这可能是微不足道的。

我喜欢使用单独的表格，以便如果选项列表中的某些内容发生变化 - 例如需要和附加属性 - 您可以更改该选项列表表，而对其余模式的影响很小。在单表解决方案中，您要么必须对选项列表数据进行非规范化，将该选项列表拉出到单独的表中，等等。在单独的表解决方案中，约束也更容易实施。

Answer 16

这对我们很有帮助：

SQL> desc aux_values;
 Name                                      Type
 ----------------------------------------- ------------
 VARIABLE_ID                               VARCHAR2(20)
 VALUE_SEQ                                 NUMBER
 DESCRIPTION                               VARCHAR2(80)
 INTEGER_VALUE                             NUMBER
 CHAR_VALUE                                VARCHAR2(40)
 FLOAT_VALUE                               FLOAT(126)
 ACTIVE_FLAG                               VARCHAR2(1)

“变量ID”表示数据类型，例如“客户状态”或“缺陷代码”或您需要的任何数据。然后你有几个条目，每个条目都填入了相应的数据类型列。因此，对于一个状态，你将有几个条目填入“CHAR_VALUE”。

如何管理数据库中的“选择列表”

16 个答案: