是否应脱离Django ORM改用原生SQL？（除非可动态生成模型）

你的情况简直是原生SQL大展身手的典型场景，我来帮你拆解下为什么，以及怎么落地更顺畅：

为什么ORM在这里不太适配？ #

• 动态变化的表结构与命名：你每个行业每年都有新表（比如Industry_A_15、Industry_B_17），而且每个表上百个字段，ORM的核心是静态模型映射，每年手动更新models.py完全不现实，inspectdb又因为约束问题掉链子，这直接戳中了ORM静态映射的痛点。
• 无重叠的行业数据：各行业数据完全独立，不需要ORM擅长的关联查询、模型关系维护，用ORM反而会因为要维护大量冗余模型增加负担。

用原生SQL的优势在这里体现得淋漓尽致 #

• 动态表引用：你可以直接通过字符串拼接生成表名（比如根据年份和行业代码动态构造Industry_{industry}_{year}），完全不用修改代码就能适配每年的新表。
• 轻量高效：你的查询都是基础SELECT语句，主流数据库（MySQL、PostgreSQL等）对基础SELECT的语法兼容性很好，不用担心跨库适配问题。
• 避开模型层的冗余工作：既然表是通过CSV上传自动创建的，不需要ORM来管理表结构，直接绕开模型层反而能减少不必要的复杂度。

一些实践小建议 #

• 用Django提供的cursor接口来执行原生SQL，比如：

  from django.db import connection
  
  def get_industry_data(industry, year):
      table_name = f"Industry_{industry}_{year}"
      with connection.cursor() as cursor:
          cursor.execute(f"SELECT * FROM {table_name} WHERE some_condition = %s", [some_value])
          # 可以用cursor.fetchall()或者cursor.dictfetchall()获取结果
          rows = cursor.dictfetchall()
      return rows
  

• 注意SQL注入风险：如果industry和year是用户输入的内容，一定要做严格的校验（比如限制行业只能是A/B等固定值，年份是数字），或者用Django的quote_name方法来转义表名：

  from django.db import connection
  table_name = connection.ops.quote_name(f"Industry_{industry}_{year}")
  

• 如果需要对返回的结果做一些统一处理，可以封装一个基础的查询类，把动态表名、参数绑定、结果解析等逻辑抽离出来，避免重复代码。

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