不知道当年SQL定义者们设计视图时是出于什么样的考虑。实际效果是，视图夹在SQL指令和表之间，成了一个三明治的结构。在这种结构下做检索，SQL
指令每次都要通过视图转换，才能作用到表上。如果不采用视图，跳过它，其实也能实现同样的效果。所以视图主要还是起到对用户屏蔽表结构的作用，另外还可以
做数据约束，此外就没有太多作用了。
在旧的关系数据库系统下，这还不是问题。因为集中计算的数据量和数据计算的开销都很有限，即使多一个"视图"这样的夹层，也不会有太多的影响。
换到大数据环境下，这就成了严重问题。目前大数据的数据量已经是关系数据库无法可拟的，加上更复杂的分布计算调度，涉及的计算机着实太多。目前极端情况 的分布计算，一次计算的节点数量已经超过万级。这个时候，计算过程中任何一点小的增量都会产生“蝴蝶效应”般巨大的影响。所以象“视图”这种可有可无的鸡 肋元素，在大数据环境里只会增加设计/开发/运行/维护的负担，而得不到太多实在的好处。这与大数据目前普遍追求的极简设计理念相悖，更增加了资源的损耗。因为这些原因，LAXCUS从一开始取消了视图，大数据时代，它确实应该休息了！
在旧的关系数据库系统下，这还不是问题。因为集中计算的数据量和数据计算的开销都很有限，即使多一个"视图"这样的夹层，也不会有太多的影响。
换到大数据环境下，这就成了严重问题。目前大数据的数据量已经是关系数据库无法可拟的，加上更复杂的分布计算调度，涉及的计算机着实太多。目前极端情况 的分布计算，一次计算的节点数量已经超过万级。这个时候，计算过程中任何一点小的增量都会产生“蝴蝶效应”般巨大的影响。所以象“视图”这种可有可无的鸡 肋元素，在大数据环境里只会增加设计/开发/运行/维护的负担，而得不到太多实在的好处。这与大数据目前普遍追求的极简设计理念相悖，更增加了资源的损耗。因为这些原因，LAXCUS从一开始取消了视图，大数据时代，它确实应该休息了！
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/30131349/viewspace-1468125/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
跨数据库的表操作
下一篇：
LAXCUS对数据存储的优化
请登录后发表评论
登录
全部评论
