如何管理數據庫中的「選擇列表」

Question

我有一個「選擇列表」實體（用於填充單選下拉選擇框）的應用程序。這些實體需要從數據庫中提取。我如何堅持這些實體在數據庫中？我應該爲每個選擇列表創建一個新表嗎？有更好的解決方案嗎？

Answer 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 

Answer 2

根據您的需要，您可以擁有一個選項表，其中包含一個列表標識符和一個列表值作爲主鍵。

select optionDesc from Options where 'MyList' = optionList 

然後，您可以用命令列等擴展它如果你有一個ID字段，那就是你可以如何引用你的答案回來......如果經常改變，你可以複製的回答答案表的值。

Answer 3

如果你不介意使用字符串的實際值，你可以簡單地給每個列表中的值不同LIST_ID並填充一個表：

ITEM_ID：整數

LIST_ID：整數

文本：VARCHAR（50）

似乎最容易的，除非你需要每個列表項多東西

Answer 4

我們實際上創建實體處理簡單選擇列表。我們創建了一個查找表，它包含所有可用的選擇列表，以及一個包含查找的所有名稱/值記錄的LookupValue表。

當我們需要它的時候，對我們很好用簡單。

Answer 5

我在兩種不同的方式做到了這一點： 1）每個列表 2）主表的名單獨特的表，享有給出具體的人

我傾向於選擇最初的選擇，因爲它使更新列表更容易（至少在我看來）。

Answer 6

我們遵循每個選擇列表的新表格模式。例如：

表FRUIT具有列ID，名稱和說明。
值可能包括：
15000，蘋果，紅果
15001，香蕉，黃色和美味
...

如果您有需要另一個表中引用的水果，你會打電話列FRUIT_ID並引用FRUIT表中該行的ID值。

Answer 7

試着轉過頭來問題。爲什麼你需要從數據庫中提取它？不是你的模型的數據部分，但你真的想把它保存在數據庫中？你可以使用一個OR映射器，如linq2sql或nhibernate（假設你在.net世界中），或者根據你可以手動將數據存儲在一個表中的數據 - 有些情況下將它全部放入同一張桌子，但只有當你覺得它真的很有意義時纔會考慮這一點。通常將不同的數據放在不同的表中會使（後來）更容易理解發生的事情。

Answer 8

這裏有幾種方法。

1）爲每個選取列表創建一個表格。每個表都有ID和名稱列;用戶選擇的值將根據所選項目的ID進行存儲。

2）創建一個表的所有選擇列表。列：ID;列表ID（或列表類型）;名稱。當您需要填充列表時，請執行查詢「選擇列表ID = ...的所有項目」。這種方法的優點：真的很容易添加選擇列表;缺點：有點難度編寫組由樣式的查詢（例如，給我的那個挑值X的記錄數」。

我個人比較喜歡選項1，似乎‘乾淨’我

Answer 9

在我創建了具有列表的名稱，並在可接受的v A表過去然後查詢它顯示列表。我還包括潛在的價值，這樣你就可以返回該列表中的顯示值和約束值，可能是更噁心（小INT的標準化數據，例如）

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

你也可以添加一個如果你想中將sortOrder場手動定義的順序來顯示它們。

Answer 10

創建列表一個表和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 11

您可以使用每個（我的首選）一個單獨的表，或者有可以使用從您的應用程序過濾器上的類型列一個共同的領料單表。我不確定一個人是否比另一個人有大的好處。

如果你有超過25個左右，組織可能更容易使用單表解決方案，使您不必選擇列表幾個表弄亂你的數據庫。

業績可能會更好使用單獨的表制定的，如果你的列表非常長的頭髮，但是這可能是微不足道的前提是您的指標，這樣的設置正確。

我喜歡用不同的表，這樣，如果東西在選擇列表的變化 - 它需要例如附加屬性 - 你可以在你的架構的其餘部分幾乎沒有影響改變只是選擇列表表。在單一表格解決方案中，您必須對您的選擇列表數據進行非規範化處理，將該選擇列表拉出到單獨的表格等中。在單獨的表格解決方案中，約束條件也更容易實施。

Answer 12

這取決於不同的事情：

• ，如果他們是不可變的和非關係型（認爲「美國各州的名字」）的參數可以提出，他們不應該在數據庫中的所有：後他們只是簡單的格式化（比如分配的兩個字符代碼）。這還有一個額外的好處，就是你不需要往返數據庫的往返取一些永不改變的東西來填充組合框。

  然後，您可以在代碼和數據庫的限制使用枚舉。如果是本地化顯示，那麼您需要爲每種文化設置不同的格式，然後您可以使用XML文件或其他資源來存儲文字。

• 如果他們是關係型的（認爲「國家 - 首都」）我不是很相信這兩種方式......但最近我一直在使用XML文件，數據庫約束和JavaScript填充。它工作得很好，在數據庫上很容易。

• 如果它們不是隻讀但很少更改（即通常不能被最終用戶更改，但只能由某個編輯器或每日批次更改），那麼我仍會考慮將它們存儲在數據庫中的機會。這取決於具體情況。

• 在其他情況下，存儲在數據庫中的方式（想想StackOverflow的標籤......它們是「查找」，但也可以由最終用戶更改） - 可能需要一些緩存。它需要一些小心的鎖定，但它會工作得很好。

Answer 13

這一直運作良好：

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」。

Answer 14

兩張表。如果你試圖將所有東西塞進一張表中，那麼你就會破壞標準化（如果你關心的話）。以下是示例：

 
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列通常會自動被編入索引。

請不要爲每個選擇列表創建一個新表格，除非您將「將在其他位置使用的」關係相關「數據放入應用程序中。你會繞過數據庫提供的關係功能。在基類或屬性文件（您對如何對名稱 - 值對建模的選擇）中，將靜態定義選擇列表作爲常量是最好的。

Answer 15

首先回答第二個問題：是的，在大多數情況下，我會爲每個選擇列表創建一個單獨的表格。特別是如果它們是針對完全不同類型的值（例如州和城市）。我用的是一般的表格式如下：

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字段作爲選擇框的值。

我通常使用一個選擇，首先按顯示順序，然後按名稱排序，這樣您就可以按字母順序排列某些東西，但仍然會添加自己的異常。例如，假設你有你想要的字母順序，但有美國第一，加拿大等國家的名單第二，你可以說"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 16

我發現創建單個表是最好的主意。

我一直在試圖創建一個所有選擇列表的主表，然後根據類型過濾掉的道路。雖然它起作用，但它總是令人頭痛。例如，你可能會發現你推測爲一個簡單的選擇列表並不那麼簡單，並且需要一個額外的字段，你現在是將這些數據分成一個額外的表還是擴展你的主列表？

從數據庫的角度來看，具有獨立的表使得它更容易管理你的關係完整性，它更容易，當你不使用的應用