第一次发帖请教问题,一个数据库设计问题

如果有各种设备,例如空调,广告灯...这些设备都是存在不同的属性,空调有风速,温度;广告灯有亮度;而且这些设备的属性值都会用到,而且属性可能会新增
现在问题是,如果以后会动态新增一个排气扇设备,有风速等属性,我的表该如何设计才能更好地扩展,在新增各种设备以及属性的时候不需要改动表结构...

请大家支招吧...

39 个解决方案

#1

这样可以吗？在数据库中加一个int type字段，用来判断是那种设备，不管来多少种都可以

#2

能否把非公共的这些属性值弄成一个聚合，存放在一个字段中？
比如json格式字符串。
我也没什么经验，期待高手解答

#3

引用 1 楼 wufengui1315 的回复:

这样可以吗？在数据库中加一个int type字段，用来判断是那种设备，不管来多少种都可以

这个很明显不行呢...只是简单的一个类型判断是不能符合需求的哇

#4

引用 2 楼 xiars123 的回复:

能否把非公共的这些属性值弄成一个聚合，存放在一个字段中？
比如json格式字符串。
我也没什么经验，期待高手解答

我感觉最好是每个设备的属性独立,不应该让他们有交集还更好控制点,而且需要考虑到动态扩展属性的问题

#5

设计方案很多啊。


推荐一种适合初学者的吧：
1、首先归集产品的通用属性，只需要80%产品有这种属性即可，比如：重量、颜色、尺寸这类；
2、通用属性直接作为字段存在；
3、附加属性用违反 1NF 的方式，直接用JSON或其它方式组装，存入一个扩展域字段。


通用属性往往需要在列表中：显示（Select）、过滤（where）、排序（Order）；所以需要直接成为字段。
非通用属性一般都是在显示某产品明细信息时才需要使用，所以存储时可以做组装。

#6

你需要把以前设计表的横向思维习惯改成纵向考虑，你就会有答案了。。。

#7

引用 5 楼 ldh911 的回复:

设计方案很多啊。


推荐一种适合初学者的吧：
1、首先归集产品的通用属性，只需要80%产品有这种属性即可，比如：重量、颜色、尺寸这类；
2、通用属性直接作为字段存在；
3、附加属性用违反 1NF 的方式，直接用JSON或其它方式组装，存入一个扩展域字段。


通用属性往往需要在列表中：显示（Select）、过滤（where）、排序（Order）；所以需要直接成为字段。
非通用属性一般都是在显示某产品明细信息时才需要使用，所以存储时可以做组装。

比较靠谱,其实我自己也想到差不多的想法,只是看看大家有木有更好的

#8

引用 6 楼 flagiris 的回复:

你需要把以前设计表的横向思维习惯改成纵向考虑，你就会有答案了。。。

不靠谱+10086

#9

引用 8 楼 shadowsick 的回复:

Quote: 引用 6 楼 flagiris 的回复:

你需要把以前设计表的横向思维习惯改成纵向考虑，你就会有答案了。。。

不靠谱+10086

其实我做过这种表设计，有7张表，你可以存任何设备，而且可以扩展任何类型的属性。
你认为不靠谱就算了。

#10

引用 9 楼 flagiris 的回复:

Quote: 引用 8 楼 shadowsick 的回复:

Quote: 引用 6 楼 flagiris 的回复:

你需要把以前设计表的横向思维习惯改成纵向考虑，你就会有答案了。。。

不靠谱+10086

其实我做过这种表设计，有7张表，你可以存任何设备，而且可以扩展任何类型的属性。
你认为不靠谱就算了。

...郁闷...你说的这话都是浮想连篇的,,,给点实际建议好吗?...请教下如何设计呢?跪求指导

#11

引用 5 楼 ldh911 的回复:

设计方案很多啊。


推荐一种适合初学者的吧：
1、首先归集产品的通用属性，只需要80%产品有这种属性即可，比如：重量、颜色、尺寸这类；
2、通用属性直接作为字段存在；
3、附加属性用违反 1NF 的方式，直接用JSON或其它方式组装，存入一个扩展域字段。


通用属性往往需要在列表中：显示（Select）、过滤（where）、排序（Order）；所以需要直接成为字段。
非通用属性一般都是在显示某产品明细信息时才需要使用，所以存储时可以做组装。

