请问,应该如何设计这个数据表的字段结构?谢谢!
16 个解决方案
#1
规格表可以分为两个表
一个是产品大类规格
一个是小类规格
大类里面存储的是 产品号 规格号
小类里面存储的是 各种规格号 大类规格表ID
大类表相当于把商品归类了 比如洗衣机 电冰箱 。。。
一个是产品大类规格
一个是小类规格
大类里面存储的是 产品号 规格号
小类里面存储的是 各种规格号 大类规格表ID
大类表相当于把商品归类了 比如洗衣机 电冰箱 。。。
#2
其实我也想过这么做,但是由于商品种类太多(二百多种),但每个种类中的型号又不是很多,就造成了分表的数量很多,但很多分表中只在一两条记录,感觉不太好,还请指导,谢谢!
#3
那就三个表啊
大类表 ID GOODSID SPECID 。。。
规格码表(spec) GiftSpecMTR ID 。。。
种类表 (Catagroy) ID CLASSID
Class表 ID..
大类表 ID GOODSID SPECID 。。。
规格码表(spec) GiftSpecMTR ID 。。。
种类表 (Catagroy) ID CLASSID
Class表 ID..
#4
请问,我有这样一个想法,不知合理不?
商品 型号 属性 值
电视 AAA 厂家 SONY
电视 AAA 尺寸 21'
电视 AAA 功率 800W
……
电视 BBB 厂家 三星
……
洗衣机 QQQ 厂家 LG
洗衣机 QQQ 转速 1000
……
请问这样的结构是否会有什么弊端?是否合理(感觉重复数据比较多)?如果条目很多,否会查询的效率会比较低啊?
请指导,谢谢!
#5
你能有多少款电视呢,1万款电视足够多了吧,假如每款电视有100个属性,那也只有100万条记录,这个数据量一点都不大,关键通过这种设计方式让你的表的灵活度非常大。
如果是销售记录表,那么我不建议你这样设计,因为销售记录的数据量比较大。
如果是销售记录表,那么我不建议你这样设计,因为销售记录的数据量比较大。
#6
请问,如果如果只是一个表,有个100万条记录可能不算大,可如果在一个数据库文件里有若干个这样的表,会不会就……?会怎么样啊?请指教,谢谢
#7
100万很小,除非你每次都要查询几十万数据,不然分表完全没问题,现在企业级的数据库都有大量千万级的表,库大小超几十G。这方面你不用考虑,建议你先把关系数据库的基础打好再考虑这些问题
#8

#9
若干年后你会觉得今天的顾虑是没必要的了
#10
很抱歉,我现在一直用的是Access ,想升级用SQL server,但还从来没接触过,所以比较水,来请多帮忙指教!谢谢!

#11
基础理论是一致的,只是sqlsever是更加纯粹的关系型数据库管理系统,Access有点像桌面版的数据库管理工具而已。而且毕竟是同一家的产品,很多地方是通用的,不过语法就要点时间来适应
#12
我原来公司的单表数据1.5亿,也内有分区哈。
我觉得,可以当出现性能问题后,再分区也不迟。
#13
100万很小,除非你每次都要查询几十万数据,不然分表完全没问题,现在企业级的数据库都有大量千万级的表,库大小超几十G。这方面你不用考虑,建议你先把关系数据库的基础打好再考虑这些问题
很抱歉,我现在一直用的是Access ,想升级用SQL server,但还从来没接触过,所以比较水,来请多帮忙指教!谢谢!![]()
呵呵,通过导入数据,可以把access的数据,都导入到sql server中,你可以先试试,这个升级必须要测试,看看可行性,然后再进行实际的升级
#14
100万很小,除非你每次都要查询几十万数据,不然分表完全没问题,现在企业级的数据库都有大量千万级的表,库大小超几十G。这方面你不用考虑,建议你先把关系数据库的基础打好再考虑这些问题![]()
我原来公司的单表数据1.5亿,也内有分区哈。
我觉得,可以当出现性能问题后,再分区也不迟。
什么是分区啊?
#15
100万很小,除非你每次都要查询几十万数据,不然分表完全没问题,现在企业级的数据库都有大量千万级的表,库大小超几十G。这方面你不用考虑,建议你先把关系数据库的基础打好再考虑这些问题![]()
我原来公司的单表数据1.5亿,也内有分区哈。
我觉得,可以当出现性能问题后,再分区也不迟。
什么是分区啊?
分区,就是把一个表,分成多个部分,比如一个表有1.2亿条数据,按照月份字段,1年有12个月,那么在过去1年,平均每个分区有1000万条数据,这个就是分区。
虽然是分区,但逻辑上还是一个表,物理上分成了12个分区。
当你只查询8月份的数据时,那么只需要去8月份的那个分区查询就可以了,而不会涉及到其他11个分区的数据,效率自然就高了。
#16
建议你赶快用sql server了,不要在access上面虚度青春了
#1
规格表可以分为两个表
一个是产品大类规格
一个是小类规格
大类里面存储的是 产品号 规格号
小类里面存储的是 各种规格号 大类规格表ID
大类表相当于把商品归类了 比如洗衣机 电冰箱 。。。
一个是产品大类规格
一个是小类规格
大类里面存储的是 产品号 规格号
小类里面存储的是 各种规格号 大类规格表ID
大类表相当于把商品归类了 比如洗衣机 电冰箱 。。。
#2
规格表可以分为两个表
一个是产品大类规格
一个是小类规格
大类里面存储的是 产品号 规格号
小类里面存储的是 各种规格号 大类规格表ID
大类表相当于把商品归类了 比如洗衣机 电冰箱 。。。
其实我也想过这么做,但是由于商品种类太多(二百多种),但每个种类中的型号又不是很多,就造成了分表的数量很多,但很多分表中只在一两条记录,感觉不太好,还请指导,谢谢!
#3
那就三个表啊
大类表 ID GOODSID SPECID 。。。
规格码表(spec) GiftSpecMTR ID 。。。
种类表 (Catagroy) ID CLASSID
Class表 ID..
大类表 ID GOODSID SPECID 。。。
规格码表(spec) GiftSpecMTR ID 。。。
种类表 (Catagroy) ID CLASSID
Class表 ID..
#4
那就三个表啊
大类表 ID GOODSID SPECID 。。。
规格码表(spec) GiftSpecMTR ID 。。。
种类表 (Catagroy) ID CLASSID
Class表 ID..
请问,我有这样一个想法,不知合理不?
商品 型号 属性 值
电视 AAA 厂家 SONY
电视 AAA 尺寸 21'
电视 AAA 功率 800W
……
电视 BBB 厂家 三星
……
洗衣机 QQQ 厂家 LG
洗衣机 QQQ 转速 1000
……
请问这样的结构是否会有什么弊端?是否合理(感觉重复数据比较多)?如果条目很多,否会查询的效率会比较低啊?
请指导,谢谢!
#5
你能有多少款电视呢,1万款电视足够多了吧,假如每款电视有100个属性,那也只有100万条记录,这个数据量一点都不大,关键通过这种设计方式让你的表的灵活度非常大。
如果是销售记录表,那么我不建议你这样设计,因为销售记录的数据量比较大。
如果是销售记录表,那么我不建议你这样设计,因为销售记录的数据量比较大。
#6
你能有多少款电视呢,1万款电视足够多了吧,假如每款电视有100个属性,那也只有100万条记录,这个数据量一点都不大,关键通过这种设计方式让你的表的灵活度非常大。
如果是销售记录表,那么我不建议你这样设计,因为销售记录的数据量比较大。
请问,如果如果只是一个表,有个100万条记录可能不算大,可如果在一个数据库文件里有若干个这样的表,会不会就……?会怎么样啊?请指教,谢谢
#7
100万很小,除非你每次都要查询几十万数据,不然分表完全没问题,现在企业级的数据库都有大量千万级的表,库大小超几十G。这方面你不用考虑,建议你先把关系数据库的基础打好再考虑这些问题
#8
100万很小,除非你每次都要查询几十万数据,不然分表完全没问题,现在企业级的数据库都有大量千万级的表,库大小超几十G。这方面你不用考虑,建议你先把关系数据库的基础打好再考虑这些问题

