privot多对多关系的中间表.PT5框架会自动把privot带上。
我们需要隐藏,因为我们不需要privot,而且pritvot也不在我们模型本身,他是中间数据
另外冗余字段,我们有一个表是记录图片的,另一个表是记录商品的。
我们可以在图片你放商品图片里的url
同时商品里放图片id和图片URL
这两个字段是重复的,这就是数据冗余,我们设计数据库是不要出现冗余信息,为啥我们用冗余呢。
主要是为了出于对查询性能的考虑。
我们在这里做了数据冗余,我们就可以减少对图片表的查询,加速查询速度!
不过推荐大家滥用数据冗余,因为数据冗余对于数据完整性,和一致性维护很困难。有两个地方记录相同的信息,但我们去写入数据的时候,就需要写入到两个地方。最大的问题在于删除和跟新。更新的时候一个地方的IMG改变了,要更改两个。否则就会产生数据不一致。不过数据冗余用的还是挺多的。
在网络开发中,除了掌握一些必要的数据库优化技巧外,在合适的时候使用冗余字段也可以做到事半功倍的效果,比如下面这样一个例子,有这么几个表,是这么设计的。
-
<李>用户表[用户]:id、用户名李
<李>项目表[项目]:id、projectName, user_id李
<李>版本表(版本):id、versionName, project_id李
<李>分类表(类别):id、categoryName, version_id李
<李>内容表[内容]:id、文本、category_id添加
差不多就是这样了。看着很不错,没有字段冗余,也符合数据库设计的三大范式。
那我们先提个问题,命名为问题X吧。
问题X:如果要查询某个版本下的内容列表,sql应该是这么写的:
好像也没什么问题。要怎么优化这个查询呢?这个问题我们最后再来说。讲回上面的表设计,如果有这样一个问题。举个例子,我要查询内容一个是否属于用户U,那我应该怎么做?
-
<李>查询内容一所属的分类B
<李>查询分类B所属的版本C
<李>查询版本C所属的项目D
<李>查询项目D是否属于用户U,从而得出内容一个是否属于用户U
这样的做法简直恶劣至极不是吗。此时你应该已深刻意识到这种表设计弱爆之处。那怎么做呢?
冗余字段!没错,我们需要在表里添加冗余字段。如果在上述表(除了用户表)都添加一个user_id字段,会怎么样呢?
首先,可以确定,每个表的user_id字段的值都不会发生改变,所以,这个字段的值从一开始设定之后,就不用再修改了。
然后,我们再回到上述的问题:查询内容一个是否属于用户,现在的做法是这样的:
查询内容是一个的user_id否为用户U的id
就一步!好简单粗暴是吧!很爽快是吧!
只需添加user_id这个冗余字段,就很大程度地方便了编码量,而且数据库的查询效率也提升N倍。还有,这个字段只需要维护一次!
现在知道冗余字段的威力了吧,回到问题x怎么优化那个业务逻辑呢?
正确的做法应该是:在内容表中,添加多一个version_id字段,可以肯定,这个字段跟user_id字段类似,只需要维护一次。
然后问题X的sql改为:
相当简单的sql !
以上说明,有时候,适当的数据库冗余是个不错的选择。
<强>总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对的支持。如果你想了解更多相关内容请查看下面相关链接
