×

Loading...
Ad by
  • 最优利率和cashback可以申请特批,好信用好收入offer更好。请点链接扫码加微信咨询,Scotiabank -- Nick Zhang 6478812600。
Ad by
  • 最优利率和cashback可以申请特批,好信用好收入offer更好。请点链接扫码加微信咨询,Scotiabank -- Nick Zhang 6478812600。

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

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的大小,所以在设计阶段就应该考虑.
Report

Replies, comments and Discussions:

  • 工作学习 / IT杂谈 / 在SQL数据库中的一个表中存5万条记录,数据库有100列,数据量是否太大,影响查询速度,主要是时间和价格。较关心查询速度。应如何处理望指教谢谢。
    • 杀杀水啦.
    • 你说有这个table中有100field?可以考虑分成几个小表。或者根据你的使用情况建几个index。5万个纪录不算什么。
      • 每月30天加3个价格,怎么分,谢谢
        • StartDate, price1, price2, price3, then create an index on startdate. 天,你说的100个field是这么回事儿!
          • 30天X3个价=90列,有5万个产品分类。12个月,12个表。
            • Totally wrong.
            • 不知你的database已经implement了还是正在design.如果是前者,则存在极大的问题,如果是后者建议你从normalization,1nf,2nf,3nf作起,无论怎样也无需90个fields.
              如此多的fields将极大地限制了每一个data page所含的record,对performance 会造成很大影响。index也不能盲目的加,否则也会对transaction带来很大的overheading.

              从maintain的角度来讲,你可以一年分12个table,但可以用一个union view把他们联起来,这样对developer会带来很大方便。
              • 谢谢执导,数据库在设计阶段。目前产品没有5万个,但正在增加中,增加具体数目不知!每年价格不同,改成半个月是否好些。
                • price随什么变化?日?月?季?
                  • 我建议主要表有project, price。 price里有effectiveDate and projectID,其他的象产品类别啊什么的放在一些reference表里。不要什么一个月,半个月一个表。然后过个1,2年把DB做个merge,archive什么的。
                    • 不能这么讲。在设计合理的情况下,把一年的record分成12个table,可以大大缩小每个table的size(大约为原来的10%),从而提高了search的速度。
                      MS SQL 2000所引入的federal server部份就是基于此作所谓的scale out solution。而且面向user的完全可以通过view来实现,不一定非要作physical merge.
                      • 你说的我同意,在设计合理的情况下。问题是他/她似乎连需求都没有搞清楚。“每年价格不同,改成半个月是否好些“,“价格每天不同!一个进价,一个卖价,一个判断是否有存货。”如果price再加上一些跨月份的business rule。。。
                      • 你是is4u的raymond吗?我虽然不懂DB,但从来就没这样做过。这种设计是错误的。应该考虑逻辑,物理优化应该留给数据库本身,不然华钱买oracle干嘛?
                        • 正是鄙人。不知你所说的设计错误是指什么?无论来自哪个vendor的database system,都得依赖于design,所谓自动的优化是不可能由database 本身实现的.
                          平常我们所谓database的optimization是针对process而言的,database schema and structure还是要靠designer来实现.这是所谓的logical optimization 。至于physical optimization则要从OS,HARDWARE等方面去考虑,这些database system不可能自动帮你实现。

                          很想听听你的意见。
                          • 好的项目实现不是需要一个超级牛人。我比较认可1建模和分析(逻辑实现)2在系统(逻辑)框架上进行优化(可维护可扩展)3在实现上的优化4在支持系统上的优化
                            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就完事。
                          • 哈,你是MS-SQL guy 啊...
                            • 咋的了?听老兄口气瞧不起MS的产品?:)咱以前也是developer的干活,C++,VB,ASP什么的也玩过,不过没赶上JAVA的好时候就混进DBA的队伍里了。
                              • 比较喜欢Oracle .... 别那么敏感。我记得MSSQL也有分段储存和叶面???(忘了)...所以,还是觉得把一年数据分12个表有点不对。要是时时的多,象交易,分day_quote/history_quote足已。
                                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来讲,更能物尽其用。
                                  但其繁琐性有时很令人生气。后者呢,有时又太为用户考虑了,其简单的设置和安装让很多人忽略了对它的tuning.

                                  其实两者的比较根本就是后面的OS之比。UNIX上的Oracle自然capacity,scalability等都要比NT上的MS SQL强。但MS SQL 2000 + .NET server似乎在把这种差距缩小了不少。
                  • 价格每天不同!一个进价,一个卖价,一个判断是否有存货。
                    • 不行,你这个需求越扯越多。你们没有DBA或是designer什么的么?如果是从头设计,就更加重要,不然以后数据量上来了,改都改不及了。
                      • 不好意思,失业在家,给朋友帮忙,自己也想提高提高。
                    • OK. You haven't described your project in details. Maybe you can try this(only for your reference):
                      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万条记录。是否太大了
                        • DB有几百万条纪录是很正常的,不正常,或者说不常见的是有100个fields.
                          • 半个月24个TABLE, 50列是否正常些。用时在将要用的部份连接,是否好些,想多听听大家的建议。
                        • 150万record无论如何也不能算多。我管的server不少table都有一千万以上的records.以ms sql的capacity,1TB的data都没有问题,主要看你如何作design和performance tuning.
                          • 请问\多少列比较正常, 列数多了有什么弊端,我看书SQL允许有几百列。再次感谢!!!
                            • 看来你对database是真的不懂。咱就冒着可能被楼下那为老兄也说成newbie的危险,说两句吧。 关于table中fields应该有多少的问题,要从MS SQL 的capacity 和 performance 两方面来看。
                              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, 那要有一百种不同价格怎么办? 哈哈.
            • 你这就不懂了。上面就是贴了这个要求嘛,就事论事,如果requirement变成了100个price,我自然再来个price table啦。在资本主义里,工作要一步一步的做,大家才都有饭吃。你一步到位,下面喝西北风呀?
          • 各位,讲讲具体的,谢谢了!!
          • haha .. 一下两个newbie ...一个一点不懂,一个懂了一点...笑死我了...(不许说我!我可不是DB guy!!!!)
            • 别把嘴笑歪了啊。。。:-( 你看全我的贴子了吗?再说,我可不敢称我全懂,懂一点儿就不错啦。
              • 知道什么叫半瓶醋吗?:)我看那醋也就刚盖了个瓶底:)
                • 你说你么?嗯,还真是过了瓶底呢。
                  • 说实话对你在无知状态下还能维持自我感觉如此良好的精神,本人深表敬佩。
                    • 别说那么多虚的。你的有知状态呢,也呈现给我们看看。让你敬佩?嘿嘿,你愿意我还不愿意呢。
                      • 唉。你这种烧熟的鸭子的精神与你在本坛的大嫂身份不太协调啊。
                        • 别在这里阴一句,阳一句的,酸不酸啊你!
                    • 我是那个什么都不懂的,就是不懂才向大家请教。你也不是天生就懂的!! 大家在这里交流,如果你在这方面知道多些,也讲给大家听听。在这里搞人身攻击实在无聊!
                      • 没说你啊。你虚心的精神比那位大嫂强多了。
                        • 这里是技术论坛,你的言论破坏了这里的气氛,你说谁并不是问题关键。
                          • 作为技术论坛,虚心似乎是要素之一。本人只是点出了某人的某些毛病,怎么就和气氛不合了?至于人身攻击好像是你敏感了吧:烧熟的鸭子=嘴硬;她岁数比我大,故尊称大嫂;半瓶醋似乎没必要解释了。请赐教,以上哪句是人身攻击?
                            • 大嫂?!你知道我老公是谁啊,别在这儿乱套近乎,恶不恶心啊?你要是自认为懂呢,就说些有用的建议,象Raymond一样,不然别再这里浪费资源。大晴天的,有劲儿就到湖边跑跑步去。
                      • 你不用理他,这个ID在论坛里专门找我碴儿的。随他去吧。
    • 5万条纪录小意思,100列略多.建议Normalize先
    • 你在公司做么?你可以看看有关数据建模的东东,否则东补西补太痛苦.
      • 同意!5万个产品分类。12个月,12个表,吼吼,总不能在这里大家一点点给你凑出个新的DB来吧?
    • 1分区 2模化范式 350k is nothing, do not worry.
      • 如果不想范化,试试dimension和snapshot (不知MS SQL有无),另外,检查Net8(MS SQL因该有相应的tool)的网络传输package大小。不过为350k的表做这些工作有点类似核弹打蚊子