地址与房产关联关系的数据库设计选型咨询

首先纠正一个认知误区：你觉得方案1“逻辑倒置”其实是误解。在数据库设计中，外键放在依赖实体（房产）中，指向被依赖实体（地址），恰恰是“房产拥有地址”的正确体现——因为房产必须关联一个地址才能存在，而地址可以独立于房产存在（比如一个地址还没有被任何用户注册为房产）。

接下来分析两种现有方案的问题：

• 方案1：如果不解决地址重复问题，确实会出现多个相同地址的address_id，导致房产关联重复的地址记录，但核心问题在地址表的重复，而非关联逻辑。
• 方案2：让地址表关联房产，相当于把地址变成了房产的附属属性，这会导致同一个物理地址必须为每个房产重复存储一次，既浪费存储，也违反数据库范式，完全不可取。

更优的解决方案（从根源解决重复+正确关联） #

你的核心痛点是Google Maps地址无门牌号导致的重复存储，结合业务场景，最优设计分两步：

1. 重构地址表，从根源避免重复

利用Google Maps提供的place_id（每个地点的唯一标识）作为地址表的唯一约束，确保同一个Google地址只存储一次：

CREATE TABLE addresses (
    id INT PRIMARY KEY AUTO_INCREMENT,
    place_id VARCHAR(255) UNIQUE NOT NULL, -- Google Maps唯一标识，杜绝重复
    street VARCHAR(255),
    city VARCHAR(100),
    postcode VARCHAR(20),
    country VARCHAR(100),
    -- 其他Google Maps返回的地址字段
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

这样，无论多少用户注册同一个无门牌号的地址，地址表只会生成一条记录。

2. 房产表关联地址，新增门牌号字段

把门牌号从地址表剥离，放到房产表中——因为门牌号是具体房产的属性，而非Google Maps地址的一部分（当Google地址无门牌号时）：

CREATE TABLE properties (
    id INT PRIMARY KEY AUTO_INCREMENT,
    user_id INT NOT NULL, -- 关联注册用户
    address_id INT NOT NULL, -- 外键，指向addresses.id
    door_number VARCHAR(50), -- 门牌号，可为空（如果用户没提供）
    property_type ENUM('apartment', 'house', 'office'), -- 房产类型
    -- 其他房产属性：面积、价格等
    FOREIGN KEY (address_id) REFERENCES addresses(id),
    FOREIGN KEY (user_id) REFERENCES users(id)
);

设计优势 #

• 彻底解决地址重复问题：通过place_id唯一约束，同一个Google地址只存一次。
• 逻辑清晰：房产通过address_id关联地址，完美体现“房产拥有地址”的业务逻辑。
• 灵活适配场景：门牌号作为房产属性，支持无门牌号（为空）和有门牌号的情况，多个房产可以关联同一个地址。

如果暂时无法引入place_id，退而求其次的方案是为地址表的核心字段（street、city、postcode、country）添加联合唯一约束，避免重复存储相同地址。

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