MySQL CREATE VIEW 定位变量 table 名称（列名称）
MySQL CREATE VIEW targeting variable table name (columns names)
我想定义很多视图，但数据库的模型正在改变，所以我想到了一些 ideas/questions：
MySQL 8 中有没有什么方法可以创建在 FROM 没有硬编码 table name 但 table name 是变量之后的视图？
是否可以在 FROM 之后创建具有硬编码名称 table 但列名称可变的视图？
创建一个视图 (A) 是不是一个好主意，它在 FROM 之后不针对特定的（硬编码）table 名称，而是作为中间翻译的另一个视图 (B) table 只处理来自 table (C) 的 select 数据，并将其返回给视图 (A)，其中列的别名与第一个视图 (A) 期望的方式相同。简而言之，第二个视图 (B) 只是在 table 名称和列名称方面充当 (A) <=> (C) 之间的翻译器？
我考虑这些解决方案的原因是我想为连接到数据库的应用程序提供一组 table 视图。它们不应该改变，但 DB 的整个模型将会改变。
我不想触及作为应用程序界面的访问视图，而是在应用程序界面视图后面定义列和 tables 之间的一些连接。此外，数据库模型将需要一些其他视图来执行常见的 calculations/reporting，但是 calculations/reporting 的源 table 数据将随着时间的推移而改变（列名，table 名称）。
- 我可以应用任何其他方法吗？您如何处理更改 table 名称、数据库中的列名称而不破坏已经实现的报告和其他需要特定名称 table 和列的功能的情况？
我正在使用 MySQL 8.
- 没有
- 没有
- 你当然可以做到这一点，基于观点的观点并不少见。好不好，见仁见智。
- 您无法完全保护应用程序免受底层数据模型更改的影响。如果在数据模型中引入、删除或更改列/列，则必须在报告/应用程序中反映它们，因为可用内容会发生变化。如果 table 或列被重命名，可以通过使用视图从应用程序中隐藏它。但是，如果重命名不是那么重要，以至于您会在报告/应用程序中反映出来，那么就会回避为什么需要重命名该列的问题。
如果您的数据结构变化如此频繁，那么基于 SQL 的产品可能不适合您，因为 SQL 需要非常严格的数据结构定义。您可能不得不考虑使用 NoSql 解决方案，以在数据库模式中提供更大的灵活性。但是，即使使用NoSql解决方案，数据结构的变化也会影响应用程序/报告。
我想定义很多视图，但数据库的模型正在改变，所以我想到了一些 ideas/questions：
MySQL 8 中有没有什么方法可以创建在 FROM 没有硬编码 table name 但 table name 是变量之后的视图？
是否可以在 FROM 之后创建具有硬编码名称 table 但列名称可变的视图？
创建一个视图 (A) 是不是一个好主意，它在 FROM 之后不针对特定的（硬编码）table 名称，而是作为中间翻译的另一个视图 (B) table 只处理来自 table (C) 的 select 数据，并将其返回给视图 (A)，其中列的别名与第一个视图 (A) 期望的方式相同。简而言之，第二个视图 (B) 只是在 table 名称和列名称方面充当 (A) <=> (C) 之间的翻译器？
我考虑这些解决方案的原因是我想为连接到数据库的应用程序提供一组 table 视图。它们不应该改变，但 DB 的整个模型将会改变。
我不想触及作为应用程序界面的访问视图，而是在应用程序界面视图后面定义列和 tables 之间的一些连接。此外，数据库模型将需要一些其他视图来执行常见的 calculations/reporting，但是 calculations/reporting 的源 table 数据将随着时间的推移而改变（列名，table 名称）。
- 我可以应用任何其他方法吗？您如何处理更改 table 名称、数据库中的列名称而不破坏已经实现的报告和其他需要特定名称 table 和列的功能的情况？
我正在使用 MySQL 8.
- 没有
- 没有
- 你当然可以做到这一点，基于观点的观点并不少见。好不好，见仁见智。
- 您无法完全保护应用程序免受底层数据模型更改的影响。如果在数据模型中引入、删除或更改列/列，则必须在报告/应用程序中反映它们，因为可用内容会发生变化。如果 table 或列被重命名，可以通过使用视图从应用程序中隐藏它。但是，如果重命名不是那么重要，以至于您会在报告/应用程序中反映出来，那么就会回避为什么需要重命名该列的问题。
如果您的数据结构变化如此频繁，那么基于 SQL 的产品可能不适合您，因为 SQL 需要非常严格的数据结构定义。您可能不得不考虑使用 NoSql 解决方案，以在数据库模式中提供更大的灵活性。但是，即使使用NoSql解决方案，数据结构的变化也会影响应用程序/报告。