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

解决方案

回答

根据需求，我们可以只拥有一个选项表，该表具有一个列表标识符和一个列表值作为主键。

select optionDesc from Options where 'MyList' = optionList

然后，我们可以在订单列等中扩展它。如果我们有ID字段，这就是我们可以参考引用答案的方式……如果它经常更改，则可以将答案值复制到答案表中。

回答

如果我们不介意使用字符串作为实际值，则可以简单地为每个列表赋予不同的list_id值，并在单个表中填充：

item_id：int

list_id：整数

文字：varchar(50)

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

回答

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

当我们需要简单时，对我们来说非常有用。

回答

我以两种不同的方式完成了此操作：
1)每个列表的唯一表
2)列表的主表，并带有给出特定视图的视图

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

回答

我们遵循了每个选择列表的新表格的模式。例如：

表FRUIT具有列ID，名称和描述。
值可能包括：
15000，苹果，红色水果
15001，香蕉，黄色和美味
...

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

回答

尝试解决问题。为什么需要从数据库中提取它？数据不是模型的一部分，但我们真的想将其保留在数据库中吗？我们可以使用linq2sql或者nhibernate之类的OR映射器(假设我们位于.net世界中)，或者根据可以将其手动存储在表中的数据而定，在某些情况下，将其全部放入同一张桌子，但只有在我们觉得它真的很有意义的情况下，才考虑这样做。通常，将不同的数据放在不同的表中可以使(以后)了解正在发生的事情变得容易得多。

回答

这里有几种方法。

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

2)创建一个包含所有选择列表的表格。列：ID；列表ID(或者列表类型)；姓名。当我们需要填充列表时，执行查询"选择列表ID = ...的所有项目"。这种方法的优点：确实很容易添加选择列表；缺点：编写按组样式的查询要困难一些(例如，给我选择值X"的记录数。

我个人更喜欢选项1，对我来说似乎更"干净"。

回答

好吧，我们可以执行以下操作：

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

回答

过去，我创建了一个具有列表名称和可接受值的表，然后查询该表以显示该列表。我还包含一个基础值，因此我们可以返回列表的显示值和一个可能更难看的绑定值(例如，归一化数据的int小)

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

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

回答

为列表创建一个表，为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");

回答

我们可以为每个表(我的首选)使用单独的表，也可以使用具有类型列的公共选择列表表，我们可以使用该列从应用程序中进行过滤。一般来说，我不确定一个人会比另一个人有更大的好处。

如果数据库超过25个，则从组织上讲，使用单表解决方案可能会更容易，这样就不会有多个选择列表表使数据库混乱。

如果列表很长，则为每个表使用单独的表可能会使性能提高一些，但是如果索引和索引的设置正确，则这可以忽略不计。

我喜欢使用单独的表，这样，如果选择列表中需要更改某些内容，例如需要更改其他属性，则可以仅更改该选择列表，而对其余架构没有多大影响。在单表解决方案中，我们将不得不对选择列表数据进行非规范化，将该选择列表拉到单独的表中，等等。在单独的表解决方案中，约束也更容易实施。

回答

这取决于各种事情：

• 如果它们是不可变的并且是非关系的(例如"美国的名字")，则可以说它们根本不应该在数据库中：毕竟，它们只是格式化一些简单的东西(例如分配的两个字符代码)。这样做还有一个好处，就是我们不需要往返数据库就可以获取不需要更改的东西来填充组合框。然后，我们可以在代码中使用枚举，并在数据库中使用约束。如果是本地化显示，则每种区域性都需要使用不同的格式，然后可以使用XML文件或者其他资源来存储文字。
• 如果它们是关系型的(想想"状态-大写")，那么我也不是很确信……但是最近我一直在使用XML文件，数据库约束和javascript进行填充。它工作得很好，并且在数据库上很容易。
• 如果它们不是只读的但很少更改(即通常不能由最终用户更改，而只能由某些编辑者或者每日批处理更改)，那么我仍然会考虑不将它们存储在数据库中的机会……这取决于在特定情况下。
• 在其他情况下，存储在数据库中是一种方式(想想StackOverflow的标记...它们是"查找"，但最终用户也可以更改)-可能需要一些缓存。它需要进行一些仔细的锁定，但是效果很好。

回答

这很好地为我们服务：

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"的填充。

回答

两张桌子。如果我们尝试将所有内容填充到一张表中，则会破坏规范化(如果我们对此很在意)。以下是示例：

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列。 (顺便说一句，每当我尝试发布带有下划线的"列表"和"选项"字样时，预览窗口都会显得有些古怪。这就是为什么我要在此处留一个空格。)

查询如下所示：

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列通常会自动建立索引。

并且，除非我们要放置"相关的"数据，否则该列表不会为每个选择列表创建新表。我们将完全规避数据库提供的关系功能。我们最好将静态选择列表定义为基类或者属性文件中某个位置的常量(我们可以选择如何对名称/值对进行建模)。

回答

首先要回答第二个问题：是的，在大多数情况下，我将为每个选择列表创建一个单独的表。尤其是当它们用于完全不同类型的值(例如州和城市)时。我使用的一般表格格式如下：

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

如果我们愿意，可以添加一个单独的"值"字段，但我通常只将id字段用作选择框值。

我通常会使用一个选择，该选择首先按显示顺序排序，然后按名称排序，因此我们可以按字母顺序排序，同时仍添加自己的例外。例如，假设我们有一个要按字母顺序排列的国家/地区列表，但首先是美国，然后是加拿大，则可以说出"选择ID，从Table ORDER BY display_order命名，名称"并设置美国的display_order值为1，加拿大为2，所有其他国家为9.

我们可能会觉得更奇特，例如具有"活动"标志，以便可以激活或者停用选项，或者设置" x_type"字段，以便可以对选项，描述列进行分组，以便在工具提示中使用等。但是基本表适用于大多数情况下。

回答

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

我一直在尝试创建所有选择列表的一个主表，然后根据类型进行过滤。当它起作用时，总是不可避免地引起麻烦。例如，我们可能发现我们认为简单的选择列表并不是那么简单，并且需要一个额外的字段，我们现在是否将此数据拆分到另一个表中或者扩展主列表？

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