mysql – 数据库表,越多越好？

最近我一直在重新思考我几个月前制作的数据库设计.主要原因是昨晚我读了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'

其中类型1 =用户,类型2 =文章,type_id =用户的ID,文章或w / e,动作2 =禁止,动作1 =删除.

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

解决方法:

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

>将每种记录类型放入一个完全独立的表中;
>将记录放在父表中,然后将记录放在子类型表中;和
>将所有记录放在一个表中,对于“可选”数据具有可为空的列(即不适用于该类型的事物).

每种策略都有其优点.

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

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

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

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

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

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

标签：mysql,database,database-design,data-modeling
来源： https://codeday.me/bug/20190714/1457290.html