优化分层数据的视图
我目前有一个包含自连接的查询，用于从使用嵌套集模型存储公司组织信息的表中查询员工的所有直接和间接管理者。 在这个SQL表示法中，以冒号（例如：1）开头的数字是变量：
select parent.empid, parent.depth from RelationshipMgr as node join
RelationshipMgr as parent on node.lft between parent.lft and parent.rgt
and node.empid = :1 order by parent.lft
通过将parent.depth = node.depth - :2到连接条件或where子句（侧面问题：哪个更快？），我可以轻而易举地仅返回管理员在员工上方的ID。
问题：我试图把这个查询变成一个视图，我没有太多的运气。 问题是我的大部分或全部变量都处于查询的连接条件中。 我现在最好的计划是将这些部分分解成列，然后我可以在查询视图时使用where子句，例如：
select node.EmpID, parent.empid as MgrID, parent.depth as MgrDepth,
node.depth - parent.depth as MgrRelativeAltitude from RelationshipMgr as node
join RelationshipMgr as parent on node.lft between parent.lft and parent.rgt
你可以看到我不得不发明MgrRelativeAltitude列，以便能够找到经理级别以上的员工ID，但这不是最大的问题。 我担心这会造成严重的性能问题，因为SQL Server似乎按照连接条件指定的方式完成全连接，然后通过where子句进行过滤，而不是智能地使用where子句来限制连接。 有没有更好的方法来创建视图？ 我是否应该将此作为查询而忘记了查看视图？ 我可以通过将其存储到存储过程而不是视图来获得任何东西吗？
请不要说“过早的优化是邪恶的......”这并不是不成熟的。 我正在取代的实施使用的东西就像一个混杂的邻接表，有一个关于雇员直接和间接管理者的记录......最差的O（n ^ 2）记录，并且可预见地遇到了严重的性能问题我们在层次结构中拥有超过30万名员工。 我的新嵌套集实现将减轻这些性能问题，除了这一个查询...如果您在提出的视图上执行select * ，结果将与我试图替换的旧表几乎相同，非常关心我。
您正试图确定非相邻节点的层次关系。 如你所见，这是一个相对昂贵的运行时间计算，查看或定期查询。 相反，如果经常运行，我会建议创建所谓的桥接表 - 无论是作为通过触发器更新的实际表，还是作为SQL Server 2005+中的索引视图（虽然还没有尝试索引视图方法）。 值得注意的是，与邻接列表相比，嵌套集提供了优越的读取时间。
折衷是一个表格，其行数远远多于源，因为它有效地代表了所有节点之间的关系，这些关系减慢了写入速度，因为它更新了添加，删除或父标识符更改的任何时间。 作为回报，您可以对其进行索引并实现快速检索时间。 一个优化，如果更新桥证明是一个瓶颈，通过一个存储过程来访问这个桥，这个桥可以作为缓存来用于频繁运行的输入组合，但是可以在运行时计算不常见的情况。 您需要评估底层节点表的读取频率和写入频率以作出决定。
这里提供了用于在RDBMS中表示分层数据的选项的概述。
链接地址: http://www.djcxy.com/p/16789.html