看来你对database是真的不懂。咱就冒着可能被楼下那为老兄也说成newbie的危险，说两句吧。关于table中fields应该有多少的问题，要从MS SQL 的capacity 和 performance 两方面来看。 -yangn(Raymond) @费城华人论坛:费城枫下论坛 The Rolia Forum of Philadelphia

工作学习 / IT杂谈 / 在SQL数据库中的一个表中存5万条记录，数据库有100列，数据量是否太大，影响查询速度，主要是时间和价格。较关心查询速度。应如何处理望指教谢谢。 -fengvan(Sunny); 2002-3-21 (#412748@0)

杀杀水啦. -mjs(臭豆腐-在痛苦中挣扎); 2002-3-21 (#412749@0)
你说有这个table中有100field?可以考虑分成几个小表。或者根据你的使用情况建几个index。5万个纪录不算什么。 -luoboyang(萝卜秧); 2002-3-21 (#412756@0)

每月30天加3个价格，怎么分，谢谢 -fengvan(Sunny); 2002-3-21 (#412766@0)

StartDate, price1, price2, price3, then create an index on startdate. 天，你说的100个field是这么回事儿！ -luoboyang(萝卜秧); 2002-3-21 (#412782@0)

30天X3个价=90列，有5万个产品分类。12个月，12个表。 -fengvan(Sunny); 2002-3-21 (#412811@0)

Totally wrong. -mjs(臭豆腐-在痛苦中挣扎); 2002-3-21 (#412828@0)
不知你的database已经implement了还是正在design.如果是前者，则存在极大的问题，如果是后者建议你从normalization，1nf,2nf,3nf作起，无论怎样也无需90个fields. -yangn(Raymond); 2002-3-21 {266} (#413001@0)
如此多的fields将极大地限制了每一个data page所含的record,对performance 会造成很大影响。index也不能盲目的加，否则也会对transaction带来很大的overheading.

从maintain的角度来讲，你可以一年分12个table，但可以用一个union view把他们联起来，这样对developer会带来很大方便。

谢谢执导，数据库在设计阶段。目前产品没有5万个，但正在增加中，增加具体数目不知！每年价格不同，改成半个月是否好些。 -fengvan(Sunny); 2002-3-21 (#413034@0)

price随什么变化？日？月？季？ -yangn(Raymond); 2002-3-21 (#413054@0)

我建议主要表有project, price。 price里有effectiveDate and projectID，其他的象产品类别啊什么的放在一些reference表里。不要什么一个月，半个月一个表。然后过个1，2年把DB做个merge,archive什么的。 -luoboyang(萝卜秧); 2002-3-21 (#413084@0)

不能这么讲。在设计合理的情况下，把一年的record分成12个table,可以大大缩小每个table的size(大约为原来的10%),从而提高了search的速度。 -yangn(Raymond); 2002-3-21 {140} (#413108@0)
MS SQL 2000所引入的federal server部份就是基于此作所谓的scale out solution。而且面向user的完全可以通过view来实现，不一定非要作physical merge.

你说的我同意，在设计合理的情况下。问题是他/她似乎连需求都没有搞清楚。“每年价格不同，改成半个月是否好些“，“价格每天不同！一个进价，一个卖价，一个判断是否有存货。”如果price再加上一些跨月份的business rule。。。 -luoboyang(萝卜秧); 2002-3-21 (#413120@0)
你是is4u的raymond吗?我虽然不懂DB,但从来就没这样做过。这种设计是错误的。应该考虑逻辑,物理优化应该留给数据库本身，不然华钱买oracle干嘛? -ra95(忘忧草); 2002-3-22 (#414414@0)

正是鄙人。不知你所说的设计错误是指什么？无论来自哪个vendor的database system,都得依赖于design，所谓自动的优化是不可能由database 本身实现的. -yangn(Raymond); 2002-3-22 {257} (#414501@0)
平常我们所谓database的optimization是针对process而言的,database schema and structure还是要靠designer来实现.这是所谓的logical optimization 。至于physical optimization则要从OS，HARDWARE等方面去考虑，这些database system不可能自动帮你实现。

很想听听你的意见。

好的项目实现不是需要一个超级牛人。我比较认可1建模和分析(逻辑实现)2在系统(逻辑)框架上进行优化(可维护可扩展)3在实现上的优化4在支持系统上的优化 -ra95(忘忧草); 2002-3-22 {287} (#414732@0)
1=data architect and chief architect
2=team leader and chief architect
3=team leader and developer (including SQL programmer);
4=DBA

你的方法的问题是把4和2放在一起做。不好。

给你个高帽:
你一直是我心目中的you1 xiu4DBA

BTW: why there is no word for you1 xiu4 in njwin? Shit!

基本同意你的意见。不过就这个topic来讲，主要还是只想提一点建议，如果一开始就给对方有关project的framework，那可能那位还不知道clue在哪头就大了。真正作project，可不敢写两行statement就完事。 -yangn(Raymond); 2002-3-22 (#414791@0)

哈，你是MS-SQL guy 啊... -ra95(忘忧草); 2002-3-22 (#414733@0)

咋的了？听老兄口气瞧不起MS的产品？：)咱以前也是developer的干活，C++，VB，ASP什么的也玩过，不过没赶上JAVA的好时候就混进DBA的队伍里了。 -yangn(Raymond); 2002-3-22 (#414797@0)

比较喜欢Oracle .... 别那么敏感。我记得MSSQL也有分段储存和叶面???(忘了)...所以，还是觉得把一年数据分12个表有点不对。要是时时的多，象交易，分day_quote/history_quote足已。 -ra95(忘忧草); 2002-3-22 {73} (#414820@0)
in this guys case, should let DBA do the optimization instead of himself.

并非一定要分12个table,这只是option之一，具体设计要看系统的实际要求。 Oracle我也在搞，其实oracle 和 ms sql 两种产品各有千秋，前者是把大量的configuration option提供给DBA来作，所以对于experienced DBA来讲，更能物尽其用。 -yangn(Raymond); 2002-3-22 {258} (#414848@0)
但其繁琐性有时很令人生气。后者呢，有时又太为用户考虑了，其简单的设置和安装让很多人忽略了对它的tuning.

其实两者的比较根本就是后面的OS之比。UNIX上的Oracle自然capacity,scalability等都要比NT上的MS SQL强。但MS SQL 2000 + .NET server似乎在把这种差距缩小了不少。

价格每天不同！一个进价，一个卖价，一个判断是否有存货。 -fengvan(Sunny); 2002-3-21 (#413092@0)

不行，你这个需求越扯越多。你们没有DBA或是designer什么的么？如果是从头设计，就更加重要，不然以后数据量上来了，改都改不及了。 -luoboyang(萝卜秧); 2002-3-21 (#413103@0)

不好意思，失业在家，给朋友帮忙，自己也想提高提高。 -fengvan(Sunny); 2002-3-21 (#413121@0)

OK. You haven't described your project in details. Maybe you can try this(only for your reference): -yangn(Raymond); 2002-3-21 {474} (#413165@0)
Table 1: Inventory(u can create 12 tables with the check constraint based on the different months and then use union view to join them together)

Create table Invertory (
log_id int identity(1,1) primary key,
product_id int foreign key references product (product_id),
in_price money,
out_price money,
backorder bit,
log_date smalldatetime default getdate() check ..)

Table 2: product
Create table product(
product_ID int primary key,
product_name varchar(50))

如1月份有30天，产品A就要有30条记录，如果有5万产品，在TABLE1，一月份TABLE就要有150万条记录。是否太大了 -fengvan(Sunny); 2002-3-21 (#413181@0)

DB有几百万条纪录是很正常的，不正常，或者说不常见的是有100个fields. -luoboyang(萝卜秧); 2002-3-21 (#413189@0)

半个月24个TABLE， 50列是否正常些。用时在将要用的部份连接，是否好些，想多听听大家的建议。 -fengvan(Sunny); 2002-3-21 (#413220@0)

150万record无论如何也不能算多。我管的server不少table都有一千万以上的records.以ms sql的capacity，1TB的data都没有问题，主要看你如何作design和performance tuning. -yangn(Raymond); 2002-3-21 (#413311@0)

请问\多少列比较正常，列数多了有什么弊端，我看书SQL允许有几百列。再次感谢！！！ -fengvan(Sunny); 2002-3-21 (#413423@0)

看来你对database是真的不懂。咱就冒着可能被楼下那为老兄也说成newbie的危险，说两句吧。关于table中fields应该有多少的问题，要从MS SQL 的capacity 和 performance 两方面来看。 -yangn(Raymond); 2002-3-22 {856} (#414438@0)
1。capacity:
MS SQL 7/2000的最小存储单位是data page, 1 page= 8 kb.,无论record多大，不可以跨page，所以the maximum size of single record =8k, fields数也就取决于每一个field的data type 的大小。

2。performance
即使根据以上的计算，你的table可以允许几百个field，但允许不代表应该，从performance 上讲，由于ms sql 读数据时是按page而不是record从harddisk往data cache读的，所以每一个page含的record越多，retrieving 就越快.fields数太多就造成以此相反的结果，对performance会带来很大的影响。

另外，如果table有clustered index, 当你作modification(insert,delete,update)时，data page就要作相应的调整，如果page含的record很少，那么page split就会频繁的发生，此对performance的影响不言而喻。

fields过多造成的结果还包括空间浪费，index size过大等。

至于fields多少合适由具体情况的分析来定.由于ms sql 不象oracle可以在control file里设定block的大小，所以在设计阶段就应该考虑.

看来萝卜秧八卦还行, 数据库就那个了, price1, price2, price3, 那要有一百种不同价格怎么办? 哈哈. -mjs(臭豆腐-在痛苦中挣扎); 2002-3-21 (#412823@0)

你这就不懂了。上面就是贴了这个要求嘛，就事论事，如果requirement变成了100个price,我自然再来个price table啦。在资本主义里，工作要一步一步的做，大家才都有饭吃。你一步到位，下面喝西北风呀？ -luoboyang(萝卜秧); 2002-3-21 (#412837@0)

各位，讲讲具体的，谢谢了！！ -fengvan(Sunny); 2002-3-21 (#412847@0)
haha .. 一下两个newbie ...一个一点不懂，一个懂了一点...笑死我了...(不许说我!我可不是DB guy!!!!) -ra95(忘忧草); 2002-3-22 (#414402@0)

别把嘴笑歪了啊。。。：-（你看全我的贴子了吗？再说，我可不敢称我全懂，懂一点儿就不错啦。 -luoboyang(萝卜秧); 2002-3-22 (#414445@0)

知道什么叫半瓶醋吗？:)我看那醋也就刚盖了个瓶底:) -pass(funny); 2002-3-22 (#414454@0)

你说你么？嗯，还真是过了瓶底呢。 -luoboyang(萝卜秧); 2002-3-22 (#414476@0)

说实话对你在无知状态下还能维持自我感觉如此良好的精神，本人深表敬佩。 -pass(funny); 2002-3-22 (#414506@0)

别说那么多虚的。你的有知状态呢，也呈现给我们看看。让你敬佩？嘿嘿，你愿意我还不愿意呢。 -luoboyang(萝卜秧); 2002-3-22 (#414509@0)

唉。你这种烧熟的鸭子的精神与你在本坛的大嫂身份不太协调啊。 -pass(funny); 2002-3-22 (#414513@0)

别在这里阴一句，阳一句的，酸不酸啊你！ -luoboyang(萝卜秧); 2002-3-22 (#414541@0)

我是那个什么都不懂的，就是不懂才向大家请教。你也不是天生就懂的！！大家在这里交流，如果你在这方面知道多些，也讲给大家听听。在这里搞人身攻击实在无聊！ -fengvan(Sunny); 2002-3-22 (#414517@0)

没说你啊。你虚心的精神比那位大嫂强多了。 -pass(funny); 2002-3-22 (#414520@0)

这里是技术论坛，你的言论破坏了这里的气氛，你说谁并不是问题关键。 -fengvan(Sunny); 2002-3-22 (#414550@0)

作为技术论坛，虚心似乎是要素之一。本人只是点出了某人的某些毛病，怎么就和气氛不合了？至于人身攻击好像是你敏感了吧：烧熟的鸭子=嘴硬；她岁数比我大，故尊称大嫂；半瓶醋似乎没必要解释了。请赐教，以上哪句是人身攻击？ -pass(funny); 2002-3-22 (#414555@0)

大嫂？！你知道我老公是谁啊，别在这儿乱套近乎，恶不恶心啊？你要是自认为懂呢，就说些有用的建议，象Raymond一样，不然别再这里浪费资源。大晴天的，有劲儿就到湖边跑跑步去。 -luoboyang(萝卜秧); 2002-3-22 (#414557@0)

你不用理他，这个ID在论坛里专门找我碴儿的。随他去吧。 -luoboyang(萝卜秧); 2002-3-22 (#414546@0)

5万条纪录小意思,100列略多.建议Normalize先 -decentboy(男人<=30, Seven); 2002-3-21 (#412768@0)
你在公司做么?你可以看看有关数据建模的东东,否则东补西补太痛苦. -mcdonald(麦当劳); 2002-3-21 (#412839@0)

同意！5万个产品分类。12个月，12个表，吼吼，总不能在这里大家一点点给你凑出个新的DB来吧？ -luoboyang(萝卜秧); 2002-3-21 (#412849@0)

1分区 2模化范式 350k is nothing, do not worry. -ra95(忘忧草); 2002-3-22 (#414398@0)

如果不想范化，试试dimension和snapshot (不知MS SQL有无)，另外，检查Net8(MS SQL因该有相应的tool)的网络传输package大小。不过为350k的表做这些工作有点类似核弹打蚊子 -mkl(mkl); 2002-3-26 (#419278@0)

@Philadelphia

看来你对database是真的不懂。咱就冒着可能被楼下那为老兄也说成newbie的危险，说两句吧。关于table中fields应该有多少的问题，要从MS SQL 的capacity 和 performance 两方面来看。

Replies, comments and Discussions:

More Topics

@Philadelphia

看来你对database是真的不懂。咱就冒着可能被楼下那为老兄也说成newbie的危险，说两句吧。 关于table中fields应该有多少的问题，要从MS SQL 的capacity 和 performance 两方面来看。

Replies, comments and Discussions:

More Topics

看来你对database是真的不懂。咱就冒着可能被楼下那为老兄也说成newbie的危险，说两句吧。关于table中fields应该有多少的问题，要从MS SQL 的capacity 和 performance 两方面来看。