📐 系统一：数据库表设计质量分析报告

项目-资讯关系表，存储项目和资讯的多对多映射。没有主键意味着：①同一组(project_id, article_id)可以重复插入；②任何JOIN操作都可能产生笛卡尔积；③数据膨胀后去重不可逆。
建议：立即添加复合主键 PRIMARY KEY (project_id, article_id)。

全国药品招投标数据主表，是整个招投标数据体系的核心表。无主键意味着中标的药品可能被重复记录，影响所有基于此表的下游分析和API输出。
建议：根据业务规则定义主键，候选：(药品编码, 中标日期, 省份)。

药品中标结果明细表。与主表md_drugbidsourcehc_zb关联，自身也无主键。父子两表均无唯一标识，数据完整性的底线失守。
建议：先定义主键后可考虑外键约束 FOREIGN KEY (zb_id) REFERENCES md_drugbidsourcehc_zb(id)。

这55张表分布在"医院会员"和"数据云服务"两个数据库中。除了表名和中文描述外，没有任何字段级的元数据（字段名、类型、约束、说明）。 这意味着对90%的数据资产，我们连"每个表有哪些字段"都不知道。质量评估无法开展，问题发现依赖人工经验。
建议：分三批补齐——第一批：核心业务表（如会员主表、订单表等）→ 第二批：配置/字典表 → 第三批：日志/归档表。

有字段明细的6张表中，34个字段名以 _id 结尾（如 articleid, projectid, channelid），它们大概率是外键关联字段。 但元数据中没有任何INDEX标记或FOREIGN KEY约束。百万级数据下，未索引的外键JOIN可能慢10-100倍。
建议：对所有 _id 结尾且非主键的字段，检查实际查询模式，按需创建索引。

iscompletion(integer), isslide(smallint), ishover(varchar) 等字段在语义上就是布尔值（是/否），但定义为数值或字符串类型。 问题：①integer类型的iscompletion可以存入3、-1等非法值；②varchar类型的ishover可以存入'yes'/'no'/'1'/'0'等各种变体。
建议：新建表统一用 BOOLEAN；存量表加CHECK约束 CHECK (iscompletion IN (0,1))。

htmlsavetime 的字段定义为 character varying(500)，但语义显然是日期时间。 用字符串存日期：①无法用日期函数做范围查询；②格式不统一（有人写 '2026-06-23'，有人写 '2026/06/23'）。
建议：评估是否有历史数据格式不统一的情况，若有则先清洗再改类型。

例如 productname 定义为 character varying(4000)、summary 定义为 character varying(4000)。 varchar(4000) 在 PostgreSQL 中接近 text 类型的上限但又不完全是——它占用固定开销，且索引受限。
建议：评估实际值长度分布，若大部分值 <255 则缩小；若确实需要长文本则改用 TEXT。

字段名 status（出现在3张表）、type（2张表）、id（没有表级前缀）——这些词在单表内没问题，但在跨表Join时完全无法从名称判断含义。 a.status = b.status 到底在比什么？需要翻文档甚至看数据才能理解。
建议：在字段注释/中文名中明确含义；新字段命名遵循"表名缩写_含义"模式。

307个字段中仅12个（4%）定义了NOT NULL约束。这意味着几乎所有字段都可能出现空值——这不是"灵活"，而是"没有业务兜底"。
建议：逐字段评估：业务上"不能为空"的字段加NOT NULL；不能加NOT NULL的字段（如可选备注）加DEFAULT值。