数据库表越多越好？

Question

最近我一直在重新思考我几个月前制作的数据库设计.主要原因是昨晚我读了vBulletin的数据库模式,看到他们使用了许多很多表.

我用于我的模式的当前"想法",例如我的日志表,是通过使用整数区分Log的类型来将所有内容保存在一个表中:

id, type, type_id, action, message
1 ,    1,     305,      2, 'Explanation for user Ban'
2,     2,    1045,      1, 'Reason for deletion of Article'

哪里type 1 = user, type 2 = article,type_id = the ID of the user, article or w/e和action 2 = ban, action 1 = deletion.

我应该将设计更改为两个表logBans,logSomething依此类推？或者保持我目前正在使用的方法更好吗？

Answer 1

这里的问题是子类型.处理子类型有三种基本方法.

每种策略都有其优点.

例如,如果不同的子类型之间几乎没有差异,则(3)特别适用.在您的情况下,如果不同的日志记录属于特定类型,那么它们是否会有额外的列？如果他们没有,或者他们把所有这些都放在一张桌子上的情况很少,那就非常有意义了.

(2)常用于Party表.这是CRM中的常见模型,涉及父类对象,其具有人员和组织的子类型(组织也可能具有公司,关联等子类型).人和组织具有不同的属性(例如称呼,给定名称,出生日期等等),因此将其拆分而不是使用可空列是有意义的.

(2)可能更节省空间(尽管现代DBMS中NULL列的开销非常低).更大的问题是(2)可能会让开发人员更加困惑.你会遇到某种情况,某人需要在某个地方存储一个额外的字段,并且会在该类型为空的列中将其打包,因为这样做比获得DBA添加列更容易(不,我不是在开玩笑) ).

根据我的经验,(1)可能是3中最不常用的方案.

最后,必须考虑可扩展性,这可能是(1)的最佳情况.在某些点上,JOIN不能有效扩展,您需要使用某种分区方案来减少表的大小.(1)是这样做的一种方法(但是粗略的方法).

不过我不会太担心.在成为问题之前,您通常需要获得数亿或数十亿条记录(除非您的记录真的很大,在这种情况下它会更快发生).

Answer 2

这取决于.如果您将拥有1500,000个类型1的条目和1000个类型2的条目,并且您将在类型2上执行大量查询,请将表分开.如果没有,只保留一个表更方便.

请记住可扩展性: