时间真的如轮一样在飞转，一周的实训又一次即将结束，可是，感觉仿佛只过去了一天。实训结束也意味着这个学期也将结束。不管时间多么的飞快，这周短暂的vb程序设计实训同样让我们收益不少。首先，不说我们学到了多少专业知识，也不说我们学到了多少专业技能。在这样零下1度的天气中实训，着实是锻炼我们的意志力。人都有惰性，这是无可厚非的事实。在寒冷的天气里，赖床就更是常有的事。因为要实训，我们很多平常经常迟到的同志不得不早起。就说实训的第一天，外面飘着白雪，早上，手机的闹铃已经响过第二遍了。

我们宿舍的几个姐妹还躲在被窝里无动于衷。可是，当一个姐们突然说了一句，“这周要实训”时，我们都‘呼啦’爬了起来，以惊人的速度洗漱好，急忙赶到教室。不管平时多么懒散的同学，这次实训都表现的异样的认真。这应该算是实训赋给我们的特别礼物吧！实训的目的无非就是训练我们的操作能力，以及提高我们的专业技能。实践出真知，这是不变的真理。毫无疑问，这次vb程序设计实训让我们每一位同学都在不同程度上提高了编程技能。编程是我们的.专业课程，可是，在老师平时上课的时候，班上大部分同学都以怠慢的态度对待。所以，对这门课程学的泛泛的。

实训前，如果要我们做一个管理系统，我想班上能完成任务的同学应该寥寥无几。在实训前，我们常抱怨，编程有多么的难。一个学期的学习，我们居然都不能完全的做出一个管理系统来。而这次短短的实训，却让我们学会了做管理系统。没错，就是短短的几天，我们每位同学都完成了一个自己做的管理系统。这说明，编程它本身不是很难，而在于你是不是真正的学习了。这次实训让我深刻的明白，你的态度决定一切。就以我自己的经历来说，一个学期的学习还没没短短一周学到的多。这是为什么？主导因素就是态度。在平日的学习中，我抱着不以为然的态度，以懒散的心态对待这门课程。所以，一个学期下来，我的编程学的一塌糊涂。而这次实训，就像是一场实战，必须认真对待。而这几天踏踏实实的学习，将我平日落下的学习全都补救过来了。真的非常感谢这次实训。通过这次实训，我的编程技能确比之前实提高了不少。

更重要的是，在这次实训中，让我明白：学习或生活中发现了自己的不足，就要及时改进。不管是在学习中，还是在生活中，有不懂的没关系。而，如果不懂，也不去问，就是一件很悲哀的事情。这次实训中，我遇到了很多不懂的问题，但是，这些不懂最后都被我弄懂了。因为遇到不懂的不会做的我及时主动询问了周围的同学。同学不懂的，我又询问了老师。不要认为问别人是一件让人很羞耻的事情。不懂就问，不但不会让你蒙羞，反而能显示你的真实与谦虚。

总之，这次实训我又有不少新收获。

最后，还要感谢这次实训期间周围同学的热情帮助和老师的热心讲解与指导。

数据库心得体会篇2

在大二的下学期刚学了数据库这门课，对这门课的第一印象是书本蛮厚的，感觉学起来应该会很难很累。在学习这门课的过程中，在对数据库的了解过程中，慢慢对数据库有了感观。数据库这一词并不是很难想象，并不是像外人看来很神奇。作为计算机专业的学生，这样的专业术语或者专业知识是最基本的。

学习的时候没有想象中的那么难，只要上课能听懂就基本还可以。但是问题还是出在书本有点厚，有的时候上课的内容都要找很久才能找到，甚至有的时候老师讲的知识书本上是找不到的，是另外补充而且是相当重要的内容。有的时候开小差，没有听到老师讲的知识点，这就导致了以后的学习无法顺利进行，使得学习起来十分困难。所以在数据库这门课的学习中，上课一定要听牢，就像老师说的那样，这样的专业课如果想凭考试前几天突击是行不通的，必须是日积月累的知识才能取得好成绩。

通过对数据库的学习，我也明白了各行各业都离不开数据库，就算是一个小型的超市也离不开它。可见数据库这门课的广泛性，如果能够认真学好它将来必有成就。我就是抱着这种信念去学习数据库的。第一次接触数据库，第一次接触sql语言，虽然陌生，但是可以让我从头开始学，就算没有基础的人也可以学得很好。刚开始练习sql语言的时候，并不是很难，基本上都是按照老师的步骤来做，还很有成就感。后来学了单表查询和连接查询后，就慢慢发现越学越困难了，每个题目都要思考很久，并且每个题目基本上不止一个答案，所以必须找出最优的答案。后面的删除、插入、修改这些题目都变化蛮大的，书本上的例题根本无法满足我们，好在老师给我们提供了大量的课件，通过这些ppt，我们可以巩固课内的知识，还可以学习内容相关的知识，更好地完成老师布置的作业。