而且通用属性一般不用到,真正需要用到都是非通用字段的,估计就是开关属性是全都有的,一般来说灯光的亮度,排气扇的风速,空调的温度,风速,而且,到时需要展现给客户看到这些属性

#12

设计两张表：设备表：id,name。

#13

引用 12 楼 wufengui1315 的回复:

设计两张表：设备表：id,name。

我晕，还没写完就出去了。
属性表：id,name,fk。
这样增加任何设备，任何属性都可以啊

#14

引用 9 楼 flagiris 的回复:

其实我做过这种表设计，有7张表，你可以存任何设备，而且可以扩展任何类型的属性。
你认为不靠谱就算了。

我猜测下你的主体设计，看是否类似：
1、存储表采用横表，也就是一行即可存储一个完整设备的所有属性；
2、存储表的字段，大部分是不含业务语义的，取名可以是 F01、F02、F03；
3、有分类表和字段语义对照表，分类表包含所有设备种类；
4、字段语义对照表，标明每个设备种类在存储表中的字段，其业务语义是啥，比如F01是 重量；
是否类似这种？

#15

引用 12 楼 wufengui1315 的回复:

设计两张表：设备表：id,name。

垂直表（属性表）的设计模型，首要面临的问题是属性操作能力上的严重削弱，比如需要中要针对比如“重量”进行过滤 和 排序，这个怎么考虑？

#16

引用 13 楼 wufengui1315 的回复:

Quote: 引用 12 楼 wufengui1315 的回复:

设计两张表：设备表：id,name。

我晕，还没写完就出去了。
属性表：id,name,fk。
这样增加任何设备，任何属性都可以啊

咔咔,需要继续加深理解

#17

引用 14 楼 ldh911 的回复:

Quote: 引用 9 楼 flagiris 的回复:

其实我做过这种表设计，有7张表，你可以存任何设备，而且可以扩展任何类型的属性。
你认为不靠谱就算了。

我猜测下你的主体设计，看是否类似：
1、存储表采用横表，也就是一行即可存储一个完整设备的所有属性；
2、存储表的字段，大部分是不含业务语义的，取名可以是 F01、F02、F03；
3、有分类表和字段语义对照表，分类表包含所有设备种类；
4、字段语义对照表，标明每个设备种类在存储表中的字段，其业务语义是啥，比如F01是 重量；
是否类似这种？

简单的来说就是非确定意义属性记录,然后再加定义描述关联属性记录?

#18

1.不更改表结构，一定要有预留字段。
2.你是如何区分各种设备的？
3.都在一个表内？
4.属性值存放在那个字段内都无所谓，查询出来能对于就行。

#19

引用 18 楼 fangmingshijie 的回复:

1.不更改表结构，一定要有预留字段。
2.你是如何区分各种设备的？
3.都在一个表内？
4.属性值存放在那个字段内都无所谓，查询出来能对于就行。

这个肯定已经有个设备类型表结构的哇...现在主要是如何分离和动态增加这些设备的各种属性...

#20

定义好规则，谁对应谁，有什么好纠结的。

#21

不同的设备用单独的表存放，通用的属性放一张公共表里啊

#22

引用 20 楼 fangmingshijie 的回复:

定义好规则，谁对应谁，有什么好纠结的。

怎么个定义规则法?以后各种不同的设备挂钩在电路板上受控制...

#23

引用 21 楼 shawncpp 的回复:

不同的设备用单独的表存放，通用的属性放一张公共表里啊

一个设备一个表,如果升级加设备那不是天天要调整表?

#24

我觉得好多人都想简单了，自己做了就知道了，
你要想想如何不改变表任何表的设计就可以任意添加各种类型的属性，包括int，string，date型等等，
然后这些属性的值又如何存储，
最后又如何查询某一种设备的某一个属性值，
这绝不是2,3张表可以搞定的。。。

#25

类型都可以转换的。这不是问题，当然不可能拿String去对于int了。
这看你如何去对应了。

不管谁去控制，你取到的数据和你表里的字段对应上就行了。

#26

引用 24 楼 flagiris 的回复:

