顺便说一句，值得注意的是，如果您已经在生成csv并希望将它们加载到mySQL数据库中，load DATA LOCAL INFILE是您最好的朋友:http://dev.mysql.com/doc/refman/5.1/en/load-data.html。Mysqlimport也值得一看，它是一个命令行工具，基本上是一个装载数据文件的漂亮包装器。

不。看起来你设计得很细致。

我认为在你的设计中，国家和公司实际上是同一个实体，城市和部门也是如此。我将去掉国家和城市表(以及Cities_Has_Departments)，并在必要时向公司表添加一个布尔标志IsPublicSector(如果除了简单的Private Sector / PublicSector之外还有其他选择，则添加CompanyType列)。

Also, I think there's an error in your usage of the Departments table. It looks like the Departments table serves as a reference to the various kinds of departments that each customer division can have. If so, it should be called DepartmentTypes. But your clients (who are, I assume, attendees) do not belong to a department TYPE, they belong to an actual department instance in a company. As it stands now, you will know that a given client belongs to an HR department somewhere, but not which one!

换句话说，客户机应该链接到您称为Divisions_Has_Departments的表(但是我将简单地称之为Departments)。如果是这样，那么如果您想在数据库中使用标准引用完整性，就必须将Cities分解为division，就像上面讨论的那样。

这不是过度设计，这是我处理问题的方式。加入很好，不会有太大的性能损失(这是完全必要的，除非你对数据库进行反规格化，这是不建议的!)对于状态，查看是否可以使用枚举数据类型来优化该表。

顺便说一句，值得注意的是，如果您已经在生成csv并希望将它们加载到mySQL数据库中，load DATA LOCAL INFILE是您最好的朋友:http://dev.mysql.com/doc/refman/5.1/en/load-data.html。Mysqlimport也值得一看，它是一个命令行工具，基本上是一个装载数据文件的漂亮包装器。

我唯一想做的改变是: 1-把你的VARCHAR改成NVARCHAR，如果你想要国际化，你可能需要unicode。

2-如果可能的话，将int id改为GUIDs (uniqueidentifier)(这可能只是我的个人偏好)。假设您最终拥有多个环境(开发/测试/登台/prod)，您可能希望将数据从一个环境迁移到另一个环境。使用GUID id可以大大简化这一点。

3-你公司的三层结构->部门->部门结构可能不够。现在，这可能是过度工程，但你可以推广这个层次结构，这样你就可以支持n层深度。这将使您的一些查询更加复杂，因此可能不值得这样做。此外，任何具有更多层的客户端都可以很容易地“填充”到这个模型中。

4-你在客户端表中也有一个状态，它是VARCHAR，没有到状态表的链接。我希望能更清楚地说明客户状态代表什么。

大多数事情都已经说过了，但我觉得我可以补充一点:年轻的开发人员在一开始就有点过多地担心性能，这是很常见的，而你关于连接表的问题似乎正朝着这个方向发展。这是一种名为“过早优化”的软件开发反模式。试着把这种反射从你的脑海中赶走:)

还有一件事:你真的需要“城市”和“国家”表吗?难道在部门表中有一个“城市”和“国家”列不足以满足您的用例吗?例如，您的应用程序需要按城市和城市按国家列出部门吗?