嘿，这个需求在城市距离类的数据存储里很典型，我来一步步给你拆解清楚：

一、字符串类型的fromCity和toCity直接比较合理吗？ #

结论是：完全合理，但前提是你要先搞定字符串的标准化问题。

字符串本身是可以直接比较的（比如按字典序），但如果不做标准化，很容易踩坑：

• 比如一个存“New York”，另一个存“new york”，大小写不同会被判定为不同城市；
• 再比如“München”和“Munchen”（带重音和不带重音），也会被当成不同的字符串。

所以只要你在数据入库前，把所有城市名统一成相同的格式（比如全小写、去除冗余空格、标准化特殊字符），直接比较字符串是完全可靠的，能准确识别出“X→Y”和“Y→X”是同一对城市组合。

二、具体实现方案（按推荐程度排序） #

方案1：存储时强制统一顺序（最推荐） #

从根源上避免重复的最好方法，就是在插入数据前，把fromCity和toCity按字典序排序，固定存储规则——比如永远把字典序更小的城市存在fromCity字段，更大的存在toCity字段。

举个SQL层面的实现例子（以MySQL为例）：

-- 先给城市对创建联合唯一索引，防止重复插入
CREATE UNIQUE INDEX idx_city_pair ON city_distances(from_city, to_city);

-- 插入时自动统一顺序，重复则更新距离
INSERT INTO city_distances (from_city, to_city, distance)
VALUES (
    LEAST('Paris', 'London'), -- 取字典序小的
    GREATEST('Paris', 'London'), -- 取字典序大的
    344
)
ON DUPLICATE KEY UPDATE distance = VALUES(distance);

如果是在应用层处理（比如Python/Java），逻辑也很简单：

def save_distance(from_city, to_city, distance):
    # 先统一城市顺序
    if from_city > to_city:
        from_city, to_city = to_city, from_city
    # 然后执行插入或更新操作，比如用ORM的get_or_create方法
    CityDistance.objects.get_or_create(
        from_city=from_city,
        to_city=to_city,
        defaults={'distance': distance}
    )

方案2：查询时兼容双向匹配（适合历史数据场景） #

如果已经有历史数据，没法修改存储顺序，那可以在查询时同时匹配两种方向：

SELECT distance FROM city_distances
WHERE (from_city = 'X' AND to_city = 'Y') OR (from_city = 'Y' AND to_city = 'X');

但这个方案的缺点很明显：数据库层面没法阻止重复存储，只能靠应用层逻辑控制；而且查询时需要扫描更多数据，性能不如方案1。

方案3：生成无序唯一键存储 #

可以把两个城市名组合成一个无序的唯一标识，比如排序后拼接成字符串，或者取哈希值（注意哈希冲突风险），然后把这个标识作为唯一键存储。

比如在应用层生成city_pair字段：

# 排序后拼接，保证X-Y和Y-X生成的字符串一致
city_pair = '-'.join(sorted([from_city, to_city]))

然后给city_pair字段创建唯一索引，这样就能确保同一对城市只会被存储一次。

三、必须注意的细节 #

• 字符串标准化是核心：一定要在数据入库前做清洗，比如统一转小写、去除多余空格、处理特殊字符（比如把带重音的字符转成普通字符，或者统一保留），否则字符串比较会失效。
• 索引不能少：不管用哪种方案，都要给相关字段创建合适的索引，保证查询和插入的性能。
• 业务场景要确认：这个方案只适用于城市间距离双向相等的场景，如果你的业务里“X→Y”和“Y→X”的距离不一样（比如涉及交通单向限行、不同路线），那这个需求本身就不成立，得重新评估。

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