34,576
社区成员
发帖
与我相关
我的任务
分享请教(讨论),大型表的设计
现有进销存的数据库，单表记录在6千万以上,每月增长1千万左右(数据最少得保留半年才能移走)，原因是不同类型的数据，都存放在同一个表里，通过类型字段区分交易类型。
现在要对数据库重新设计。然经验尚浅，唯有向各位前辈请教！
由于业务性质，每一笔新交易都要通过计算之前的各种交易来得到当前真实的库存,运算量比较大，并发量高时系统慢得不行。我想通过把不同的交易类型，分开到不同的表里存放，然后再通过视图把几组表联接起来(union all),不知是否可行？还是运用SQL Server本身的分区技术，把大表切成n个小表？
在此，诚心向各位高人请教，肯请指点一二，谢谢!
现在要对数据库重新设计。然经验尚浅，唯有向各位前辈请教！
由于业务性质，每一笔新交易都要通过计算之前的各种交易来得到当前真实的库存,运算量比较大，并发量高时系统慢得不行。我想通过把不同的交易类型，分开到不同的表里存放，然后再通过视图把几组表联接起来(union all),不知是否可行？还是运用SQL Server本身的分区技术，把大表切成n个小表？
在此，诚心向各位高人请教，肯请指点一二，谢谢!
...全文
请发表友善的回复…
发表回复
九章落地 2010-05-14
- 打赏
- 举报
三易通软件(三易通服装进销存软件，三易通服装进销存管理软件，三易通服装进销存管理系统，三易通服装店管理软件，三易通服装店管理系统，三易通服装销售管理软件，三易通服装销售管理系统，三易通服装零售管理软件，三易通服装零售管理系统，三易通服装店软件，三易通服装店收银软件)
三易通服装进销存软件(服装店管理系统),非常简单好用的服装店软件!
三易通官网:http://www.3etsoft.cn
三易通软件（pos系统，收银软件，服装仓库管理软件，三易通服装零售软件，POS收银软件，三易通服装店收银软件，服装批发软件，三易通服装专卖店管理软件，服装营销管理系统，服装软件，鞋业销售管理软件，服装收银系统，三易通服装销售管理软件，鞋服管理软件，服装分销管理软件，服装营销软件，POS管理软件，三易通服装管理软件，三易通服装店软件，专卖店管理软件，三易通服装店管理系统，服装鞋帽软件，三易通服装进销存软件，鞋业软件，三易通服装店管理软件，服装进销存管理系统，服装鞋帽管理软件，三易通鞋店管理软件，服装鞋帽管理系统，服装分销系统，服装进销存系统，服装销售管理系统，服装库存管理软件）
三易通软件介绍:http://www.3etsoft.cn/Channel.Asp?ID=1
三易通服装进销存软件(服装店管理系统),非常简单好用的服装店软件!
三易通官网:http://www.3etsoft.cn
三易通软件（pos系统，收银软件，服装仓库管理软件，三易通服装零售软件，POS收银软件，三易通服装店收银软件，服装批发软件，三易通服装专卖店管理软件，服装营销管理系统，服装软件，鞋业销售管理软件，服装收银系统，三易通服装销售管理软件，鞋服管理软件，服装分销管理软件，服装营销软件，POS管理软件，三易通服装管理软件，三易通服装店软件，专卖店管理软件，三易通服装店管理系统，服装鞋帽软件，三易通服装进销存软件，鞋业软件，三易通服装店管理软件，服装进销存管理系统，服装鞋帽管理软件，三易通鞋店管理软件，服装鞋帽管理系统，服装分销系统，服装进销存系统，服装销售管理系统，服装库存管理软件）
三易通软件介绍:http://www.3etsoft.cn/Channel.Asp?ID=1
Scarroot 2008-03-19
- 打赏
- 举报
mark
rfq 2008-03-06
- 打赏
- 举报
建议任何技术都是解决问题的方式，具体问题具体分析。
最好试验一下。分区技术和利用文件组并行读写 都可以试一下；
我的感觉分区要好一些
最好试验一下。分区技术和利用文件组并行读写 都可以试一下；
我的感觉分区要好一些
jxwangjm 2008-03-06
- 打赏
- 举报
Mark一下
flairsky 2008-03-05
- 打赏
- 举报
硬件过关的话就用数据库自带的分组分区好了，存放在不同硬盘上
每月一张表，每张表的分区方式一样，你查的时候也可以用一句sql就能查，性能会提高很多
每月一张表，每张表的分区方式一样，你查的时候也可以用一句sql就能查，性能会提高很多
九章落地 2008-03-04
- 打赏
- 举报
TO w2jc:
谢谢!
我也正在查阅数据同步这方面的资料!
感谢各位高人各抒己见,使我受益良多!
若按月份来切分大表,有两种方式:分区表(sql 2005),物理表(tblTrans1-tblTrans12),哪种方式比较高效且简单可行呢?您们喜欢采用哪种方式设计这样的大表呀?
谢谢!
我也正在查阅数据同步这方面的资料!
感谢各位高人各抒己见,使我受益良多!
若按月份来切分大表,有两种方式:分区表(sql 2005),物理表(tblTrans1-tblTrans12),哪种方式比较高效且简单可行呢?您们喜欢采用哪种方式设计这样的大表呀?
w2jc 2008-03-04
- 打赏
- 举报
SQL有什么好方法,两个库几分钟便能同步一次呢?
---------------------------------------------
SQL 2000企业版: 1) 日志传送，2) 复制
SQL 2005企业版：1) 日志传送，2) 复制，3）数据库镜像
（上面这些是MSSQL自带的，还有一些第三方的方案，但不清楚细节）
这3种技术都可以实现数据同步，
1）和2）比较好的情况下可以做到每5分钟同步一次（更快的同步频率没试过，系统开销有点大了），
1）的配置简单一些，2）有好几种配置方式，
3）是2005的新特性，也有2种基本配置方式，两个数据库是完全同步的（但镜像库也是只读的）
建议LZ看一下关于SQL高可用性和数据同步方面的专题，这个还是有点复杂，
每种方法都有优缺点，要针对不同的需求做选择。
我比较喜欢用日志传送，从很早的MSSQL版本就有了，非常成熟的技术，
但是接收日志传送的目标数据库必须处于只读状态下。
---------------------------------------------
SQL 2000企业版: 1) 日志传送，2) 复制
SQL 2005企业版：1) 日志传送，2) 复制，3）数据库镜像
（上面这些是MSSQL自带的，还有一些第三方的方案，但不清楚细节）
这3种技术都可以实现数据同步，
1）和2）比较好的情况下可以做到每5分钟同步一次（更快的同步频率没试过，系统开销有点大了），
1）的配置简单一些，2）有好几种配置方式，
3）是2005的新特性，也有2种基本配置方式，两个数据库是完全同步的（但镜像库也是只读的）
建议LZ看一下关于SQL高可用性和数据同步方面的专题，这个还是有点复杂，
每种方法都有优缺点，要针对不同的需求做选择。
我比较喜欢用日志传送，从很早的MSSQL版本就有了，非常成熟的技术，
但是接收日志传送的目标数据库必须处于只读状态下。
ojuju10 2008-03-04
- 打赏
- 举报
我个人认为，将大表按业务逻辑分成小表，
在个别大的小表里面用到05的分区表
最后考虑在表的关键字段上建立索引
九章落地 2008-03-04
- 打赏
- 举报
w2jc,您说的很有道理!
我们现在已经有一个专门跑报表的销售分析系统,并用套帐的方式一年一个库,数据量大,只能每天晚上同步一次,大的报表,基本上都是在上面跑!
之前我们也想到把报表和OLTP完全分开,放到另一个历史库,但有些查库存的报表,必须要查当前的数据,特别是在客户做月结的时候,最常用.而我们的数据同步一次也要半个钟左右,由于表太集中,job同步的时候,也是系统最慢的时候,这个问题一直没能很好解决.所以OLTP和一部分报表,不得不集中到一个库里做.
这里我想请教各位,SQL有什么好方法,两个库几分钟便能同步一次呢?
另外,TO:happyflystone:
我想向您请教,您一个月一个表存数据,查询的时候,是写成视图,还是通过拼SQL语句或存储过程实现呢?
我们现在已经有一个专门跑报表的销售分析系统,并用套帐的方式一年一个库,数据量大,只能每天晚上同步一次,大的报表,基本上都是在上面跑!
之前我们也想到把报表和OLTP完全分开,放到另一个历史库,但有些查库存的报表,必须要查当前的数据,特别是在客户做月结的时候,最常用.而我们的数据同步一次也要半个钟左右,由于表太集中,job同步的时候,也是系统最慢的时候,这个问题一直没能很好解决.所以OLTP和一部分报表,不得不集中到一个库里做.
这里我想请教各位,SQL有什么好方法,两个库几分钟便能同步一次呢?
另外,TO:happyflystone:
我想向您请教,您一个月一个表存数据,查询的时候,是写成视图,还是通过拼SQL语句或存储过程实现呢?
w2jc 2008-03-04
- 打赏
- 举报
现在很多功能(包括一些业务流程)都是写成存储过程,直接在服务器上执行,但并发量大时(跑报表,做单),数据库时常会堵塞,导致系统效率低下,有时确定一份交易,需要几分钟!
------------------------------------------------------------
如果用重新做数据库设计的话，最好把OLTP和报表这两个部分分开。
OLTP需要数据更新快，表上的索引要少而精。
报表则不更新数据，但做大量的查询，表上的索引要足够多才能提高查询速度。
这两种应用对SQL的要求完全不同，甚至是互相矛盾的。
很多小应用都忽视这种区别，数据量不大的时候无所谓，SQL服务器可以应付。
如果数据量大，用户多，报表很复杂，那么就要把这两种数据访问分开。
比较直接的就是用2台SQL服务器，一台应付OLTP，一台应付报表查询，历史数据处理等等。
从设计系统的一开始就考虑如何将当前数据定期转到报表服务器上。
把这两种应用分开之后，虽然只是多了另外一台SQL服务器，
但性能上的提升与单纯升级硬件或者优化SQL相比是有本质区别的，
这种构架的可扩展性非常好，性能优化的效果也非常明显（因为你可以分别为OLTP和报表做特定的优化）,
今后再做很多复杂的优化，高可用性等会方便很多。
------------------------------------------------------------
如果用重新做数据库设计的话，最好把OLTP和报表这两个部分分开。
OLTP需要数据更新快，表上的索引要少而精。
报表则不更新数据，但做大量的查询，表上的索引要足够多才能提高查询速度。
这两种应用对SQL的要求完全不同，甚至是互相矛盾的。
很多小应用都忽视这种区别，数据量不大的时候无所谓，SQL服务器可以应付。
如果数据量大，用户多，报表很复杂，那么就要把这两种数据访问分开。
比较直接的就是用2台SQL服务器，一台应付OLTP，一台应付报表查询，历史数据处理等等。
从设计系统的一开始就考虑如何将当前数据定期转到报表服务器上。
把这两种应用分开之后，虽然只是多了另外一台SQL服务器，
但性能上的提升与单纯升级硬件或者优化SQL相比是有本质区别的，
这种构架的可扩展性非常好，性能优化的效果也非常明显（因为你可以分别为OLTP和报表做特定的优化）,
今后再做很多复杂的优化，高可用性等会方便很多。
-狙击手- 2008-03-03
- 打赏
- 举报
一年是一套帐，数据存储表是以月为单位
-狙击手- 2008-03-03
- 打赏
- 举报
happyflystone,您说的套帐,好像常见的都是一年一套帐,但我们的数据库,存半年的数据,变量很很慢了,好像行不通呢.
--
我们一般以月为单位进行的
--
我们一般以月为单位进行的
九章落地 2008-03-03
- 打赏
- 举报
MSTOP您说的有一定道理,不同交易分布确实不平衡,所以我也不确定每种交易类型分成单独的表,是否能提升效率!
happyflystone,您说的套帐,好像常见的都是一年一套帐,但我们的数据库,存半年的数据,变量很很慢了,好像行不通呢.
还请大家多些发表经验之谈,谢谢!
happyflystone,您说的套帐,好像常见的都是一年一套帐,但我们的数据库,存半年的数据,变量很很慢了,好像行不通呢.
还请大家多些发表经验之谈,谢谢!
-狙击手- 2008-03-03
- 打赏
- 举报
建议看看套帐
九章落地 2008-03-03
- 打赏
- 举报
非常感谢tim_spac!
我们的系统,其实每个月都会做"月结",据说以前也试过用一个表来维护当前库存和可用数,像tim_spac提到的"库存状态",但由于种种原因(如死锁或不知名原因),有时候数据会不准,影响了公司的业务,所以改成了每一笔交易,都重新算一遍库存,以增加准确性,但这样一来,又导致了数据库整体性能低下,真的不知如何是好呢!
您提到参照财务理论进行设计表,很有意思,我先思考一下看是否可行,再次感谢 ^_^
我们的系统,其实每个月都会做"月结",据说以前也试过用一个表来维护当前库存和可用数,像tim_spac提到的"库存状态",但由于种种原因(如死锁或不知名原因),有时候数据会不准,影响了公司的业务,所以改成了每一笔交易,都重新算一遍库存,以增加准确性,但这样一来,又导致了数据库整体性能低下,真的不知如何是好呢!
您提到参照财务理论进行设计表,很有意思,我先思考一下看是否可行,再次感谢 ^_^
-狙击手- 2008-03-03
- 打赏
- 举报
用05吧
华芸智森 2008-03-03
- 打赏
- 举报
现有进销存的数据库，单表记录在6千万以上,每月增长1千万左右(数据最少得保留半年才能移走)，原因是不同类型的数据，都存放在同一个表里，通过类型字段区分交易类型。
------------------------------------
分表,按月分.
现在要对数据库重新设计。然经验尚浅，唯有向各位前辈请教！
由于业务性质，每一笔新交易都要通过计算之前的各种交易来得到当前真实的库存,运算量比较大，并发量高时系统慢得不行。我想通过把不同的交易类型，分开到不同的表里存放，然后再通过视图把几组表联接起来(union all),不知是否可行？还是运用SQL Server本身的分区技术，把大表切成n个小表？
-----------------------------------
我想通过把不同的交易类型，分开到不同的表里存放,不可行.随着时间长,你的表不平衡.有些表会非常高,有些表非常少.
------------------------------------
分表,按月分.
现在要对数据库重新设计。然经验尚浅，唯有向各位前辈请教！
由于业务性质，每一笔新交易都要通过计算之前的各种交易来得到当前真实的库存,运算量比较大，并发量高时系统慢得不行。我想通过把不同的交易类型，分开到不同的表里存放，然后再通过视图把几组表联接起来(union all),不知是否可行？还是运用SQL Server本身的分区技术，把大表切成n个小表？
-----------------------------------
我想通过把不同的交易类型，分开到不同的表里存放,不可行.随着时间长,你的表不平衡.有些表会非常高,有些表非常少.
tim_spac 2008-03-03
- 打赏
- 举报
"进销存"是一种财务概念的系统，建议参考财务的“日清月结、进出两条线的”理论进行设计。
关于“日清”可以考虑将日交易信息写入日表；每日将日表数据统计后更新库存状态，并将日表里的数据转移到历史表。
“每一笔新交易都要通过计算之前的各种交易来得到当前真实的库存”的操作将变成在日数据及与库存状态数据里进行计算，这样的数据量应该是系统能够承受的。
关于“日清”可以考虑将日交易信息写入日表；每日将日表数据统计后更新库存状态，并将日表里的数据转移到历史表。
“每一笔新交易都要通过计算之前的各种交易来得到当前真实的库存”的操作将变成在日数据及与库存状态数据里进行计算，这样的数据量应该是系统能够承受的。
九章落地 2008-03-03
- 打赏
- 举报
TO:Parss
谢谢!
现在很多功能(包括一些业务流程)都是写成存储过程,直接在服务器上执行,但并发量大时(跑报表,做单),数据库时常会堵塞,导致系统效率低下,有时确定一份交易,需要几分钟!
虽然把不同交易类型放到不同表里,能减小单表记录量,加快insert/delete/update的速度,但select效率却不好把握.union是一方面,另一方面数据分布不平均,还是会导致其中主要的几种交易数据量很大.
对于sql server,操作频繁的表(insert/select),大于6千万的数据量,系统好像不是很撑得住?
很乐意与各位一起交流.
谢谢!
现在很多功能(包括一些业务流程)都是写成存储过程,直接在服务器上执行,但并发量大时(跑报表,做单),数据库时常会堵塞,导致系统效率低下,有时确定一份交易,需要几分钟!
虽然把不同交易类型放到不同表里,能减小单表记录量,加快insert/delete/update的速度,但select效率却不好把握.union是一方面,另一方面数据分布不平均,还是会导致其中主要的几种交易数据量很大.
对于sql server,操作频繁的表(insert/select),大于6千万的数据量,系统好像不是很撑得住?
很乐意与各位一起交流.
parss 2008-03-03
- 打赏
- 举报
根据多年的开发经验来看，Union语句还是很慢的。如果想加速，你应该首先考虑在数据库服务器完成ＳＱＬ动作，再返回你所得到的数据。可以写成存储过程或视图。
欢迎交流
欢迎交流
加载更多回复（4）
