何时使用View而不是Table?

bev*_*qua 98 sql database-design view

应该何时在实际的表上使用View?我应该期望这会产生什么收益?

总的来说,在表格上使用视图有什么好处?我不应该以视图首先看起来的方式设计表格吗?

Luk*_*der 73

哦,你需要考虑很多不同之处

选择意见:

  1. 视图提供了对表的抽象.您可以在视图中轻松添加/删除字段,而无需修改基础架构
  2. 视图可以轻松地为复杂连接建模.
  3. 视图可以隐藏您特定于数据库的内容.例如,如果您需要使用Oracles SYS_CONTEXT函数或许多其他功能进行一些检查
  4. 您可以直接在视图上轻松管理GRANTS,而不是实际的表.如果您知道某个用户只能访问视图,则更容易管理.
  5. 视图可以帮助您向后兼容.您可以更改基础架构,但视图可以隐藏某个客户端的这些事实.

插入/更新的视图:

  1. 您可以直接在视图中使用Oracle的"WITH CHECK OPTION"子句等功能来处理视图的安全问题

缺点

  1. 你丢失了有关关系的信息(主键,外键)
  2. 您是否能够插入/更新视图并不明显,因为视图会隐藏其基础连接

  • @ouonomos:普通视图不包含任何数据.它只是一个存储的SQL语句,即基础数据的视图.某些数据库(例如Oracle,PostgreSQL)支持物化视图,这些视图将"视图"临时存储在另一个表中以便更快地访问.这样做是为了在视图复杂时加快读取访问.但是这对你的情况没有帮助,因为物化视图仍然是一个视图,而不是数据本身.你的方法可能没问题. (8认同)
  • 快速问题:视图是"永久性的",还是只持续会话的生命周期?我问的原因:我们有一个系统,有时会在长代码运行过程中出现故障.我通过将部分代码咬入中间表来缓解这种情况,从而节省了中间结果.因此,如果系统在代码完成之前进行调用,我只需要从上次保存的临时表开始提取.如果他们提供相同的持久性,我可能会转而使用视图.否则我会继续这样做,并在运行结束时删除临时值.谢谢! (3认同)

Pau*_*sik 41

意见可以:

  • 简化复杂的表结构
  • 允许您过滤敏感数据并以更简单的方式分配权限,从而简化您的安全模型
  • 允许您在不更改输出结构的情况下更改逻辑和行为(输出保持不变,但基础SELECT可能会发生显着变化)
  • 提高性能(Sql Server索引视图)
  • 使用可能难以收集的视图提供特定的查询优化

而且您不应该设计表来匹配视图.您的基础模型应该关注数据的高效存储和检索.视图部分是一种工具,通过允许您抽象复杂性来减轻高效,规范化模型所带来的复杂性.

另外,询问"在桌面上使用视图有什么好处?"并不是一个很好的比较.你不能没有桌子,但你可以不用看法.它们各自存在的原因完全不同.表是具体的模型,视图是抽象的,好的,视图.

  • +1 视图部分是一种工具,它允许您抽象复杂性,从而减轻由高效、规范化模型引起的复杂性。 (2认同)

HLG*_*GEM 32

当您需要确保每次都遵循复杂的逻辑时,视图是可以接受的.例如,我们有一个视图,可以创建所有财务报告所需的原始数据.通过让所有报告都使用此视图,每个人都使用相同的数据集,而不是使用一组联接的一个报告,另一个忘记使用一个提供不同结果的报告.

如果要将用户限制为特定的数据子集,则可以接受视图.例如,如果您不删除记录但仅将当前版本标记为活动而旧版本标记为非活动,则您希望视图用于仅选择活动记录.这可以防止人们忘记将where子句放在查询中并获得错误的结果.

视图可用于确保用户只能访问一组记录 - 例如,特定客户端的表视图以及表上没有安全权限可能意味着该客户端的用户只能看到数据对那个客户.

重构数据库时,视图非常有用.

使用视图调用视图时,视图是不可接受的,这会导致可怕的性能(至少在SQL Server中).我们几乎失去了一个价值数百万美元的客户端,因为有人选择以这种方式抽象数据库并且性能非常糟糕且超时频繁.我们也必须支付修复费用,而不是客户,因为性能问题完全是我们的错.当视图调用视图时,它们必须完全生成基础视图.我已经看到了这个视图称为视图的视图,该视图调用视图并生成了数百万条记录,以便查看最终需要的三个用户.我记得其中一个视图用了8分钟来完成记录的简单计数(*).查看调用视图是一个非常糟糕的主意.

用于更新记录通常是一个坏主意,因为通常只能更新同一个表中的字段(同样这是SQL Server,其他数据库可能会有所不同).如果是这种情况,那么直接更新表格更有意义,以便您知道哪些字段可用.

  • 你的意思是成功吗? (3认同)
  • 不知道视图调用视图存在性能问题。这似乎很奇怪。这不是由查询优化器正确处理的吗?您的案例中使用了哪个版本的 SQL Server? (2认同)

Ode*_*ded 7

当您需要从多个表中进行选择或仅获取表的子集时,视图很方便.

您应该以这样的方式设计表,以使数据库正常化(最小重复).这可能使查询有点困难.

视图有点分离,允许您以不同的方式查看表中的数据.


TTo*_*oni 7

通常的做法是在视图中隐藏连接以向用户呈现更加非规范化的数据模型.其他用途涉及安全性(例如通过隐藏某些列和/或行)或性能(在物化视图的情况下)


Pat*_*rez 6

您应该在不考虑视图的情况下设计表格.
除了保存连接和条件之外,Views还具有性能优势:SQL Server可以在视图中计算并保存其执行计划,因此比"即时"SQL语句更快.
View还可以简化您在现场级别的用户访问工作.


Lou*_*adi 6

根据维基百科

与表相比,视图可以提供许多优势:

  • 视图可以表示表中包含的数据的子集
  • 视图可以限制底层表暴露于外部世界的程度:给定用户可能有权查询视图,但拒绝访问基表的其余部分。

  • 视图可以将多个表连接并简化为单个虚拟表。

  • 视图可以充当聚合表,其中数据库引擎聚合数据(总和、平均值等)并将计算结果作为数据的一部分呈现。

  • 视图可以隐藏数据的复杂性。例如,视图可以显示为 Sales2000 或 Sales2001,透明地对实际基础表进行分区。

  • 视图占用很少的空间来存储;数据库只包含视图的定义,而不是它所呈现的所有数据的副本。

  • 视图可以提供额外的安全性,具体取决于所使用的 SQL 引擎。


fas*_*seg 5

首先,顾名思义,视图是不可变的.这是因为视图只是从DB中存储的查询创建的虚拟表.因此,您有一些观点特征:

  • 您只能显示数据的子集
  • 您可以将多个表连接到一个视图中
  • 您可以在视图中聚合数据(选择计数)
  • view实际上并不包含数据,因为它们是底层表的虚拟聚合,所以它们不需要任何表空间

因此,有大量的用例比视图更适合视图,只考虑只在网站上显示活跃用户.视图会更好,因为您只对数据库中实际存在的数据子集(活动和非活动用户)进行操作

看看这篇文章

希望这有帮助..