0

我想定义很多视图,但是数据库的模型正在发生变化,所以我想到了一些想法/问题:

  1. MySQL 8 中是否有任何方法可以在 FROM 没有硬编码表名但表名是变量之后创建视图?

  2. 是否可以创建在 FROM 之后具有硬编码表名但列名是可变的视图?

  3. 在 FROM 之后创建一个视图 (A) 不是针对特定(硬编码)表名,而是另一个视图 (B) 作为中间转换表,它只是从表 (C) 中选择数据并给出它返回到视图 (A),其中列的别名与第一个视图 (A) 期望的方式相同。简而言之,第二个视图 (B) 在表名和列名方面只是充当 (A) <=> (C) 之间的翻译器?

我考虑这些解决方案的原因是我想为连接到数据库的应用程序提供一组表视图。它们不应该改变,但 DB 的整个模型会改变。

我不想触及作为应用程序接口的访问视图,而是在应用程序接口视图后面定义列和表之间的一些连接。此外,数据库模型将需要一些其他视图来进行常见的计算/报告,但计算/报告的源表数据将随着时间的推移而改变(列名、表名)。

  1. 我还有其他方法可以应用吗?在不破坏已经实现的报告和其他需要特定表和列名称的功能的情况下,您如何处理更改数据库中的表名、列名的情况?

我正在使用 MySQL 8。

4

1 回答 1

-1
  1. 您当然可以这样做,并且基于视图的视图并不少见。这是否是一个好主意,这是一个见仁见智的问题。
  2. 您无法完全保护应用程序免受底层数据模型更改的影响。如果您在数据模型中引入、删除或更改列/列,则必须在报告/应用程序中反映它们,因为可用内容会发生变化。如果表或列被重命名,则可以通过使用视图对应用程序隐藏。但是,如果重命名不是那么重要,以便您在报告/应用程序中反映这一点,那么它就会提出为什么需要重命名该列的问题。

如果您的数据结构变化如此频繁,那么基于 SQL 的产品可能不适合您,因为 SQL 需要对数据结构进行非常严格的定义。您可能不得不考虑使用 NoSql 解决方案,以在数据库模式中提供更大的灵活性。但是,即使您使用 NoSql 解决方案,数据结构的更改也会影响应用程序/报告。

于 2019-03-25T21:45:08.520 回答