SQL视图与数据库抽象(在代码中)

| 我刚刚了解了SQL视图,这看起来不错,但是如果我将抽象表连接到数据访问类,这会不会完成同样的事情?您对此有何想法?我以前从未使用过视图,所以这对我来说是很新的。     
已邀请:
        请记住,并非所有命中您数据库的应用程序都可能使用相同的数据访问类。它们也没有用于导出或报告中。如果您希望保持一致,则视图是抽象一些复杂事物(例如如何获取某些种类的财务信息)的更好的地方。但是,也不要过度抽象任何东西到视图。视图不应调用视图(至少在Sql Server中,但我怀疑在其他数据库中也是如此),因为您必须实例化所有基础视图才能在顶层获得数据。这意味着要获得所需的三个记录,您可能最终会首先实现数百万条记录。对于大桌子,这可能会造成噩梦般的性能问题。当需要修复某些问题时,调用视图的其他视图将成为一个真正困难的维护问题。     
        视图的主要目的是抽象创建特定结果集的复杂性。在大型关系数据库中,您通常需要将许多表连接在一起以获得有用的数据。通过创建视图,任何客户端都可以访问它而无需访问您的数据库访问层。 此外,几乎所有RDMS都将通过缓存已解析的执行计划来优化视图。如果查询足够复杂,则执行查询时可能会遇到大量查询计划命中。但是,对于视图,查询计划是在创建视图或首次使用时创建并保存的。 视图对于保持向后兼容性也很有用。假设您有一个需要更改的表,但是很难一次更新所有客户端以使用新的表架构。您可以使用旧表名创建一个提供向后兼容性的视图。然后,您可以使用新架构创建新表。     
        我想说,视图的主要目的之一是简化复杂数据库(无论是星型架构/ OLTP)和另一层(用户/ OLAP多维数据集/报告界面)之间的接口。 大概我想说的是,如果可以通过多种方式访问​​数据库(MS Excel / .net应用程序),那么您将希望使用SQL视图,因为它们对所有人都可用,否则,如果您创建了c#中的数据访问类(例如),则MS Excel人员将无法使用它。     
        简单地放置视图,可以减少sql查询中放在一起的所有联接的复杂外观。 因此,一个视图可以对30个表进行联接,而不是对30个表执行联接,但是可以在另一个视图/ sproc中重用它来简单地说:
SELECT * FROM myView
而不是:
SELECT...
FROM
...
INNER JOIN
...
INNER JOIN
...
INNER JOIN
...
它基本上隐藏了所有这些细节。本文应该是一个很好的参考:http://www.craigsmullins.com/cnr_0299b.htm 关键是视图不是物理结构,它们只是数据库系统中一个或多个表的关系模型或“视图”。     
        抽象联接到数据访问类可能会为您提供相同的数据,但可能不会为您提供相同的性能。 同样,对于大多数企业而言,数据库是共享资源。明智的做法是假设已经有一些应用程序无法访问或无法通过您的数据访问类访问数据库。明智的做法是,假设某些将来的应用程序无法或不会通过您的数据访问类。举一个简单的例子,您使用的任何dbms的命令行界面和图形界面都不会使用数据访问类。 视图也是SQL数据库实现逻辑数据独立性的方式。将它们视为公共接口的一部分。     
        可以由交互式SQL用户,报表编写器,OLAP工具和用不同语言编写的应用程序共享视图,也可以由不与其他eahc共享类的多个编程团队共享视图。 因此,这是数据库设计人员在整个数据用户社区中共享标准化查询的好方法。     

要回复问题请先登录注册