房屋租赁合同管理看起来只是记录租客和租期，但真正把业务落到数据库时，如果只用一张表塞下所有字段，后续统计空置房源、查询缴费记录、生成到期提醒都会变得很麻烦。房源、租客、合同、账单是四类不同的数据对象，它们之间有明确的关系：一个房源在不同时间可能关联多个租客，一个租客可能租过多套房，一份合同对应多条账单。本文基于SQLite实现一个本地可运行的租赁合同管理项目，先拆解需求，再建表和触发器，最后提供到期查询视图。

需求拆解：为什么房屋租赁合同不能只建一张表

如果只维护一张合同表，字段通常会包含房源地址、房东信息、租客姓名、身份证号、手机号、月租金、押金、起止日期、付款记录等。这样做的问题在于数据冗余和更新异常。例如同一租客续租或换房，需要重复录入身份证号和手机号，一旦号码变更就要改多条记录。房源状态也需要手动更新，合同到期后如果忘记把房源改回空置，空置查询就不准确。

更合理的做法是把数据拆成房源表、租客表、合同表和账单表。房源表描述房屋本身的地址、面积和当前状态；租客表保存租客身份信息；合同表作为中间关系，记录某套房在某个时间段租给某位租客的价格和押金；账单表则记录每一次实际收款，包括租金、押金、水电费等。这样拆分后，房源空置查询只关心房源表，租客信息修改只影响租客表，账单对账只关心账单表，各模块职责清晰。

SQLite非常适合这个场景。它不需要独立数据库服务，数据库就是一个文件，部署和备份都很简单。对于个人房东、小型公寓或单机工具类应用，SQLite的事务、外键、触发器、视图能力已经足够支撑合同管理的核心逻辑。下面从建库开始，把上面的设计落成可执行SQL。

SQLite建库与表结构设计

先创建数据库文件。如果使用命令行工具，在Windows下可以执行 sqlite3 C:\sqlite\rent.db，这个路径中的反斜杠是Windows路径分隔符。创建完文件后，第一步是开启外键约束。SQLite默认不强制外键，需要每个连接执行 PRAGMA foreign_keys = ON;。否则删除房源时可能留下指向不存在房源的合同数据。

表结构如下：房源表 houses 包含地址、面积和状态；租客表 tenants 保存姓名、手机号和身份证号；合同表 contracts 通过 house_id 和 tenant_id 关联前两张表，同时记录起止日期、月租金和押金；账单表 payments 通过 contract_id 关联合同。日期统一使用 TEXT 类型存储 YYYY-MM-DD 格式，SQLite的 date() 和 julianday() 函数可以直接解析这种格式，计算租期天数很方便。

PRAGMA foreign_keys = ON;
CREATE TABLE houses (
    house_id INTEGER PRIMARY KEY AUTOINCREMENT,
    address TEXT NOT NULL,
    area REAL,
    status TEXT NOT NULL DEFAULT '空置'
        CHECK (status IN ('空置','已租','维修中')),
    created_at TEXT NOT NULL DEFAULT (datetime('now','localtime'))
);
CREATE TABLE tenants (
    tenant_id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    phone TEXT NOT NULL UNIQUE,
    id_card TEXT,
    created_at TEXT NOT NULL DEFAULT (datetime('now','localtime'))
);
CREATE TABLE contracts (
    contract_id INTEGER PRIMARY KEY AUTOINCREMENT,
    house_id INTEGER NOT NULL,
    tenant_id INTEGER NOT NULL,
    start_date TEXT NOT NULL,
    end_date TEXT NOT NULL,
    monthly_rent REAL NOT NULL,
    deposit REAL NOT NULL,
    status TEXT NOT NULL DEFAULT '履行中'
        CHECK (status IN ('履行中','已到期','已退租','已违约')),
    created_at TEXT NOT NULL DEFAULT (datetime('now','localtime')),
    FOREIGN KEY (house_id) REFERENCES houses(house_id),
    FOREIGN KEY (tenant_id) REFERENCES tenants(tenant_id)
);
CREATE TABLE payments (
    payment_id INTEGER PRIMARY KEY AUTOINCREMENT,
    contract_id INTEGER NOT NULL,
    pay_date TEXT NOT NULL,
    amount REAL NOT NULL,
    pay_type TEXT NOT NULL DEFAULT '租金'
        CHECK (pay_type IN ('租金','押金','水电','维修费')),
    remark TEXT,
    FOREIGN KEY (contract_id) REFERENCES contracts(contract_id)
);

这里把 status 字段加上 CHECK 约束，能避免录入状态时出现错别字。合同起止日期虽然没有用 CHECK 强制结束日期晚于开始日期，但建议在应用层做一次校验。SQLite的 CHECK 约束虽然可以写日期比较表达式，但报错信息不一定友好，应用层提前校验更利于用户体验。

接下来插入几条样本数据，方便验证后续触发器与视图。样本中一套房源处于已租状态，另一套空置，同时给合同添加对应的押金和首月租金账单。

INSERT INTO houses (address, area, status) VALUES
('阳光花园3栋502', 88.5, '已租'),
('翠湖小区7栋1201', 105.0, '空置');
INSERT INTO tenants (name, phone, id_card) VALUES
('张明', '13800000001', '110101199001011234'),
('李丽', '13800000002', '110101199203034567');
INSERT INTO contracts (house_id, tenant_id, start_date, end_date, monthly_rent, deposit, status) VALUES
(1, 1, '2024-01-01', '2025-01-01', 3200.00, 3200.00, '履行中'),
(2, 2, '2024-03-01', '2025-03-01', 4500.00, 4500.00, '已退租');
INSERT INTO payments (contract_id, pay_date, amount, pay_type, remark) VALUES
(1, '2024-01-01', 3200.00, '租金', '1月租金'),
(1, '2024-01-01', 3200.00, '押金', '合同押金');

