Question

想象一下，您有一个网站，其中包含从后端数据库填充的多个下拉菜单。目标是将这些值存储在数据库中，并在呈现表单时检索它们。

我见过两种方法：

1）每个列表类型一个表：

profession_type
|id|value|

hobby_type
|id|value|

2）所有查找值都有一个表格：

|id|type           |value|
|0 |profession_type|value|
|1 |profession_type|value|
|2 |profession_type|value|
|3 |hobby_type     |value|
|4 |hobby_type     |value|
|5 |hobby_type     |value|

两者都有客观优势吗？＃2似乎更通用（您可以按类型从表中选择以填充特定的下拉列表），但是表格将比使用＃1时更大。此外，如果使用＃2，则所有外键都指向同一个巨型表。这似乎不是什么大问题，但在我看来，这种方法看起来更复杂。

Answer 1

我会选择＃2。您可以检索和缓存所有信息，即使添加新类型，也无需更改数据库或检索逻辑。

如果要添加和更改表，则需要触摸数据库模式以便将来进行所有更改，并更改新表的检索代码。

此外，您对表格大小的担忧可能是毫无根据的。除非你有数百万行，否则它会没问题。我想象几百或几千行？数据库可以轻松处理。

Answer 2

从报告的角度来看，＃2使事情变得更加困难，尤其是在使用直接命中数据库的工具（例如SSRS或Tableau）的情况下。您需要放入存储过程或视图以使报告成为可能。问题在于，在许多报表工具中，多次连接到一张表可能很困难。

是的，我完全理解，在开发应用程序时，每次想要添加新下拉列表时都会在背面添加一个新表，但是通过选择选项1，您将节省背面一位可怜的BI开发人员遭到CEO大喊大叫。

存储下拉值，什么是好方法

2 个答案: