在生产数据库中暴露可自动建表的CSV映射导入功能是否属不良实践？

先直接给结论：这种通过HTML页面导入映射时自动创建数据库表的做法，确实是高风险的不良实践，主要问题集中在这几个方面：

• 安全与权限隐患：如果HTML页面的权限控制不到位，不管是恶意用户还是误操作的内部人员，都可能搞出乱子——比如创建大量垃圾表污染数据库，甚至如果映射逻辑里没有做严格的SQL参数化，还可能触发SQL注入攻击，直接威胁整个数据库的安全。就算是可信用户，也可能因为不熟悉数据库规范，创建出不符合要求的表结构。
• 维护与一致性灾难：动态生成的表往往没有统一的规范，比如字段类型、索引、约束这些都可能混乱不堪。时间一长，数据库里会堆满各种结构各异的“野表”，后续做数据查询、备份、迁移或者业务迭代时，维护成本会直线上升，还容易形成数据孤岛，没法和核心业务表做关联。
• 性能与资源浪费：过多的表会占用数据库的元数据资源，拖慢数据库的查询优化、备份恢复速度。如果导入的CSV数量大，生成的表太多，甚至可能影响整个数据库的运行性能。

改进的思路 #

如果要兼顾CSV导入的灵活性和系统稳定性，可以试试这些方案：

• 预定义标准表结构：提前根据业务需求创建好规范的目标表，导入映射只负责把CSV字段对应到已有表的字段，不允许动态建表。如果需要支持新的CSV格式，走审批流程由DBA或开发人员统一添加新表，保证结构的一致性和规范性。
• 用统一的中间存储：比如建一张通用的CSV数据存储表，字段可以包含csv_id、field_name、field_value、import_time等，所有导入的CSV数据都存在这张表里，后续通过视图或者ETL工具把数据转换到对应的业务表。这样既满足了不同CSV格式的需求，又能严格控制数据库schema的统一性。
• 如果必须动态建表（仅限特殊场景）：一定要加上严格的管控：
  • 只开放给高权限用户操作，比如管理员或指定的业务负责人
  • 对表名、字段名做严格校验，只允许字母、数字、下划线，禁止特殊字符
  • 强制给动态生成的表加统一前缀/后缀，比如csv_import_20240520_sales，方便识别和清理
  • 自动添加必要的约束，比如主键、字段类型限制，避免脏数据
  • 配置自动清理规则，定期删除过期的临时导入表

总之，除非是临时数据分析这类有严格管控的特殊场景，否则动态创建表的做法一定要尽量避免——优先选择预定义结构或统一存储的方案，才能平衡灵活性和系统的稳定性、安全性。

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