用触发器自动维护房屋状态和合同状态

如果不使用触发器，应用层需要同时更新合同表和房源表，例如新增一份合同后，还要记得把房源状态改为已租。这种手工同步很容易遗漏，尤其在合同退租、违约、到期等场景下，状态变更条件更多。SQLite触发器可以在数据写入或更新时自动执行逻辑，减少应用层代码量。

先创建一个插入触发器，每当向 contracts 表插入新合同时，自动把对应房源状态改为已租。再创建一个更新触发器，当合同状态被修改为已到期、已退租或已违约时，把房源恢复为空置。这样应用层只需要维护合同状态，房源表会自动跟着变化。

CREATE TRIGGER trg_contract_insert
AFTER INSERT ON contracts
BEGIN
    UPDATE houses
       SET status = '已租'
     WHERE house_id = NEW.house_id;
END;
CREATE TRIGGER trg_contract_status_update
AFTER UPDATE OF status ON contracts
BEGIN
    UPDATE houses
       SET status = CASE
                        WHEN NEW.status IN ('已到期','已退租','已违约') THEN '空置'
                        ELSE '已租'
                    END
     WHERE house_id = NEW.house_id;
END;

还要解决合同到期自动标记的问题。SQLite没有内置定时任务，但可以在应用启动时执行一条 UPDATE 语句，将结束日期早于今天且状态仍为履行中的合同批量更新为已到期。同时也可以创建一个触发器，在合同更新时检查是否已经到期。

CREATE TRIGGER trg_contract_expire_check
AFTER UPDATE ON contracts
WHEN NEW.end_date < date('now','localtime')
   AND NEW.status = '履行中'
BEGIN
    UPDATE contracts
       SET status = '已到期'
     WHERE contract_id = NEW.contract_id;
END;

这里 date('now','localtime') 返回本地日期，NEW.end_date 是更新后的合同结束日期。触发器条件中的小于号在HTML代码块里写成了 <，实际SQL执行时就是普通的小于号。SQLite默认不开启递归触发器，所以触发器内部更新 contracts 表不会再次触发自身，可以放心使用。

通过视图实现到期合同提醒

合同到期提醒是租赁管理最常用的功能。与其每次用一条复杂SQL拼接字段，不如创建视图，把房源、租客和合同信息连接起来，并计算剩余天数，只保留30天内到期的履行中合同。以后查询提醒列表时直接 SELECT * FROM v_expiring_contracts; 即可。

这里使用 julianday() 函数把日期转换成儒略日数，两个日期相减得到天数差。用 CAST(... AS INTEGER) 把结果转成整数，页面展示时不会出现小数天数。筛选条件有两层：剩余天数大于等于0，避免已经到期的合同混入；剩余天数小于等于30，符合即将到期的范围。

CREATE VIEW v_expiring_contracts AS
SELECT c.contract_id,
       t.name AS tenant_name,
       t.phone,
       h.address,
       c.end_date,
       CAST(julianday(c.end_date) - julianday(date('now','localtime')) AS INTEGER) AS remain_days,
       c.monthly_rent,
       c.status
  FROM contracts c
  JOIN tenants t ON t.tenant_id = c.tenant_id
  JOIN houses h   ON h.house_id = c.house_id
 WHERE c.status = '履行中'
   AND julianday(c.end_date) >= julianday(date('now','localtime'))
   AND julianday(c.end_date) - julianday(date('now','localtime')) <= 30;

这个视图把业务判断封装在数据库层，应用代码只负责查询和展示。对于即将到期的合同，运营人员可以提前联系租客确认是否续租。如果续租，就在原合同结束后新建一份合同，或更新结束日期并重新计算；如果不再续租，租客退租后把合同状态改为已退租，触发器会自动把房源改为空置，提醒列表也会自动排除该合同。

容易踩的坑与优化建议

第一个容易忽略的问题是外键约束没有开启。很多SQLite管理工具默认连接不会自动执行 PRAGMA foreign_keys = ON;，结果删除房源或租客时不会报错，却留下了孤儿合同记录。因此无论在命令行、应用代码还是迁移脚本中，都要在连接建立后立即执行这条语句。

第二个是并发写入的限制。SQLite的写操作采用库级锁，同一时间只允许一个写事务。单机工具或小型公寓管理没有问题，但如果想把它部署成多用户公网服务，出现同时写入时会报 database is locked。这种情况下应该考虑升级到PostgreSQL或MySQL，或者把写操作串行化并加上超时设置。

第三个是日期边界的处理。SQLite的 julianday() 对无效日期字符串会返回 NULL，比如 2024-02-30 这种不存在的日期。如果表里混入这类数据，剩余天数计算结果会是空值，提醒视图会直接跳过该合同。可以在插入或更新日期时增加 CHECK 约束，或者在应用层做严格日期解析。

最后建议给高频查询字段建立索引。合同表的 status、end_date、house_id、tenant_id 都是常见的筛选条件，尤其是到期提醒视图会频繁过滤状态和结束日期。为这些列建索引后，即使合同数据增长到几万条，查询速度依然可以保持在毫秒级。整个方案从表结构到触发器、视图，形成一个完整而轻量的SQLite实战项目。