除了老师布置的一些基本作业外，还有一份大作业。就像我们小组的是杂货店的销售管理系统，在完成这一作业的过程中，我们可以通过网络实现一家杂货店。过程是很复杂的，杂货店需要员工，还有百来种商品，不仅需要大量的数据，还要完成需求说明，数据词典，还有e-r图等，虽然想象起来并不是很难，但是要转化成文字，转化成人们能够读懂的文字就显得十分困难。特别是一个完整的销售系统，对我们来说都是第一次接触，在做大作业的时候经常是前面改改，后面改改，因为一些数据不能很好地对应起来，经常会遗忘一些，所以出现了这样的情况。一个完整的数据库系统也就是在这样修修改改的状态下完成的，也给了我很大的反思。第一、一个数据库的完成一定要考虑各方面的因素，包括现实因素。第

二、在完成这类作业时，修修改改是很正常的，不要因此而厌倦。第三、一个完整的数据库一定不能出现错误，否则会在现实生活中带来不必要的麻烦。

通过本学期数据库的学习及大作业的完成，很有去作项目的冲动，但深知自己的能力水平有限，还需要更多的学习。

数据库心得体会篇3

这次数据库课程设计用的是microsoft visual foxpro 6.0 ，而我们平时用的microsoft sql server ，虽然对vfp完全陌生，但在老师的指引下，我们近乎完美的完成了课程设计。当然过程是艰辛的。

面对着完全陌生的操作环境vfp，许多同学开始埋怨，要求用sql，用我们学过的asp等来完成设计。但我们慢慢发现用vfp做课程设计其实很有优势，于是它的这个优势激发了我们去了解它的欲望。老师先将vfp中基本的建数据库，建表以及建表单等向我们演示了一遍，我们也仿照着做了，发觉并不是很难。但想到这次课程设计做的是一套学生学籍和成绩管理系统，我们又开始茫然了。那天，老师给我们看了一段可以让文字循环移动的代码，这使我们产生了好奇心理，有了快速了解它的冲动。因为用面向对象的语言做特效，这还是第一次。下课之后我把那段我们不了解的语言写的特效代码发到了vfp论坛上请人帮忙解释，最后我们完全理解了那段代码的意思。

这次课程设计我们克服了炎热的天气（学校机房之前没装空调……后来设计完才装……），也克服对新知识的恐惧感以及畏难情绪。我们懂得了团队合作的重要性，也懂得了团队中如何交流、如何分工，如何集体讨论难点。我们充分利用了网络资源（技术论坛，共享的实例等）。

我们喜欢这次课程设计的感觉，喜欢编程，喜欢团队交流。数据库课程设计心得体会篇13

由于平时接触的都是一些私人项目，这些项目大都是一些类库，其他人的交流相对可以忽略不计，因此也就不考虑规范化的文档。实际上从学习的经历来看，我们接触的知识体系都是属于比较老或比较传统的，与现在发展迅速的it行业相比很多情况已不再适用，尤其是当开源模式逐渐走近开发者后更是如此。

虽然这次是一个数据库课程设计，由于本人在选择项目的时候是本着对自己有实际应用价值的角度考虑的，所以其中也涉及到一些数据库以外的设计。对于ooa/ood的开发模式有时不免要提出一些疑问，uml是设计阶段的工具，而它基本涵盖了软件设计的方方面面，也就是说按照这一软件工程的正常流程，在动手写第一句代码之前，开发人员已经非常熟悉软件产品了，这对于相当有经验的架构师一类人说可能会很容易，但是我们作为学生，连足够的编码经验都没有，却首先被教授并要求先ooa再oop，这样直接导致的问题就是文档与编码对不上号，在修改代码的时候基本不会再去审查文档和先前的分析。甚至根本就是现有代码再有文档，即便是这种情况，代码与文档还是不对应。不可否认，在传统软件工程的详细设计之前的项目过程中还是有很多利于项目开发的部分的。所以我就一直在寻找适合我——针对探究型项目——的开发模式，这次的项目也算是一次尝试，当然这个过程并不会太短。

