【DBA】手游数据库设计为什么第二种方法更优越？

Question

本帖最后由 default7 于 2014-07-17 15:42:36 编辑

Answer 1

个人感觉，比较赞同楼主的做法。因为游戏是游戏，渠道是渠道，对应是对应，很清晰明了。我想dba的想法会是从提高数据的运行效率考虑的，可以减少表的关联，能提高存储过程的执行时间。

Answer 2

现在用的是DBA的设计思路。
然后运行
SELECT AGENTNAME,COUNT(AGENTNAME)  AS TT FROM TB_AGENT GROUP BY AGENTNAME ORDER BY TT  DESC
SELECT GAMEID,COUNT(GAMEID) AS TT FROM TB_AGENT GROUP BY GAMEID ORDER BY TT DESC 
 
//很多TT都是大于1的，有的甚至100多了另外
1）如果表不加主键、不加索引可以提高速度和性能吗？
2）去获取视图的数据的话不用交表，Oracle性能没有这么差吧，两个交表就不行？。。

Answer 3

感觉有时候冗余也不完全是坏事吧，何必在意一些细节，能满足需求，有同等或更优的执行效率就更佳了。既然dba说那样做就那样做吧，咳咳~~~

Answer 4

其实我觉得楼主的设计是对的，你那个DBA是打酱油，原因如下：
1. 某些情况下，即使是OLTP数据库，冗余也是允许的，但你那个场景不需要冗余，完全可以用视图代替，而且性能也有保证
2. 那个DBA没有考虑到数据一致性的问题， 比如说，如果agent的名字发生变化，应怎样保证更新是正确的?更进一步说，如果给agent增加额外的资料，那岂不傻眼了?
3. 至于索引的问题，像你那几张表，查询的次数会远远高于增删改的次数，在这种情况下，使用索引所付出的负面代价仅仅是额外的存储空间，却带来更好的查询性能，尤其是相关的查询频率比较高的情况下。如果是我的话，我还会加上外键约束，以避免代码可能插入垃圾数据的情况出现。冗余是可以的，但不可以把允许冗余作为低级的表结构设计的借口