请教该如何设计数据表？

我想把很多商品的指标属性放在同一个记录表中，以便将来针对某个商品查询它的属性，但是很多商品属性截然不同，比如电视有厂家、功率、屏幕尺寸，3D或高清等属性，而洗衣机也有厂家、功率，却没有屏幕尺寸，3D或高清等属性，但有转速、涡轮/滚筒等指标，而音箱又有其相同或不同的指标属性……
请问，应该如何设计这个数据表的字段结构？谢谢！

16 个解决方案

#1

规格表可以分为两个表

一个是产品大类规格

一个是小类规格

大类里面存储的是产品号规格号

小类里面存储的是各种规格号大类规格表ID

大类表相当于把商品归类了比如洗衣机电冰箱。。。

#2

引用 1 楼 fredrickhu 的回复:

规格表可以分为两个表

一个是产品大类规格

一个是小类规格

大类里面存储的是产品号规格号

小类里面存储的是各种规格号大类规格表ID

大类表相当于把商品归类了比如洗衣机电冰箱。。。

其实我也想过这么做，但是由于商品种类太多（二百多种），但每个种类中的型号又不是很多，就造成了分表的数量很多，但很多分表中只在一两条记录，感觉不太好，还请指导，谢谢！

#3

那就三个表啊

大类表   ID GOODSID  SPECID 。。。

规格码表（spec)   GiftSpecMTR  ID 。。。

种类表  (Catagroy)   ID CLASSID

Class表 ID..

#4

引用 3 楼 fredrickhu 的回复:

那就三个表啊

大类表   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

引用 5 楼 dotnetstudio 的回复:

你能有多少款电视呢，1万款电视足够多了吧，假如每款电视有100个属性，那也只有100万条记录，这个数据量一点都不大，关键通过这种设计方式让你的表的灵活度非常大。

如果是销售记录表，那么我不建议你这样设计，因为销售记录的数据量比较大。

请问，如果如果只是一个表，有个100万条记录可能不算大，可如果在一个数据库文件里有若干个这样的表，会不会就……？会怎么样啊？请指教，谢谢

#7

100万很小，除非你每次都要查询几十万数据，不然分表完全没问题，现在企业级的数据库都有大量千万级的表，库大小超几十G。这方面你不用考虑，建议你先把关系数据库的基础打好再考虑这些问题

#8

引用 7 楼 DBA_Huangzj 的回复:

100万很小，除非你每次都要查询几十万数据，不然分表完全没问题，现在企业级的数据库都有大量千万级的表，库大小超几十G。这方面你不用考虑，建议你先把关系数据库的基础打好再考虑这些问题

#9

若干年后你会觉得今天的顾虑是没必要的了

#10

引用 7 楼 DBA_Huangzj 的回复:

100万很小，除非你每次都要查询几十万数据，不然分表完全没问题，现在企业级的数据库都有大量千万级的表，库大小超几十G。这方面你不用考虑，建议你先把关系数据库的基础打好再考虑这些问题

很抱歉，我现在一直用的是Access ，想升级用SQL server，但还从来没接触过，所以比较水，来请多帮忙指教！谢谢！请教该如何设计数据表？

#11

基础理论是一致的，只是sqlsever是更加纯粹的关系型数据库管理系统，Access有点像桌面版的数据库管理工具而已。而且毕竟是同一家的产品，很多地方是通用的，不过语法就要点时间来适应

#12

引用 8 楼 mansohu 的回复:

Quote: 引用 7 楼 DBA_Huangzj 的回复:

100万很小，除非你每次都要查询几十万数据，不然分表完全没问题，现在企业级的数据库都有大量千万级的表，库大小超几十G。这方面你不用考虑，建议你先把关系数据库的基础打好再考虑这些问题

我原来公司的单表数据1.5亿，也内有分区哈。

我觉得，可以当出现性能问题后，再分区也不迟。

#13

引用 10 楼 mansohu 的回复:

Quote: 引用 7 楼 DBA_Huangzj 的回复:

100万很小，除非你每次都要查询几十万数据，不然分表完全没问题，现在企业级的数据库都有大量千万级的表，库大小超几十G。这方面你不用考虑，建议你先把关系数据库的基础打好再考虑这些问题

很抱歉，我现在一直用的是Access ，想升级用SQL server，但还从来没接触过，所以比较水，来请多帮忙指教！谢谢！

呵呵，通过导入数据，可以把access的数据，都导入到sql server中，你可以先试试，这个升级必须要测试，看看可行性，然后再进行实际的升级

#14

引用 12 楼 yupeigu 的回复:

Quote: 引用 8 楼 mansohu 的回复:

Quote: 引用 7 楼 DBA_Huangzj 的回复:

100万很小，除非你每次都要查询几十万数据，不然分表完全没问题，现在企业级的数据库都有大量千万级的表，库大小超几十G。这方面你不用考虑，建议你先把关系数据库的基础打好再考虑这些问题

我原来公司的单表数据1.5亿，也内有分区哈。

我觉得，可以当出现性能问题后，再分区也不迟。

什么是分区啊？

#15

引用 14 楼 mansohu 的回复:

Quote: 引用 12 楼 yupeigu 的回复:

Quote: 引用 8 楼 mansohu 的回复:

Quote: 引用 7 楼 DBA_Huangzj 的回复:

100万很小，除非你每次都要查询几十万数据，不然分表完全没问题，现在企业级的数据库都有大量千万级的表，库大小超几十G。这方面你不用考虑，建议你先把关系数据库的基础打好再考虑这些问题

