标签：mysql database database-design data-modeling

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

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。