这是我的数据库设计：
我的第一个目标是按国家、城市、办公室或州轻松地对人员和他们自己的设备（该项目将用于资产管理）进行分组。
第二个目标是防止同一办公室的重复条目。一旦用依赖信息创建了一个办公室，其他人就需要添加某个办公室的现有信息。
你觉得我的设计怎么样？理想还是比要求的更复杂？
编辑：
感谢您的明智评论。如果我像下面这样改变我的结构，用户可以为多个国家添加一个城市。不是吗？可以为英国和法国添加伦敦城市。以及状态或地址。我应该通过过滤来防止这种情况发生，以便用查询填充列表框吗？
AskOverflow.Dev
模糊要求
你的要求太模糊了。添加更多细节。以非常精确的术语谈论每个实体如何与另一个实体相关。
地址
地址应分配给办公室。如果办公室只能有一个地址，那么地址应该是办公室表的一部分。
国家-州-城市的等级制度对我来说毫无意义。准确解释您的要求如何要求该结构。对此类值的报告是通过查询完成的，带有排序和分组，而不是构建单独的表。通常，只有一个语义列的相关表不应该是一个单独的表。
您谈到了将人员分配到办公室，但您的设计没有这种关联。
数据验证
您的一些顾虑似乎与验证地址的数据输入有关。通常应用程序是这种数据验证的前线防御，数据库端的检查扮演次要角色。
无论哪种方式（应用程序或数据库），您在此处显示的尝试都是微不足道的，不足以确保有效数据。如果您打算对地址进行数据验证，请认真对待：与其破解您自己的支票，不如利用由邮政编码驱动的邮政地址验证系统。使用远程服务或在本地提供您自己的完整已知地址数据集以及用于查找和比较地址信息的现有库。您的业务问题数据不应直接链接到此类表，而您的应用程序或数据库触发器应调用远程或本地地址验证服务。
命名问题
改为
People单数Person。修正
Adressto的拼写Address。在名称中使用全部小写字母以获得最大的可移植性并避免出现问题。
修复
Name在地址表中出现两次的问题。我不喜欢规范化
Locations. 在某些情况下，我会有一张Locations表格，上面分别列出了城市、州、国家/地区。在你的情况下，我会简单地将它们拼写出来Office。另外，我会使用标准缩写
归一化有两个用途：
允许在拼写更改时进行集中更改。但是一个城市/州/国家改名的频率是多少？
为了节省空间。但是你会拥有数百万
Offices吗？您可能
Persons在每个中都有很多Office，因此出于这两个原因，“规范化”是合理的。