回到数据库设计上了，这次的数据库设计我是严格按照数据库建模的步骤来进行的，老实说我并没有感觉这样的流程对开发带来多大的帮助，反倒是觉得将思维转化为图表很浪费时间。总体上来说这次的项目也不是很大，而且在数据库的设计上比较保守，也就是说实际上数据库设计还可以再完善完善的。随着我对计算机领域的拓宽和加深，我也会静下心来思考在接触计算机之前的行为，很多次我能深切感觉到，其实我的大脑（未于别人比较）本身就是在使用一种更接近关系数据库的方式来记忆，所以我很可恨自然的设计出符合三范式的表结构来，即便我不知道这些范式的确切含义。可能就像"范式不太容易用通俗易懂的方式解释"一样，在"让工具用图标表述我的思维"时费了一番力气。

从我作为项目的提出人和实现者来看，这是个失败的项目，结合几次教学项目的的`实践，发现这也已经不是第一次了。主观原因占多数，比如，尝试新的开发方式，根据设计花了太多的时间来抽象出公用的库而忽略业务逻辑。就这次项目而言，失败的原因有以下几点：

使用了新的开发环境（vim），这是首次在脱离高级ide的情况下编码。

使用了新的开发语言（python，actionscript3），因为我一直比较喜欢"学以致用"，而且这样的"数据驱动型"软件的整套自实现的库都已经完成了，但是由于语言本身的差异，迁移时问题很多，当发现这一点是，已没有多少有效剩余时间了。

编码流程的不妥，我比较喜欢从底层的库开始开发，因为一旦库测试通过，将很容易将它放到不同的表示层下。但如果库没有测试成功，将导致整个项目没有任何可视化模型，所以这次的项目无法提交"可运行的代码"。

实践目的的不同，我轻易不放弃锻炼的机会，事实上，有机会就一定要比以前有所突破，总是照搬以前的做法还不如就不做呢。这个前提是因为现在能完全用来的学习的时间比较多，等到工作时再这样做的可能性就很小了，因此当然要抓紧机会了。不过还有一个隐藏原因，总以为自己很了不起，其实"遇到的问题数跟人的能力是成正比的"。

数据库心得体会篇4

这次实习是一个操作类的实习，那么久对比下以前操作过的软件，对比一下二者不同，我们使用的软件主要是arcgis软件和mapgis软件。首先是mapgis软件。mapgis软件的优点在于界面清楚，鼠标交互性强，需要功能或者对某对象操作时右键可以找到相应操作。比如导入图层新建图层等，arcgis要新建图层则需要在规定的地理数据库中新建一个数据集，然后对其进行编辑。在分析方法方面mapgis的功能也比较齐全。我使用的mapgis版本唯一一个我比较不满意的地方是操作较快是比较容易程序崩溃;再来我也是用了arcgis做后面的实习19，arcgis的鼠标交互性相对来说弱一点，但是arcgis的优点也是比较好的，首先它的功能模块分得比较清楚，我不需要为了一个功能找很多地方，然后对于对象图层的分析与操作功能都放在工具箱中，我可以设置哪些功能开启，哪些功能关闭，节约操作或者分析速度。当我想把数据在两种软件中混用的时候，可以转化文件为标准shp文件，两软件的通信就是这样了。只不过这其中除了一点问题，不同版本软件在转换数据的时候会不可避免的出现数据丢失受损或者异常等情况，只能再次操作。

以后我再对着不同的软件进行操作的时候，会注意他们的操作风格，是偏鼠标还是键盘，是分一套功能还是分模块。然后这次实习的过程其实也是蛮重要的，不仅仅是一些操作过程。

我们在之前的实习中从来没有一次是对arccatalog的操作做得这么详细，全面。这次实习也是一次查漏补缺，将以前很多没有用到的东西都给补上了。我在做这次实习之前，arcgis的软件对我来说就是这几样功能：

1、编辑地图

2、发布地图生成服务

3、导出文件应用到其它科目

但是现在我知道了自己以前的这些操作是很狭隘的，只是仅仅包括了一些很小的功能。对于数据库这块的操作正是我以前所没有认真做或者深层次的接触的。当我把这次实习的第二部分做完以后，收获的确是不小的，虽然实习所用的版本和我用的软件版本不同，甚至于有些步骤根本做不了，但是毕竟还是有很多的相似之处。除了几何网络的那里没有实施之外，其他的都做了，即便是一个很简单的步骤也做了一下，感受下两个版本的不同。在阅读实习材料的过程中我其实很想找到一些：“为什么这样操作”的解释，但是没有，然后就自己找了下一些步骤做法的原因。比如说：为什么要将要素类两张表合成一张表，这是可以减少数据冗余的。思考，得出结果，总结经验，这才是实习需要有的效果。希望以后会有更多这种查漏补缺类型的实习，弥补自身不足。

数据库心得体会篇5

两个星期时间非常快就过去了，这两个星期不敢说自己有多大进步，获得了多少知识，但起码是了解了项目开发部分过程。虽说上过数据库上过管理信息系统等相关课程，但是没有亲身经历过相关设计工作细节。这次实习证实提供了一个很好机会。

通过这次课程设计发现这其中需要很多知识我们没有接触过，去图书馆查资料时候发现我们前边所学到仅仅是皮毛，还有很多需要我们掌握东西我们根本不知道。同时也发现有很多已经学过东西我们没有理解到位，不能灵活运用于实际，不能很好用来解决问题，这就需要我们不断大量实践，通过不断自学，不断地发现问题，思考问题，进而解决问题。在这个过程中我们将深刻理解所学知识，同时也可以学到不少很实用东西。从各种文档阅读到开始需求分析、概念结构设计、逻辑结构设计、物理结构设计。亲身体验了一回系统设计开发过程。很多东西书上写很清楚，貌似看着也很简单，思路非常清晰。但真正需要自己想办法去设计一个系统时候才发现其中难度。经常做到后面突然就发现自己一开始设计有问题，然后又回去翻工，在各种反复中不断完善自己想法。

我想有这样问题不止我一个，事后想想是一开始着手做时候下手过于轻快，或者说是根本不了解自己要做这个系统是给谁用。因为没有事先做过仔细用户调查，不知道整个业务流程，也不知道用户需要什么功能就忙着开发，这是作为设计开发人员需要特别警惕避免，不然会给后来工作带来很大的麻烦，甚至可能会需要全盘推倒重来。所以以后课程设计要特别注意这一块设计。

按照要求，我们做是机票预订系统。说实话，我对这个是一无所知，没有订过机票，也不知道航空公司是怎么一个流程。盲目开始设计下场我已经尝过了，结果就是出来一个四不像设计方案，没有什么实际用处。没有前期调查，仅从指导书上那几条要求着手是不够。

在需求分析过程中，我们通过上网查资料，去图书馆查阅相关资料，结合我们生活经验，根据可行性研究结果和客户要求，分析现有情况及问题，采用client/server结构，将机票预定系统划分为两个子系统：客户端子系统，服务器端子系统。在两周时间里，不断地对程序及各模块进行修改、编译、调试、运行，其间遇到很多问题：由于忘记了一些java语言规范使得在调试过程中一些错误没有发现，通过这次课程设计，我对调试掌握得更加熟练了，意识到了程序语言规范性以及我们在编程时要有严谨态度，同时在写程序时如有一定量注释，既增加了程序可读性，也可以使自己在读程序时更容易。

我们学习并应用了sql语言，对数据库创建、修改、删除方法有了一定了解，通过导入表和删除表、更改表学会了对于表一些操作，为了建立一个关系数据库信息管理系统，必须得经过系统调研、需求分析、概念设计、逻辑设计、物理设计、系统调试、维护以及系统评价一般过程，为毕业设计打下基础。

很多事情不是想象中那么简单，它涉及到各种实体、属性、数据流程、数据处理等等。很多时候感觉后面设计根本无法继续，感觉像是被前面做各种图限制了。在做关系模型转换时候碰到有些实体即可以认为是实体又可以作为属性，为了避免冗余，尽量按照属性处理了。

物理结构设计基本没有碰到问题，这一块和安全性、完整性不觉就会在物理结构设计中添加一些安全设置：主键约束、check约束、default定义等。最后才做索引部分，对一些比较经常使用搜索列，外键上建立索引，这样可以明显加快检索速度，最后别忘记重要安全性设置，限制用户访问权限，新建用户并和数据库用户做相应映射。

不管做什么，我们都要相信自己，不能畏惧，不能怕遇到困难，什么都需要去尝试，有些你开始认为很难事在你尝试之后你可能会发现原来她并没有你以前觉得那样，自己也是可以。如果没有自信，没有目标，没有信心就不可能把事情做好，当其他人都在迷茫时候，自己一定要坚信目标，大学毕业出去即面临找工作，从学习这个专业，到以后从事这方面工作都需要不断地去学习去实践，这次实践可以给我们敲一个警钟，我们面临毕业，面临择业，需要这些实践经验，在困难面前要勇于尝试，这是这次课程设计给我最大感想！

以上基本是这次实习体会了，设计进行非常艰难，编码非常不容易，才发现做一个项目最重要不在于如何实现，而是实现之前需求分析和模块设计。创新很难，有些流行系统其实现并不难，难在于对市场分析和准确定位。设计，是一个任重道远过程。

数据库心得体会篇6

在这次课程设计中，我们小组设计的是一个仓库管理系统，通过设计这个系统，可以更方便地实现信息的浏览，查询，添加等操作和报表输出等功能，具体包括能实现产品入库管理，可以填写入库单，确认产品入库；产品出库管理，可以填写出库单，确认出库；借出管理，凭借条借出，然后能够还库；初始库存设置，设置库存的初始值，库存的上下警戒限；可以进行盘库，反映每月，年的库存情况；可以查询产品入库情况，出库情况，当前库存情况，可以按出库单，入库单，产品，时间进行查询；虽然这个系统的功能还不是很完善，还有很多功能尚未实现，但这也是我们共同努力的结果，只要有更多的时间，我相信我们能完成的更好。

通过这次将近一个星期的课程设计实训，我对数据库在生活中的广泛应用有了更深的体会，同时也加深了对access20xx的.认识，了解了相关的access的知识，尤其是对数据库的原理与开发程序的应用有了更进一步的认识和了解。由于不会vb编程，很多功能实现起来很困难，但好在access有查询、宏和窗体，特别是宏操作可以将几个操作结合在一起，可以执行多个查询，可以调用多次窗体。例如，在某个窗体中要显示设备代码表信息，所以这个窗体中建立一个子窗体用于设备代码表的显示，我们打开窗体后又对设备代码表进行了跟新，所以窗体中显示的并不是最新数据，我们往往需要及时看到设备代码表跟新后的最新数据，窗体不会自动跟新我们就不会看到最新数据，所以这时候我们就会用一个宏操作在对设备代码表跟新之后关闭窗体在打开窗体，这样窗体就相当于完成了一次跟新操作。又例如，在一个表a中刚刚追加了一条记录，我们要将每次刚刚新添加的记录跟新到另一个表b中，用一个查询是很难完成的，经过认真思考，得到了解决的办法是，需要三个步骤，第一步，在表a中添加标志字段，设置默认值为‘否’。第二步，编写跟新查询将标志字段为‘否’的数据跟新到表b中。第三步，编写跟新查询将表a中标志字段为‘否’的跟新为‘是’。

经过这次课程设计，是我明白团队的力量是最大的，至少三个臭皮匠顶个诸葛亮，何况我们都是充满激情的团队。我想在以后的工作中我一定要做到多思考多与团队交流，遇到难题一定要有必胜的信心

数据库心得体会篇7

今天进行了一次完整的数据库设计的过程，其实一直来说我都是非常害怕数据库的设计的，因为在刚刚接触的时候，我就知道，数据库设计其实是一个项目的开端，因为数据库设计实际上就是业务的设计，在需求清晰的时候，完成清晰流畅的业务设计又是一大难点。

一下为我自己的心得经验希望大家批评指正！

数据库设计应该遵循以下几个原则：

对需求的认知完全没有歧义；

熟练而且正确的e-r图绘制，明确改图是表明实体和关系的图，实体表示要在数据库里保存的类，关系表示类与类之间的相互关系，关系主要有一对一，一对多，多对多。经验之谈，继承关系通常可以用一对一表示，而一对多或者多对多通常表示类之间的使用关系；

在设计时要做到高度的抽象，对内容或者关系相类似的内容抽象为一类实体，在分类时可以抽象出一个“类”的实体，与要分类实体之间进行多对多关系映射，明确哪些是必须要进行存储的实体；

如果系统涉及用户角色的不同不妨把，账户和身份的考虑分离开，账户的存在让他是一直存在的并且在身份变化时个人的历史和基础内容是不变的，就是身份的加持让他可以有特权或者使命，而账户是他在系统中的根；

对于有值内容，并且需要对值进行统计结果的需要对他进行内容的拆分，比如：问卷表和问卷内容表，问卷内容值表要拆开，才有利于统计计算，而且他们之间是一对多关系；

有时更加困难的是一个实体会发生多个维度的分类，那么就把他的拆分维度一一分开；

“频道”概念在消息分发时是一个非常灵活的概念；