U9业务架构SQL Server 2008SOA技术实践

高并发场景下的 ERP 系统开发，SQL Server 2008 其实还挺能打的。4000 多张业务表、数据库常态在 40GB 以上，还要留着 3 年以上的客户数据——没两把刷子可搞不定。平台框架、元数据管理、ERP 模块组件这些都搞得比较细，像 3NF 到 4NF 的规范也没落下。 SQL Server 2008做 SOA 架构其实也还不错，尤其是你习惯搞模块化、组件化那一套，扩展起来顺手。性能方面，结合一些 XML 优化手段，查询响应也挺快的，尤其你在调接口时多注意字段索引和查询计划，差不多就能压住高并发。 你要真想玩深点，可以看看这几个方向：像MySQL高并发优化的套路，有些点在 SQL

行版本快照的读已提交机制，在做高并发业务系统时挺实用的。以前在 SQL Server 2005 之前，读写一冲突就卡住，想提高性能只能用脏读，多少有点不放心。后来版本支持从 Tempdb 拿快照，直接读已提交数据，查询不再被更新锁住，响应也快，数据也干净。你要是做基于 SQL Server 的大型管理系统，建议早点把快照开了。尤其那种一个事务动不动几十行更新的业务，用快照能稳住用户体验，还省了不少锁相关的 bug。文章里还列了事务没启用快照和启用后的差异，对照表蛮直观的。像 begin tran 和 select 之间行为的变化，看一眼你就明白为啥值得开启。另外，这里还有几个相关链接挺有意思的

在U9数据表中，业务主键作为唯一性索引，使用非聚集唯一索引方式维护数据的唯一性。 当自定义业务导致业务主键超过SQL Server 16个索引键限制时，可使用持久化计算列将多个业务字段拼合为一列，建立唯一性索引来保证数据唯一性。 但拼接后的计算列长度可能超过SQL Server索引键900字节限制。

U9分页算法实现前，分页模式未经优化：选择，rownumber从（选择，在MainTable A left join DictTable1 as D1 on (A.DictID1=D1.ID) left join DictTable2 as D2 on (A.DictID2=D2.ID) …. left join DictTableN as DN on (A.DictIDN=DN.ID) ) T Where T. rownumber> 10000 and T. rownumber

在U9ERP系统中，为了展开BOM（物料清单），我们提供了详细的SQL脚本。这些脚本可以直接在系统中使用，帮助用户快速完成BOM展开操作。

下载用友U9数据字典，获取详细的业务数据和操作指南。

计算U9用户密码

XML优化硬编码SQL的挑战：在U9系统中，常见硬编码SQL例如tselect * from table_a where id in (xxx,xxx…)存在性能问题，无法重用查询计划。由于IDList数目不同，SQL查询计划难以重用，尤其是大于3M的SQL文本解析开销甚至超过执行查询本身。

SQL Server 2008应用实践是数据库管理和优化的关键。