rdf数据库和mysql_RDF搜索引擎——数据库设计心得

数据库的设计是一个项目的基石，数据库的设计质量直接影响着后期代码开发的进度，关于我们组数据库的具体设计可以参考另一篇博客(RDF搜索引擎——数据库具体设计)这里只谈一些设计过程中的心得和体会。

一，数据库设计流程

关于数据库设计流程不同课本不同网站都有不同看法，经过这次项目实践，我总结了比较适合自己的数据库设计流程以及每个流程一些需要注意的事项。

首先数据库的整个设计流程中从设计到最后检验都要始终注意数据完整性约束，包括实体完整性，引用完整性，域完整性，用户定义的完整性(业务规则约束)

确定需求：设计数据库前一定要先仔细分析清需求后再动手，磨刀不误砍柴工，需求分析不足或不正确就开始设计数据库后期会需要反复改(这次就因为太急了导致后期改了好多次┬＿┬)

确定实体：简单的数据库可能不需要分析实体直接上，但稍微大点的项目先分析出实体对设计数据库很有帮助。这里可以借助E-R图来进行辅助分析。

确定表格：大体设计出表格，这里要注意的是关系数据库中的“关系”，要注意区分之前分析出的实体之间的关系是一对一，一对多还是多对多，如果是多对多需要一张额外的关系表来表达彼此的关系。

确定字段：分析确定好表格中的字段，包括字段是否可以为空，数据类型，主外键，是否设置索引等等，这一步和前一步可以结合数据库设计的三个范式进行考虑。

反复检验：在正式在服务器里搭数据库前要反复检验数据库的设计的正确性以及合理性，如果不合理要及时进行修正迭代，在反复确认后再部署，尽量避免部署了数据库后发现了问题再返回重新设计，这样损失会比较大。

二，数据库的设计合理性问题

数据库设计没有唯一答案，但是会有更好的答案，在实际设计数据库中不仅要考虑正确性问题，还要考虑数据库设计的合理性问题，比如一般系统都会有权限管理功能，不同权限的用户可以使用的功能不同，其中一种设计方案是不同权限的用户分别建立一个表存储，而另一个设计方案是用户都在一个表，用户组是一个表，把不同用户分到用户组，功能分配只需要给用户组分配，表面一看两者都可以实现功能，但是后者显然更合理，因为它具有良好的拓展性和复用性，因为假如现在又有了一种新的类型的用户，第一种设计方案就又需要新建一张表存储这个类型的用户，好，这也能解决，但哪一天有了100种用户呢？1000种用户呢？再比如在确保用户用户注册账号时要确保昵称的唯一性，这里可以使用触发器实现，也可以设计唯一索引进行限制，但是哪个更好一些呢？这个是不是也需要我们去思考！所以我们设计数据库不仅要设计的正确，还要设计的合理，要有拓展性复用性，同时性能，可靠性也要好。

三，数据库的设计理论要结合实践

理论要结合实践，课本知识要辩证的吸收，比如课堂上讲到存储过程时更多地是在讲存储过程的好处，鼓励大家多用存储过程，对于存储过程难以调试的缺陷几乎一笔带过，我们组这次数据库设计一开始就是严格按老师课堂上所讲把表格，视图，存储过程，触发器，权限，索引都逐个进行了思考，但到后来才了解到实际应用时会因为难以调试要尽量避免使用存储过程，不过我们不走这条弯路也意识不到理论实践要结合这一点教训。

总之，数据库设计这一路走来，感觉很不容易，收获颇丰，期待小组项目最终的成功！