某项目中，对某个区域（区域是具有二维坐标的）进行策略操作。
策略可以有多种，有多个。
区域自然有guid， 区域作为primary key， 把那些策略作为一个xml字段，存放懂啊数据库里？
莫非这种设计不违背范式设计？
第一范式： 不断的拆开，拆了，让字段无法分解为止。 很明显xml已经违背了第一了。
策略是什么？ 策略有开始时间， 停止时间， 策略有坐标，策略有类型（何种策略类型），等一系列属性。
为了省事情，把一个区域的策略做成一个xml存放进去。
问一下，这种设计到底怎么样？
怎么样评价？
策略可以有多种，有多个。
区域自然有guid， 区域作为primary key， 把那些策略作为一个xml字段，存放懂啊数据库里？
莫非这种设计不违背范式设计？
第一范式： 不断的拆开，拆了，让字段无法分解为止。 很明显xml已经违背了第一了。
策略是什么？ 策略有开始时间， 停止时间， 策略有坐标，策略有类型（何种策略类型），等一系列属性。
为了省事情，把一个区域的策略做成一个xml存放进去。
问一下，这种设计到底怎么样？
怎么样评价？
解决方案：15分
现在这种直接存储xml的做法本人认为是可取的，有些小项目经常会这么干，省人力，省时间，省脑力………………
感觉不必纠结这些，违背原则的地方多了去了，
感觉不必纠结这些，违背原则的地方多了去了，
解决方案：5分
范式还要求除外键，表之间不能有冗余
而事实上我们为了效率，安全等考虑，往往特意地加上冗余字段
而事实上我们为了效率，安全等考虑，往往特意地加上冗余字段
解决方案：7分
所谓的第一、第二、第三范式，也不过是几个大神总结的而已，又不是刑法。
违法就违法了啊。
数据本来就非常复杂，从文件存储到数据，从sql到nosql，事物还在不断发展变化，没有一成不变的真理
违法就违法了啊。
数据本来就非常复杂，从文件存储到数据，从sql到nosql，事物还在不断发展变化，没有一成不变的真理
CodeBye 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明xml作为字段存储，有没有违背范式设计？！