这样的表结构应该怎么办

2012-12-26

这样的表结构应该怎么处理这个是视图，里面的D00_06是员工表，因为有许多字段都是员工比如fzr负责人，tbr填表

这样的表结构应该怎么处理

这个是视图，里面的D00_06是员工表，因为有许多字段都是员工比如fzr负责人，tbr填表人，jcr检查人等等，总觉得这样的表结构不够好，而且目前已经有1w多数据，每月2、3千条增长，现在从视图中select全部要9秒左右，该怎么优化呢？
[最优解释]
alter view V_TEST
as
select ID,....,(select ygxm from d00_06 where ygno=fzr) as fzrxm,....
from D04_11

这样速度应该更快
[其他解释]
不用视图会更快，但是会不会对编码带来难度，就要评估了
[其他解释]
聚集索引 ygno 这个，2楼方法试试
[其他解释]

引用:

这个是视图，里面的D00_06是员工表，因为有许多字段都是员工比如fzr负责人，tbr填表人，jcr检查人等等，总觉得这样的表结构不够好，而且目前已经有1w多数据，每月2、3千条增长，现在从视图中select全部要9秒左右，该怎么优化呢？

其实不一定全部要关联的,做erp经常会用到什么制单人,审核人之类不重要的人名,你可以直接将用户姓名取来存在那个单据里呀,不一定要把id存在单据里再去关联,意义不大,除非非常重的!
[其他解释]
适当冗余啊。这么多小分表。
[其他解释]
冗余太大，那些什么人什么人的，拆到一个类型表，需要的时候再关联
[其他解释]
不管是什么负责人、填表人还是检查人，都是员工，都关联员工表显示就是了，要分那么多小表干嘛？
另外才几万条select就要9秒了？检查下索引设置，检查下是否优化了查询代码？如果查询本身很复杂，就别搞视图了，还不如直接查询基表呢
[其他解释]

引用:

不管是什么负责人、填表人还是检查人，都是员工，都关联员工表显示就是了，要分那么多小表干嘛？
另外才几万条select就要9秒了？检查下索引设置，检查下是否优化了查询代码？如果查询本身很复杂，就别搞视图了，还不如直接查询基表呢

本身一定是员工表，小表是视图虚拟出来的吧
[其他解释]

引用:

引用:不管是什么负责人、填表人还是检查人，都是员工，都关联员工表显示就是了，要分那么多小表干嘛？
另外才几万条select就要9秒了？检查下索引设置，检查下是否优化了查询代码？如果查询本身很复杂，就别搞视图了，还不如直接查询基表呢
本身一定是员工表，小表是视图虚拟出来的吧

这里确实是在建视图，那些小表是join的时候虚拟的，现在是希望先建一个包含工号姓名等全部信息的视图，然后再在视图里查询，所以感觉是不是视图应该优化一下？直接用2楼的那种还是join哪个更快呢？另外索引要怎么设置？
[其他解释]

引用:

不用视图会更快，但是会不会对编码带来难度，就要评估了

确实会影响编码，主要是整体结构的统一性，别的都是从视图里查的
[其他解释]

引用:

聚集索引 ygno 这个，2楼方法试试

ygno本身是D00_06表的主键,已经是聚集索引了,2楼的方法试了,速度好像差不多(9秒那个时间是查询全部记录的,有where id=9之类的时候还是挺快的1秒左右。
[其他解释]

引用:

引用:这个是视图，里面的D00_06是员工表，因为有许多字段都是员工比如fzr负责人，tbr填表人，jcr检查人等等，总觉得这样的表结构不够好，而且目前已经有1w多数据，每月2、3千条增长，现在从视图中select全部要9秒左右，该怎么优化呢？

其实不一定全部要关联的,做erp经常会用到什么制单人,审核人之类不重要的人名,你可以直接将用户……

这倒是个办法，有时候适当的冗余更快一点，唉，就是改动大点了
[其他解释]

引用:

适当冗余啊。这么多小分表。

确实，适当冗余，员工可以的话搞个类型表。

热点排行

SQL Server

这样的表结构应该怎么办