SQLAlchemy搭配Redshift物化视图使用的可行性及选型咨询

完全可以正常搭配使用，不存在底层兼容问题。
很多新手对SQLAlchemy的主键要求有误解：ORM层要求模型定义至少一个标记为主键的列，只是Python侧用来做会话内对象实例的唯一标识，不会向数据库下发创建主键的DDL，也不会校验数据库侧是否真的存在对应主键约束。
针对没有主键的Redshift物化视图，有两种成熟的处理方式，都不会影响join等复杂查询：

• 优先选物化视图里能唯一标识单条记录的一列（或多列组合），在模型定义时给这些列加上primary_key=True参数即可。哪怕数据库里这些列没有实际主键约束也没关系，ORM层的这个标记不会改写你生成的查询SQL，join逻辑是在Redshift端执行的，根本不会因为这个标记抛出异常。你环境里配置的dist/sort key是Redshift存储层的优化配置，对上层ORM完全透明，不需要做任何特殊适配。
• 如果找不到能唯一标识行的列，也不用硬凑，直接通过mapper参数指定代理主键即可，示例代码如下：

from flask_sqlalchemy import SQLAlchemy
from sqlalchemy import text
db = SQLAlchemy()

class UserBehaviorMV(db.Model):
    __tablename__ = "mv_user_behavior_stat"
    # 按实际字段定义即可，不需要硬给字段加主键标记
    user_id = db.Column(db.BigInteger)
    stat_date = db.Column(db.Date)
    pay_amount = db.Column(db.Numeric(12,2))
    visit_cnt = db.Column(db.Integer)

    __mapper_args__ = {
        # 选一个非空、区分度高的列作为ORM侧的代理主键即可
        "primary_key": [user_id]
    }

针对你提到的「高频重读取、绝大多数查询针对物化视图」的场景，优先选SQLAlchemy，完全没必要自己实现连接池逻辑，原因很实在：

• Flask-SQLAlchemy自带的连接池是经过十几年生产验证的成熟方案，自动处理连接保活、回收、会话生命周期管理、事务回滚等边缘场景，自己从零实现PostgreSQL连接池很容易踩连接泄漏、失效连接报错、事务状态残留的坑，线上出问题排查成本极高。
• 用SQLAlchemy不代表你必须全写ORM查询语法：遇到复杂聚合、多表join的场景，你完全可以直接写原生SQL，通过db.session.execute(text("你的原生Redshift SQL"))执行即可，同时还能复用连接池、结果序列化的能力，比纯裸SQL自己管理连接效率高很多。
• 只有当你所有查询都是固定的极复杂SQL，完全不需要动态条件拼接、对象映射能力，且团队所有人都极度排斥ORM依赖时，才考虑不用SQLAlchemy，但这种场景也更建议你直接用SQLAlchemy的Core层执行原生SQL，关闭ORM相关特性即可，没必要重复造连接池的轮子。

实用提醒：不要尝试用ORM的update()/delete()/add()方法操作Redshift物化视图，物化视图的刷新需要执行Redshift专属的REFRESH MATERIALIZED VIEW命令，这类操作直接走原生SQL即可，普通读操作不受任何影响。

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