我正在尝试设计一个MySQL数据库来存储用户zipcode首选项以提供特定服务。例如，作为管道工的用户A愿意前往x，y和z邮政编码以提供他的服务。 我一直在考虑实现这一点的各种方法，可伸缩性非常重要。另外，我想在邮政编码和城市名称之间建立映射。
设计此方法的一种方法是创建一个巨大的表，每列代表一个邮政编码，每行将存储一个带有邮政编码首选项的用户条目。但是当我添加邮政编码并说数百万用户时，这会如何扩展？我认为它不会很好地扩展，但实现起来很简单。
另一种方法是通过拥有主表和一堆辅助表来实现此层次结构。辅助表保持让我们说县的邮政编码，主表充当辅助表的密钥。我认为这可以更好地扩展，因为表可以分布，但我可能有很小的冗余，因为用户可以存储在几个表中。
无论如何，我会感谢任何可以帮助我的想法，想法或替代设计。这个问题真的归结为，我应该如何设计这个以及为什么？
更新 我有一个单独的表与用户信息。我正在尝试为用户的邮政编码首选项设计表格。
答案 0 :(得分：1)
我建议稍微改进你目前的做法。
使用支持地理空间数据索引的数据库，例如使用Postgis的PostgreSQL。然后，除邮政编码外，还要存储邮政编码的坐标。
因此，在向管道工询问他想要提供哪些邮政编码时，您将能够提取附近的邮政编码。同样，当用户查询您的数据库时，您将能够在附近区域拔出管道工。
答案 1 :(得分：1)
无论可伸缩性问题如何，您都必须定义实体，您不希望首先出现数据库设计错误。 我想你可以有两个表，比如User和ZipCodes，以及一个将用户首选项与邮政编码联系起来的表，例如UserZipCodes，它有一个首选的邮政编码，或者更多的用户，这取决于你的要求，（可能强制执行）它有一个独特的约束）。我不知道MySQL，但是在SQL服务器中读取这样的表，列数很少，不是性能问题，所以你最好事先测试一下。
答案 2 :(得分：1)
由于商人通常不会行驶数百英里来修复泄漏的水龙头，您可以按如下方式解决问题：
我只需创建一个zip_code_distances表并预先计算美国所有42K邮政编码之间的距离，这些邮政编码在20到20英里半径范围内....仅包括20-内的邮政编码彼此相距25英里的半径会减少您需要存储在距离表中的行数，最大值为17亿（42K ^ 2） - 42K，更容易管理400万左右...
请在此处查看我的完整答案：
Calculate distance between zip codes and users
您要包含的其他表格包括：city，city_to_zipcode等...
希望有所帮助：）
答案 3 :(得分：0)
我会使用postgresql - 非常可扩展。它也非常丰富。至于模式，考虑将表拆分为三个表： 1.拉链码表 2.用户数据表 3.交叉表链接zipcodes和数据
不要在一张桌子上做到这一点！
答案 4 :(得分：0)
正如其他人所建议的那样......三个实体：用户，邮政编码和两者之间的交叉引用。业务规则将是...... 用户可以为许多Zipcodes提供服务。 许多用户都可以使用邮政编码。
行数可能看起来很大，但实际上这对于现代DBMS来说并不是很多，并且有很多方法可以从具有数百万行的表中获得非常好的性能。例如。水平分区。
一个不错的选择是存储地理空间数据，以帮助用户按照@Denis的建议选择附近的邮政编码