12

我有一个规范化的数据库，外键/主键提供一对多的数据库。

我打算用 PHP 访问这个数据库以进行基本的前端/后端显示。现在，我的问题来自这两个示例查询：

CREATE VIEW `view` AS
  SELECT
    functiondetails.Detail,
    functionnames.ID,
    functionnames.FunctionName,
    functionnames.Catogory
  FROM functiondetails
    INNER JOIN functionnames ON functiondetails.AsscID = functionnames.ID

或者

SELECT
  functiondetails.Detail,
  functionnames.ID,
  functionnames.FunctionName,
  functionnames.Catogory
FROM functiondetails
  INNER JOIN functionnames ON functiondetails.AsscID = functionnames.ID

查询中没有错误，因为我两次都没有失败，但我的总体问题是：

如果我打算不断地从我的数据库中引用大量信息。创建一个视图会不会更容易，然后它将一直使用新添加的信息进行更新，或者在我的实际 php 上进行第二个查询是否更好。示例：

$Query = $MySQli->prepare("
  SELECT
    functiondetails.Detail,
    functionnames.ID,
    functionnames.FunctionName,
    functionnames.Catogory
  FROM functiondetails
    INNER JOIN functionnames ON functiondetails.AsscID = functionnames.ID
")
$Query->execute();
$Results = $Query->fetch_results();
$Array = $Results->fetch_array(MYSQLI_ASSOC);

还是从我的观点中选择？

$Query = $MySQLi->prepare("SELECT * FROM `view`");
$Query->execute();
$Results = $Query->fetch_results();
$Array = $Results->fetch_array(MYSQLI_ASSOC);

那么哪一个是用于查询我的数据库的更好方法呢？

4

5 回答 5

6

视图是一个抽象层，创建抽象层的通常原因是为您提供一个让您的生活更轻松的工具。

使用视图的一些重大优势包括：

  1. 安全性
    您可以控制谁有权查看而不授予他们访问基础表的权限。

  2. 澄清
    很多时候，列标题并不像它们可以描述的那样具有描述性。视图允许您增加返回数据的清晰度。

  3. 性能
    性能方面，观点不会对您造成负面影响。但是，由于 MySQL 不支持物化视图，因此您不会看到使用视图的性能提升。

  4. 易于编码
    视图可用于重用复杂查询，减少用户错误的空间。

  5. 易于管理
    每当您的表架构发生变化时，它都会让您的生活更轻松。

    例如，假设您有一张包含待售房屋的表格homes_for_sale，但后来您决定希望该表格处理您曾经有过待售/当前待售的所有房屋，all_homes. 显然，新表的模式与第一个表大不相同。

    如果您有大量查询来自homes_for_sale，现在您必须检查所有代码并更新所有查询。这会让您面临用户错误和管理噩梦。

    解决更改的更好方法是用同名视图替换表。视图将返回与原始表完全相同的架构，即使实际架构已更改。然后，如果需要，您可以按照自己的节奏浏览您的代码，并更新您的查询调用。

于 2013-08-28T18:31:48.460 回答
5

您可能假设 MySQL 将视图的结果存储在某处，并随着基础表中的数据更改而更新该结果。MySQL 不这样做。查询视图与运行查询完全相同。

但它甚至可能比运行裸 SQL 查询的性能更差，因为 MySQL 可能会将基本查询的结果累积在一个临时表中，这样您就可以在查询中针对视图使用更多的 SQL 子句。我说“可能”是因为它因视图算法而异。

请参阅http://dev.mysql.com/doc/refman/5.6/en/view-algorithms.html了解 MySQL 如何使用“合并”算法或“临时”算法来执行视图。

如果你想要物化视图，有一个名为FlexViews的工具可以维护物化视图：

Flexviews 是 MySQL 的物化视图实现。它包括一个简单的 API，用于创建物化视图并刷新它们。使用 Flexviews 的优点是物化视图是增量刷新的，也就是说，通过使用记录数据库表更改的特殊日志来有效地更新视图。Flexviews 包括创建和维护这些日志的工具。Flexviews 创建的视图包括对 JOIN 和所有主要聚合函数的支持。

于 2013-08-28T19:03:26.337 回答
5

如果您是以下情况，则最好创建视图：

  • 确定所需的列
  • 也想在其他地方重用您的视图
  • 你喜欢以抽象的方式编码。（隐藏技术细节）
  • 需要通过在其上创建索引来快速访问。
  • 对少数用户的特定访问（点来自评论）
于 2013-08-26T12:35:28.503 回答
4

视图只是一个存储的文本查询。您可以对其应用 WHERE 和 ORDER，执行计划将在考虑这些子句的情况下计算。如果您想保持代码“干净”，我认为这将很有用。您需要记住的是修改视图有点困难，因此如果您不太确定列，或者后者会更改，请坚持查询。

关于性能是一样的！

此致！

于 2013-08-28T18:10:17.327 回答
3

在性能方面它们应该是相同的，但出于一些实际原因，视图更好。

我更喜欢视图，因为它通过在一个地方更改它们来鼓励更好地重用和重构复杂查询，而不是在多个地方使用查询时必须在任何地方复制粘贴新版本。

此外，针对视图运行更新查询看起来更简洁、更简单，但请注意，有时您无法更新视图中属于不同基础表的多个列。因此，如果您必须更新 2 个不同的列，则必须运行两个不同的更新查询。

使用视图也很有意义，因为您将复杂的数据库逻辑卸载到它所属的数据库中，而不是将其构建到您的应用程序代码中。

使用视图的缺点是，如果您没有准备好数据库管理工具，那么设置可能需要更长的时间。此外，如果您有很多视图，您可能必须想出一些方法来组织和记录它们。如果视图开始建立在其他视图之上，这将变得更加复杂。因此，您必须提前计划并维护依赖关系。

于 2013-08-28T18:23:03.227 回答