#9
若干年后你会觉得今天的顾虑是没必要的了
#10
100万很小,除非你每次都要查询几十万数据,不然分表完全没问题,现在企业级的数据库都有大量千万级的表,库大小超几十G。这方面你不用考虑,建议你先把关系数据库的基础打好再考虑这些问题
很抱歉,我现在一直用的是Access ,想升级用SQL server,但还从来没接触过,所以比较水,来请多帮忙指教!谢谢!

#11
基础理论是一致的,只是sqlsever是更加纯粹的关系型数据库管理系统,Access有点像桌面版的数据库管理工具而已。而且毕竟是同一家的产品,很多地方是通用的,不过语法就要点时间来适应
#12
100万很小,除非你每次都要查询几十万数据,不然分表完全没问题,现在企业级的数据库都有大量千万级的表,库大小超几十G。这方面你不用考虑,建议你先把关系数据库的基础打好再考虑这些问题![]()
我原来公司的单表数据1.5亿,也内有分区哈。
我觉得,可以当出现性能问题后,再分区也不迟。
#13
100万很小,除非你每次都要查询几十万数据,不然分表完全没问题,现在企业级的数据库都有大量千万级的表,库大小超几十G。这方面你不用考虑,建议你先把关系数据库的基础打好再考虑这些问题
很抱歉,我现在一直用的是Access ,想升级用SQL server,但还从来没接触过,所以比较水,来请多帮忙指教!谢谢!![]()
呵呵,通过导入数据,可以把access的数据,都导入到sql server中,你可以先试试,这个升级必须要测试,看看可行性,然后再进行实际的升级
#14
100万很小,除非你每次都要查询几十万数据,不然分表完全没问题,现在企业级的数据库都有大量千万级的表,库大小超几十G。这方面你不用考虑,建议你先把关系数据库的基础打好再考虑这些问题![]()
我原来公司的单表数据1.5亿,也内有分区哈。
我觉得,可以当出现性能问题后,再分区也不迟。
什么是分区啊?
#15
100万很小,除非你每次都要查询几十万数据,不然分表完全没问题,现在企业级的数据库都有大量千万级的表,库大小超几十G。这方面你不用考虑,建议你先把关系数据库的基础打好再考虑这些问题![]()
我原来公司的单表数据1.5亿,也内有分区哈。
我觉得,可以当出现性能问题后,再分区也不迟。
什么是分区啊?
分区,就是把一个表,分成多个部分,比如一个表有1.2亿条数据,按照月份字段,1年有12个月,那么在过去1年,平均每个分区有1000万条数据,这个就是分区。
虽然是分区,但逻辑上还是一个表,物理上分成了12个分区。
当你只查询8月份的数据时,那么只需要去8月份的那个分区查询就可以了,而不会涉及到其他11个分区的数据,效率自然就高了。
#16
建议你赶快用sql server了,不要在access上面虚度青春了