基于知识图谱的岳麓书院文化资源管理系统数据库设计心得

数据库设计心得
第一次做项目，也是第一次设计数据库，学习数据库时觉得单单创建几张表不是什么难事，但当我们自己为一个系统设计数据库时才发现建表有多难。

首先对于表所含的属性的讨论，单单一个用户表就要讨论很久，因为很多属性都能放进去，很多属性也都能放在外面。例如对于账号，密码，手机号，用户名等属性就能构成用户表，其余属性例如性别，生日，个性签名等可以放个人信息表，全放在用户表里面感觉也可以，小组讨论到最后还是决定少一点表，多一点属性。

谈到用户表用户也分为普通用户和管理员用户，仅仅因为身份不同而新建一张表貌似有点浪费，因此讨论后决定利用标签来区分普通用户和管理员用户，identity char(1) 限定为0、1和2，分别代表普通用户，管理员用户，内置超级用户。标签使许多表得以简化，自我感觉有点像子类继承父类，子类不同之处只有标签代表的含义而已。

数据库最复杂的应该是主键和外键的设置吧，有些表几乎都是外键，有些表到最后还是只能用自增主键。在本系统中我们也打算增加一点小小的沟通，除了能够查询岳麓资源之外也能和志同道合的人讨论，那么就必然会有好友表以及信息表，好友表的属性设置为两个人的id，即用户表的主键，作为复合主键，但同时他们也是用户表的外键。好友表还算比较好设计，那么信息表呢？你给我发信息我给你发信息，两个id作为主键显然不再合适，只能用自增主键，自增主键也是有可能用完的，虽然我们这个项目连smallint都不可能用完，但我们还是讨论了一下假如超过了应该怎么办，最常用的方法是利用分库分表来增加容量（我特别好奇qq的信息是怎么存储的，我觉得一个信息应该有上限，所以不断复制粘贴1，最后聊天框都卡住了，稳定后发现1并不是很多，也就是有上限）。除此之外就是套娃操作不好设计表了，比如在一个帖子里面你回复我我回复你，虽然很多软件设计为展开就两级页面，但是设计起来真的麻烦，直接略过吧，给个一级回复就行了。

本次的数据库心得就是这些了，数据库设计起来确实很好玩。在后面的版本还会给数据库加上视图、触发器和索引，使其更加完整。

ps:我想把聊天框的1给删掉还卡了一下，不知道为什么超过后会卡，明明已经无法继续输入了。