填充多租户应用程序的下拉列表答案

【问题标题】：Populating dropdownlists for mult-tenant applications填充多租户应用程序的下拉列表
【发布时间】：2011-06-22 15:23:43
【问题描述】：

我正在构建一个多租户的 mvc 3 应用程序，这意味着它将使用相同的基本数据结构，但根据用于访问它的域名提供不同的数据。

我要解决的一个问题就是这个。如何最好地根据正在呈现的站点使用选择选项填充多个下拉列表。要添加另一个皱纹，我还需要对字符串进行本地化。

一个明显的选择是简单地创建一个表格，其中包含网站 ID 和语言 ID 列，以及字段 ID 和字符串值。这似乎没问题，但似乎也忽略了已经存在的本地化机制。我觉得我在这里重新创造了轮子。

例如，站点 1 可能有一个收藏活动的下拉列表，并且具有针对音乐兴趣的范围项目。站点 2 可能具有相同的下拉列表，但具有针对体育兴趣的项目。

所以我的问题是，您将如何解决这个问题？此外，以类似的方式...如果您有选择列表，例如州代码、城市等。您会倾向于创建单独的表格来填充这些数据（州表、城市表等）还是将所有这些信息都在一个公用表中，并有一个 ID 来指示它用于哪个下拉列表？前者似乎更规范化，但后者似乎更高效（编写的代码更少）。

【问题讨论】：

我认为这与 asp.net-mvc 没有任何关系。多租户与语言无关，您要问的更多是数据设计问题。
跟asp.net-mvc有关，因为本地化方面，asp.net-mvc提供了哪些本地化方法。此外，它与填充下拉列表的方式有关，这在 MVC 与其他框架中有所不同。

【解决方案1】：

关于通用查找表的思考。这家伙绝对反对。

我使用过它并相信我节省了一些时间，或者至少节省了一些按键。以后可能会后悔。

【讨论】：

他有一些有趣的cmets。我并不真正同意其中的一些观点，或者更确切地说，我认为它们过于理论化了。不过，他确实提出了一些好的观点。纯粹主义者和实用主义者之间的数据库设计存在这种分歧。纯粹主义者相信具有自然键的高度规范化的数据。在实践中，该技术常常使这种方法变得困难。此外，纯粹主义者倾向于将数据模型视为对现实生活的建模，但某些数据模型必须做出让步（例如，可扩展或处理多租户问题）。
链接不再可用，所以答案不是真的有效。