我原来公司的单表数据1.5亿，也内有分区哈。

我觉得，可以当出现性能问题后，再分区也不迟。

什么是分区啊？

分区，就是把一个表，分成多个部分，比如一个表有1.2亿条数据，按照月份字段，1年有12个月，那么在过去1年，平均每个分区有1000万条数据，这个就是分区。

虽然是分区，但逻辑上还是一个表，物理上分成了12个分区。

当你只查询8月份的数据时，那么只需要去8月份的那个分区查询就可以了，而不会涉及到其他11个分区的数据，效率自然就高了。

#16

建议你赶快用sql server了，不要在access上面虚度青春了

#1

#2

引用 1 楼 fredrickhu 的回复:

规格表可以分为两个表

一个是产品大类规格

一个是小类规格

大类里面存储的是产品号规格号

小类里面存储的是各种规格号大类规格表ID

大类表相当于把商品归类了比如洗衣机电冰箱。。。

#3

那就三个表啊

大类表   ID GOODSID  SPECID 。。。

规格码表（spec)   GiftSpecMTR  ID 。。。

种类表  (Catagroy)   ID CLASSID

Class表 ID..

#4

引用 3 楼 fredrickhu 的回复:

那就三个表啊

大类表   ID GOODSID  SPECID 。。。

规格码表（spec)   GiftSpecMTR  ID 。。。

种类表  (Catagroy)   ID CLASSID

Class表 ID..

#5

#6

引用 5 楼 dotnetstudio 的回复:

你能有多少款电视呢，1万款电视足够多了吧，假如每款电视有100个属性，那也只有100万条记录，这个数据量一点都不大，关键通过这种设计方式让你的表的灵活度非常大。

如果是销售记录表，那么我不建议你这样设计，因为销售记录的数据量比较大。

请问，如果如果只是一个表，有个100万条记录可能不算大，可如果在一个数据库文件里有若干个这样的表，会不会就……？会怎么样啊？请指教，谢谢

#7

#8

引用 7 楼 DBA_Huangzj 的回复:

100万很小，除非你每次都要查询几十万数据，不然分表完全没问题，现在企业级的数据库都有大量千万级的表，库大小超几十G。这方面你不用考虑，建议你先把关系数据库的基础打好再考虑这些问题

#9

若干年后你会觉得今天的顾虑是没必要的了

#10

引用 7 楼 DBA_Huangzj 的回复:

100万很小，除非你每次都要查询几十万数据，不然分表完全没问题，现在企业级的数据库都有大量千万级的表，库大小超几十G。这方面你不用考虑，建议你先把关系数据库的基础打好再考虑这些问题

很抱歉，我现在一直用的是Access ，想升级用SQL server，但还从来没接触过，所以比较水，来请多帮忙指教！谢谢！请教该如何设计数据表？

#11

#12

引用 8 楼 mansohu 的回复:

Quote: 引用 7 楼 DBA_Huangzj 的回复:

100万很小，除非你每次都要查询几十万数据，不然分表完全没问题，现在企业级的数据库都有大量千万级的表，库大小超几十G。这方面你不用考虑，建议你先把关系数据库的基础打好再考虑这些问题

我原来公司的单表数据1.5亿，也内有分区哈。

我觉得，可以当出现性能问题后，再分区也不迟。

#13

引用 10 楼 mansohu 的回复:

Quote: 引用 7 楼 DBA_Huangzj 的回复:

100万很小，除非你每次都要查询几十万数据，不然分表完全没问题，现在企业级的数据库都有大量千万级的表，库大小超几十G。这方面你不用考虑，建议你先把关系数据库的基础打好再考虑这些问题

很抱歉，我现在一直用的是Access ，想升级用SQL server，但还从来没接触过，所以比较水，来请多帮忙指教！谢谢！

呵呵，通过导入数据，可以把access的数据，都导入到sql server中，你可以先试试，这个升级必须要测试，看看可行性，然后再进行实际的升级

#14

引用 12 楼 yupeigu 的回复:

Quote: 引用 8 楼 mansohu 的回复:

Quote: 引用 7 楼 DBA_Huangzj 的回复:

100万很小，除非你每次都要查询几十万数据，不然分表完全没问题，现在企业级的数据库都有大量千万级的表，库大小超几十G。这方面你不用考虑，建议你先把关系数据库的基础打好再考虑这些问题

我原来公司的单表数据1.5亿，也内有分区哈。

我觉得，可以当出现性能问题后，再分区也不迟。

什么是分区啊？

#15

引用 14 楼 mansohu 的回复:

Quote: 引用 12 楼 yupeigu 的回复:

Quote: 引用 8 楼 mansohu 的回复:

Quote: 引用 7 楼 DBA_Huangzj 的回复:

100万很小，除非你每次都要查询几十万数据，不然分表完全没问题，现在企业级的数据库都有大量千万级的表，库大小超几十G。这方面你不用考虑，建议你先把关系数据库的基础打好再考虑这些问题

我原来公司的单表数据1.5亿，也内有分区哈。

我觉得，可以当出现性能问题后，再分区也不迟。

什么是分区啊？

#16

建议你赶快用sql server了，不要在access上面虚度青春了

秒客网

请教该如何设计数据表？

16 个解决方案

#1

#2

#3

#4

#5

#6

#7

#8

#9

#10

#11

#12

#13

#14

#15

#16

#1

#2

#3

#4

#5

#6

#7

#8

#9

#10

#11

#12

#13

#14

#15

#16

相关文章