如何在关联CRS表的SQL数据库中存储Northing/Easting或经纬度坐标？

核心原则：优先用空间数据类型，避免冗余空列 #

不要采用Lat、Long、Northing、Easting四个独立列的设计——这种方案会产生大量空值，既浪费存储资源，又提升查询与维护的复杂度，后续扩展灵活性极低。推荐直接利用SQL的geometry或geography类型，结合你已有的CRS表完成适配，具体分两种场景处理：

1. 统一用geometry适配所有CRS类型 #

• 无论点位是经纬度（地理坐标系）还是东/北坐标（投影坐标系），都统一存储为geometry类型，同时通过外键关联CRS表记录对应的CRS ID。
• 存储时根据CRS类型选择对应构造函数：
  • 经纬度（如WGS84）：使用ST_GeomFromText('POINT(lon lat)', <EPSG代码>)（例：WGS84对应EPSG 4326）
  • 东/北坐标（如UTM投影）：使用ST_GeomFromText('POINT(easting northing)', <EPSG代码>)
• 优势：空间类型自带CRS信息（通过EPSG码），与CRS表形成双重校验避免数据不一致；原生支持空间查询、距离计算等操作，比单独存储数值列灵活得多。

2. 分场景用geography+geometry（可选） #

如果业务中地理坐标系（经纬度）与投影坐标系（东/北）的操作差异明显（比如频繁做球面距离计算），可以：

• 在点位表新增两个字段：geo_point geography和proj_point geometry，同时保留CRS外键。
• 根据点位的CRS类型填充对应字段：地理CRS填geo_point，投影CRS填proj_point，另一字段留空。
• 这种方式比四个数值列高效（空间类型为紧凑存储），且支持原生空间函数，但会增加少量存储开销，适合业务场景明确区分的情况。

适配现有CRS表的关键操作 #

• 确保CRS表存储每个CRS对应的EPSG代码，这是空间类型与CRS关联的核心依据。建议CRS表包含crs_id（主键）、crs_name、epsg_code、is_geographic（标记是否为地理坐标系）等字段。
• 插入点位数据时，根据CRS的epsg_code和is_geographic选择对应空间类型构造函数，同时关联crs_id外键。
• 查询时，可通过CRS表的is_geographic字段快速筛选地理/投影点位，也能用ST_SRID()函数获取空间点的EPSG码，与CRS表做关联校验。

明确不推荐的方案：四个独立数值列 #

该方案存在诸多问题：大量空值浪费存储，查询时需判断有效列增加SQL复杂度；无法直接使用空间函数，后续若需空间分析需额外做数据转换，成本极高。

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