我们该如何设计数据库(四)

其实我一直在准备另一篇博文的基础资料,但是和朋友聊天,他问我最近在做什么,我说在做系统Log模块,并和他交流了一下,于是这篇博客就应运而生。

所有数据都可以用如下形式表述:ID,表名,列名,Value。

比如说现在有这么一条数据要插入User表:

ID(Guid,这里为了方便理解用Int)UsernamePasswordEmail
1CrazyJinn123456[email protected]

这一条记录可以转换为:

ID表名列名Value
1UserUsernameCrazyJinn
1UserPassword123456
1UserEmail[email protected]

你可以在各种对灵活性要求高的地方看到这种设计,比如说在《我们该如何设计数据库(三)》的留言中,就有园友提到了类似的设计。

当然,这种方式效率不是很高;不过可以把聚集索引加到表名上,然后非聚集索引加在列名上,再水平分割一下,如果你心情好,再做个读写分离,相信就非高并发、千万数据量级的应用来说,理论上还是可以接受的。

好了,现在进入正文。

现在要做一个通用的Log模块。

既然是通用的,那就意味着灵活性要非常强,因为你不知道Log中要记录的数据结构是如何的。

而且给我的需求有一个非常变态的地方:要有回退功能。不过这个我们先不去管他。

根据之前的讨论,我们可以很容易设计出一张Log表。

ID表名列名Type(Create\Edit\Delete)Value***修改时间

如果处理的全是无关系的问题,这样做就足够了。但是要知道,RDBMS,最重要的就是关系的处理。

比如说要Log这样两张表:

上文所设计出的Log表面对这样的一对多关系是无法储存的,不要往了,我们还有多对多关系。

当然可以拓展Log表来实现储存一对多/多对多关系,虽然我不确定能不能做到,因为我没有就这方面去深入的思考。如果您想到了好的设计,欢迎留言和我探讨。

让我们来重新思考一下Log模块的本质:

1、大量数据。

2、只是大量数据(和别的模块没有关联,纯粹的数据)。

这种场景让我不由自主的想到了Nosql。在这里,使用MongoDB来实现。关于MongoDB入门,可以参考下面两篇文章:

祥叔:《MongoDB开发学习(1)开天辟地,经典入门》

Fish Li:《MongoDB实战开发 【零基础学习,附完整Asp.net示例】》

MongoDB使用Bson来储存数据,你可以简单的把Bson理解为Json。众所周知,Json是一个非常易于扩充的,松散的的数据格式;基于Json易于扩充的特性,我们可以这样来设计Log表

LogIDID表名Content(所储存的内容,包含了***修改时间,修改类型,以及新的修改ID)

如果我对User表修改了6次,那么我们Log的数据如下图:

我们主要把注意力集中在上图用红框标注的3条数据上。

***条数据,ContactList是一个Array类型,长度为0,这表示没有对应的Contact。

第二条数据,ContactList长度变为1,这表示这次修改为User添加了一个Contact的关联,我们将第二条数据完全展开来看:

可以看到,包含了一个完整的Contact进来。

#p#

第三条数据ContactList为Null,这表示我在某个别的地方修改了User信息。这次修改没有涉及Contact,所以保存为Null。当我们取数据的时候,如果发现某个List为Null,就要递归的向上去查找不为Null的数据。例如我这里,就要去找到第二条数据的ContactList。

为了方便大家理解,我把Json贴在下面。对照前面的图片可以很好的阅读。

  1. {  
  2.   "Content" : [{  
  3.       "_id" : new BinData(3, "mtonv7sMCkewsMIjWZ9/qg=="),  
  4.       "Username" : "1",  
  5.       "Password" : "1",  
  6.       "Number" : 1,  
  7.       "LastModified" : new Date("27/11/2012 10:28:18"),  
  8.       "ContactList" : [{  
  9.           "_id" : new BinData(3, "1QwcXGKedUCO27QprZB26Q=="),  
  10.           "UserID" : new BinData(3, "YyQDfuoj6EuuDNl91leigA=="),  
  11.           "Phone" : "Phone1",  
  12.           "Email" : "Email1" 
  13.         }, {  
  14.           "_id" : new BinData(3, "EeWfiFCknkex4H2jEraR/w=="),  
  15.           "UserID" : new BinData(3, "YyQDfuoj6EuuDNl91leigA=="),  
  16.           "Phone" : "Phone2",  
  17.           "Email" : "Email2" 
  18.         }]  
  19.     }, {  
  20.       "_id" : new BinData(3, "Afk3spV0q0uKM+yNs/SHbw=="),  
  21.       "Username" : "1 to 2",  
  22.       "Password" : "1 to 2",  
  23.       "Number" : 2,  
  24.       "LastModified" : new Date("27/11/2012 10:35:03"),  
  25.       "ContactList" : []  
  26.     }, {  
  27.       "_id" : new BinData(3, "H/5o2lizmUWkaxAZUgNHzg=="),  
  28.       "Username" : "2 to 3",  
  29.       "Password" : "2 to 3",  
  30.       "Number" : 3,  
  31.       "LastModified" : new Date("27/11/2012 10:40:28"),  
  32.       "ContactList" : [{  
  33.           "_id" : new BinData(3, "7HDyGU2+A02HbQtUFbOo8A=="),  
  34.           "UserID" : new BinData(3, "H/5o2lizmUWkaxAZUgNHzg=="),  
  35.           "Phone" : "PhoneNew",  
  36.           "Email" : "EmailNew" 
  37.         }]  
  38.     }, {  
  39.       "_id" : new BinData(3, "zf2SiYW81kufGO7ZgY5r3A=="),  
  40.       "Username" : "3 to 4",  
  41.       "Password" : "3 to 4",  
  42.       "Number" : 4,  
  43.       "LastModified" : new Date("27/11/2012 10:41:34"),  
  44.       "ContactList" : null 
  45.     }, {  
  46.       "_id" : new BinData(3, "N68jDslbU0uvdHJTSq0vIg=="),  
  47.       "Username" : "5",  
  48.       "Password" : "6",  
  49.       "Number" : 7,  
  50.       "LastModified" : new Date("27/11/2012 17:14:12"),  
  51.       "ContactList" : null 
  52.     }, {  
  53.       "_id" : new BinData(3, "Fw6OqMNcc0K+rySfgz3dTg=="),  
  54.       "Username" : "9",  
  55.       "Password" : "9",  
  56.       "Number" : 9,  
  57.       "LastModified" : new Date("27/11/2012 17:16:15"),  
  58.       "ContactList" : [{  
  59.           "_id" : new BinData(3, "zfsQRK***0kGFFcnc5TZ9GA=="),  
  60.           "UserID" : new BinData(3, "YyQDfuoj6EuuDNl91leigA=="),  
  61.           "Phone" : "PhoneNew",  
  62.           "Email" : "EmailNew" 
  63.         }]  
  64.     }],  
  65.   "ModelID" : new BinData(3, "YyQDfuoj6EuuDNl91leigA=="),  
  66.   "ModelName" : "User",  
  67.   "_id" : ObjectId("50b4254257751f09a02decba")  

这样,一个Log功能的雏形就出来了

就此搁笔

原文链接:http://www.cnblogs.com/CrazyJinn/archive/2012/12/04/2794785.html

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/248557.html<

(0)
管理的头像管理
上一篇2025-04-27 15:35
下一篇 2025-04-27 15:37

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注