我觉得好多人都想简单了，自己做了就知道了，
你要想想如何不改变表任何表的设计就可以任意添加各种类型的属性，包括int，string，date型等等，
然后这些属性的值又如何存储，
最后又如何查询某一种设备的某一个属性值，
这绝不是2,3张表可以搞定的。。。

靠谱+10086

#27

引用 25 楼 fangmingshijie 的回复:

类型都可以转换的。这不是问题，当然不可能拿String去对于int了。
这看你如何去对应了。

不管谁去控制，你取到的数据和你表里的字段对应上就行了。

如果设备的属性是固定的,那这样做肯定是很简单没问题的,现在主要是未知设备,未知属性如何动态增加才是要解决的关键点...

#28

反射，用反射机制，我个人觉得可以！

#29

设备和位置设备，就像是类和对象的关系了，总会有相同的部分。

#30

引用 29 楼 fangmingshijie 的回复:

设备和位置设备，就像是类和对象的关系了，总会有相同的部分。

相同的好处理,但是不相同的呢?抽象统一的这个没问题,剩下不统一的该如何处理

#31

引用 24 楼 flagiris 的回复:

我觉得好多人都想简单了，自己做了就知道了

确实做过：
从垂直属性表（属性全部用varchar，使用时根据配置转换），
到无业务语义字段表（属性共255项，预留不同类型的，但大部分仍然是varchar），
到1主表+N扩展表（公共属性放主表，跟类型相关属性放专用扩展表，扩展表自动可按需在Web页面动态配置），
到主属性+扩展XML（公共属性放主表，整个实体的所有属性完整保存一份XML，字段类型由XSD管理；展现的时候直接把XML读出来扔给表单，自动就绑定回去了）。


目前综合来看，还是最后一种性价比适中。


能否简单介绍下你的模型？

#32

引用 31 楼 ldh911 的回复:

Quote: 引用 24 楼 flagiris 的回复:

我觉得好多人都想简单了，自己做了就知道了

确实做过：
从垂直属性表（属性全部用varchar，使用时根据配置转换），
到无业务语义字段表（属性共255项，预留不同类型的，但大部分仍然是varchar），
到1主表+N扩展表（公共属性放主表，跟类型相关属性放专用扩展表，扩展表自动可按需在Web页面动态配置），
到主属性+扩展XML（公共属性放主表，整个实体的所有属性完整保存一份XML，字段类型由XSD管理；展现的时候直接把XML读出来扔给表单，自动就绑定回去了）。


目前综合来看，还是最后一种性价比适中。


能否简单介绍下你的模型？

我也想了解下
flagiris 
的模型设计

#33

引用 6 楼 flagiris 的回复:

你需要把以前设计表的横向思维习惯改成纵向考虑，你就会有答案了。。。

确实可以这样做，不过不太好

两列：第一列name varchar  第二列value varchar
把以前的 where 温度 = 3
改成 where name = 温度 and value = 3

不过最好用mongodb 支持非结构存储
要不就用postgresql 支持数组

#34

bfffnhADS D DVDS 

#35

建议使用 NoSQL。 处理属性，是长项。推荐 MangoDB

#36

引用 35 楼 williamx 的回复:

建议使用 NoSQL。 处理属性，是长项。推荐 MangoDB

别那么天真,环境不是你想怎么改就怎么改,已经存在固定环境...

#37

引用 15 楼 ldh911 的回复:

Quote: 引用 12 楼 wufengui1315 的回复:

设计两张表：设备表：id,name。

垂直表（属性表）的设计模型，首要面临的问题是属性操作能力上的严重削弱，比如需要中要针对比如“重量”进行过滤 和 排序，这个怎么考虑？

这个确实是问题， 我是菜鸟，都不怎么考虑性能问题的，，，

#38

引用 37 楼 wufengui1315 的回复:

Quote: 引用 15 楼 ldh911 的回复:

Quote: 引用 12 楼 wufengui1315 的回复:

设计两张表：设备表：id,name。

垂直表（属性表）的设计模型，首要面临的问题是属性操作能力上的严重削弱，比如需要中要针对比如“重量”进行过滤 和 排序，这个怎么考虑？

这个确实是问题， 我是菜鸟，都不怎么考虑性能问题的，，，

#39

你这是要做资产管理系统吗？