我的工作场所已经开始（最终）使我们的应用程序现代化。其中一个主要推动力是撕裂并重做我们的数据库。数据库中总有一些东西让我感到困惑：我们在代码中有各种表格，用于填充小的，基本不变的下拉菜单（头发颜色，眼睛颜色，性别等）和元素中的整数主键。每个表都用作主（相当大）表中的外键。这对我来说没有意义，因为它似乎有一些开销，我们的主要目标是高性能和可维护性。我的问题是双重的：
就存储数据的大小而言，对于这些表的关系使用整数FK与存储可能最高的varchar存储大小和/或性能存在显着差异长度7或8可能？
在数据库表中填充下拉列表并将其PK值作为FK存储在主表中与填充代码中的下拉列表并简单地保存字符串值之间是否存在显着的性能差异？
完成所有操作后，我们的应用程序将使用MVC4和实体框架用.NET 4.0编写。我们的数据库将是MS SQL Server 2012数据库。感谢您的帮助，对不起，如果这是重复。我无法弄清楚要搜索什么。
答案 0 :(得分：-1)
听起来像OOO（面向对象的矫枉过正）。解决方案是抽象到合理的水平。在这种情况下，如果你“感到困惑”而且“从来没有意义”，那可能就没必要了。没有正确或错误的方法，但在我看来，做你所描述的事情你不会有任何问题。
当然varchar占用的空间比FK多。计算您计划存储的记录数量，您将获得尺寸差异。可以忽略不计？可能。
如果有的话，那应该比从数据库填充更快。
答案 1 :(得分：-1)
1）CPU仅以二进制方式通话，我们世界上最接近的数据是数字。 你使用的字符串/ varchar，当cpu正在处理时，它们将被转换/映射到数字。
所以理论上+逻辑上，使用数字应该是最佳选择
至于性能增益是否“显着”，当你测试大量数据时，这只是更有形，你必须测量它们。
在db general / best practice中，建议使用数字作为密钥。
但imo，varchar应该没有区别，但你必须要注意区分大小写（抵押品）可能会破坏你的设计
因此使用数字可以为您节省很多不可预见/未来/整合问题。
2） 如果你进入表演，非规范化通常是一种方法。 但是如果你真的需要表演并没有更好的选择，你应该只进入这个。
你需要理解为什么/你应该采用规范化，这通常比非规范化产生更多的实际效益。