网站中国家、州、城市级联选择数据的存储方案与位置咨询

数据存储格式选型 #

• 原始Excel仅适合做初始数据导入源，不要直接用于生产环境存储。先把Excel里的树状数据做结构化清洗，转成标准映射表结构即可，不需要搞复杂设计：
  • 国家表：核心字段为country_id（主键）、country_name，可加排序权重字段把常用国家排在前面
  • 州/省表：核心字段为state_id（主键）、state_name、country_id（关联国家表的外键）
  • 城市表：核心字段为city_id（主键）、city_name、state_id（关联州/省表的外键）
• 如果后续没有频繁调整行政区划的需求，清洗完的数据也可以直接导出为结构化JSON文件，存在GAE配套的Cloud Storage静态存储或者Firestore里就行，不用特意搭关系型数据库，维护成本更低。

存储位置与拉取策略选型 #

三个常见方案的实际表现和适配性如下，直接按场景选就行：

• 全量数据打包进前端首屏加载：仅适合数据量极小的场景（比如只覆盖不到10个国家，压缩后总数据量小于100KB）。如果是覆盖全球的全量国家-州-城市数据，压缩后也有2-5MB，会明显拖慢登记页首屏加载速度；后续只要有行政区划调整（比如区域更名、新增城市），就得重新发布前端版本，灵活性极差，通用场景不推荐。
• 全量数据存后端，每次打开页面全量拉取：完全没必要，问题和前端存全量基本一致——浪费带宽、加载慢，用户大概率只需要选单个国家下的单个城市，没必要把几万条冗余数据全拉到本地，直接排除。
• 国家列表存前端，州、城市数据存后端按需拉取：这是绝大多数同类业务的最优解，完全适配你的GAE技术栈：
  • 全球国家总共就200余条，压缩后仅几KB，直接打包进前端静态资源没有任何负担，首屏就能直接渲染第一个下拉框，不需要等接口响应
  • 后端只需要两个极轻量接口：GET /states?country_id={选中的国家ID}返回对应国家的州列表，GET /cities?state_id={选中的州ID}返回对应州的城市列表，逻辑简单响应快，GAE免费实例都能扛住很高的并发
  • 后续做行政区划更新只需要修改后端存储的数据，不需要重新发前端版本，维护成本很低

小优化提示：这类地理数据几乎是静态不变的，可以给两个拉取接口加CDN缓存，同参数的请求结果可以缓存数周甚至数月，进一步降低后端压力、提升响应速度。如果你的用户集中在少数几个国家，也可以把这些高频国家的州列表做预加载，进一步减少用户选值时的等待时间。

内容的提问来源于stack exchange，提问作者Martim Gouveia