DBA中为什么手游开发中 oracle数据库设计第二种方案更优越

Question

需求

存放“游戏资料数据”、“渠道资料”。

方案

我的方案

1.需要3张表 TB_GAME,TB_AGENT,TB_RELATION
2.表TB_GAME结构

GAMEID    int                 主键，SEQ序列递增
GAMENAME  varchar2 (60)

3.表TB_AGENT 结构

AGENTID        INT            主键,SEQ序列递增
PARENTID       INT            索引，上级ID
AGENTNAME      VARCHAR2(60)

4.表TB_RELATION 结构

ID            INT        主键,SEQ序列递增
GAMEID        INT        索引
AGENTID       INT        索引

游戏GAME，渠道AGENT全部独立，关联关系全部存入到RELATION表。
每个表都必须加上主键，RELATION表的GAMEID AGENTID全部设置上索引。

---

DBA方案

1.仅需要2张表 TB_GAME,TB_AGENT
2.表TB_GAME结构

GAMEID        INT
GAMENAME      VARCHAR2(256)

3.表TB_AGENT结构

AGENTID        INT
AGENTNAME      VARCHAR2(256)
PARENTID       INT
GAMEID         INT

AGENT与GAME是一对一，比如有一个游戏叫“三国”，他的渠道是“百度”，然后又有一个游戏叫“mm”，他的渠道也是百度，那么渠道表AGENT就会有两条记录，他们的AGENTNAME都是=百度。
而且如果一个主渠道（TB_AGENT.PARENTID=0）ID为 1001，那么他子渠道(TB_AGENT.PARENTID=1001)的所有子渠道的ID都是以1001 开头，这样不会导致重复吗？
Oracle存在自动递增序列，为什么不能用自动递增？

比如一个主渠道他的ID是 1005，他已经有一个子渠道 10052025，那么如果再给他新增一个子渠道。那么新增这个子渠道的ID是这样算的，先得到他父ID，和该父ID下的子渠道ID中ID最大的那个。10052025中去掉ID1005剩下2025，再2025+1，就得到了2026，拼接上父ID 1005，那么他的ID就是 10052026。为什么这样设计更优越。。。

---

疑问

我认为这样存在的不足
为什么说第二种DBA设计方案更优越？为什么很多程序员会用手动拼接主键ID？
为什么DBA设计的表没有一个字段上加了索引、主键、或者唯一，还是说oracle加了主键索引跟没加没有多大区别？

Answer 1

加索引的目的是加快查询速度，但是会增加容量。
DBA不加索引我的认为的可能是这个表本身数据就不多，无所谓加不加索引。
虽然第一种方案看上去结构更清晰，但是当联表查询的时候尽量会要求表越少表越好。

Answer 2

我看你可以提议DBA把他的两张表合成一张表，冗余就冗余吧，修改起来也快，因为记录条数显而易见就那么点。

不要在意类似这种记录条数可预见的表设计方案，任何一种方案都是可行的，再怎么设计，慢也慢不到哪里，快也快不到哪去。在我看来，你的方案也没问题。

Answer 3

DBA设计的方案，表TB_AGENT明显是存在冗余，对增加表TB_AGENT更新的成本。
如修改某个Agent的名称，本来是只需要更新一条记录，但是由于TB_AGENT增加了GAMEID字段，如果这个Agent代理了10个游戏，就需要更新10条记录。

好处就是根据GAMEID查找对应的Agent的时候，如果按照你的方案，需要做TB_RELATION和TB_AGENT表关联，如果判断这样的关联会造成性能瓶颈的话，才会采用这种反模式的设计。

另外对于ID的判断，个人认为使用Oracle的序列，开发和使用起来比较简单。如果按照DBA的方案，每次插入一个子渠道，还需要查询一次所有子渠道的最大值，无形中增加了数据库的负担。除非是想通过ID直接查询Agent的下属Agent，不再使用PARENTID字段。

总体上我认为DBA的设计是不合理的，如果确实存在数据量大的问题，应该考虑通过缓存等方案解决，没必要在数据库底层搞个冗余的结构。