1.学习概述
在准备达梦DCA认证考试的过程中，我系统学习了数据库各类基础对象相关理论知识，同时结合银河麒麟操作系统环境完成大量实操练习。数据库对象是数据库的核心组成单元，业务系统所有的数据存储、查询、逻辑封装都依赖表、索引、视图、函数、存储过程等对象完成。本次学习目标是掌握各类数据库对象的概念、创建、修改、删除、使用场景，理解不同对象的适用边界，做到既能熟练完成基础实操，也能够理解背后的业务使用逻辑，为后续售前技术交流、项目POC打下基础。
2.各类数据库对象概念与实操理解
2.1.表（Table）
表是数据库最基础的存储对象，用来存储业务真实数据，由行和列组成，每一列定义字段类型、约束条件，每一行代表一条业务记录。实操中我练习了普通表、分区表的创建，配置主键、非空、唯一、检查约束。

我的理解：表相当于现实业务中的一张登记表，约束就是登记表的填写规则，比如主键保证每条记录唯一，非空约束保证关键字段不能为空。分区表适合海量数据场景，把大表拆分为多个分区，提升查询、清理历史数据的效率。
2.2.索引（Index）
索引是数据库中用于加速检索的一种数据结果，类似于数据的目录。它通过预排序关键字段的引用，减少查询时的全表扫描开销。
一种数据库对象
通过指针加速查询速度
通过快速定位数据的方法，减少磁盘I/O
索引与表相互独立，且占用存储空间
数据库自动使用和维护索引
索引是否调用看优化器
索引分为：聚簇索引（有且只有一个）、非聚簇索引（二级索引）、全文索引、位图索引、空间索引。非聚簇索引包括唯一/非唯一索引、函数索引、组合索引、全局索引和分区索引。全文索引、位图索引、空间索引采用B+树存储，与聚簇索引和非聚簇索引的存储逻辑不同。

我的理解：索引不是越多越好。索引可以加速查询，但是表做插入、更新、删除（DML）的时候，数据库同时也要维护索引数据，索引过多会造成写入性能下降。只有针对高频查询过滤字段建立索引，才能发挥索引的价值。
2.3.视图（View）
视图是虚拟对象，本身不存储真实业务数据，本质是封装好的一条SELECT查询语句。访问视图的时候，数据库会执行对应的查询返回结果。可以简化复杂多表查询，同时也可以做权限控制，只开放部分字段给业务用户。

我的理解：视图可以把多表关联的复杂SQL封装起来，业务人员直接查询视图，不用写复杂关联语句。但是视图不存储数据，底层基表数据发生变化，视图返回结果同步变化。
2.4.函数（Function）
函数分为内置系统函数和用户自定义函数。自定义函数接收输入参数，经过内部逻辑处理后返回一个返回值，可以在 SQL 语句中直接调用。

我的理解：函数适合封装通用计算逻辑，比如数据格式转换、简单数值计算。函数有返回值，可以嵌入 select 语句；注意函数内部不能执行事务提交回滚操作。
2.5.存储过程（Stored Procedure）
存储过程是一组编译保存在数据库内部的 SQL 语句集合，可以实现复杂业务逻辑，支持入参、出参，没有返回值，可以包含 DML、事务控制逻辑，适合完成一批次的业务处理。

我的理解：存储过程和函数很容易混淆，核心区别：函数必须有返回值；存储过程侧重完成一批业务处理，支持事务，不能直接在 select 中调用。大量复杂业务逻辑封装在存储过程，减少应用和数据库之间的网络交互。
3.达梦与 Oracle 数据库对象的差异对比
因为近期学习Oracle数据库基础知识，在DCA实操练习过程中，我也重点对比了两类数据库在数据库对象层面的异同，帮助自己规避迁移过程中的坑点。
表与约束：整体语法高度兼容，达梦高度兼容Oracle建表语法；部分参数、数据类型存在细微差异，Oracle部分特有字段类型迁移到达梦需要做类型映射。
索引：两者B树索引使用逻辑基本一致；达梦支持的索引类型更加贴合国产信创环境。
视图：视图创建、查询语法几乎完全兼容；可更新视图的约束逻辑大体保持一致。
函数与存储过程：PL/SQL语法大部分兼容，达梦支持PL/SQL与DMPL两种过程化语言。大部分Oracle存储过程、自定义函数可以直接迁移，但是少数Oracle特有内置函数，达梦需要改写替换；部分异常处理、包语法需要做少量适配调整。
迁移启发：在做Oracle向达梦迁移项目的时候，表、索引、视图这类对象迁移成本较低；存储过程、自定义函数是迁移工作量最大的部分，需要重点做语法校验和功能测试。
4.实操过程遇到的问题与错误复盘
在DCA练习实操练习阶段，我踩过不少实际的问题，这些错误也加深了我对数据库对象的理解：
使用视图做update更新操作时报错。误以为视图可以无条件修改数据，实操报错后才理解：视图本质是查询语句，视图的DML修改会受到底层基表约束、键保留表条件的限制。
5.学习心得
通过本次针对表、索引、视图、函数、存储过程等数据库对象的学习和DCA上机实操，我不再只停留在背诵概念，而是理解每一类对象的设计初衷、适用场景以及对应的代价。
举一个模拟业务场景帮助理解：假设我们要做一套企业员工管理业务系统。
首先我们需要业务表存储员工编号、姓名、部门、入职时间等真实员工数据，同时增加主键、非空约束保证数据合规。
业务经常按员工编号查询员工信息，我们就在员工编号字段建立索引，提升查询效率。
业务系统需要经常查询员工与所属部门的关联信息，就可以把多表关联SQL封装成视图，业务直接查询视图，不用重复写复杂关联语句。
如果业务需要统一处理员工薪资计算逻辑，可以编写自定义函数，输入薪资参数返回计算结果，直接在查询语句中调用。
如果需要批量完成一批员工岗位调整、数据归档、批量更新业务，就可以编写存储过程，封装整套业务逻辑，支持事务控制，一次调用完成整套业务处理。
从这个场景也能看出来，各类数据库对象不是孤立存在，而是相互配合共同支撑业务。同时结合Oracle与达梦的对比学习，我认识到达梦对Oracle语法高兼容，极大降低迁移成本，但并不是100%完全等同，存储过程、函数这类过程化对象是迁移的重点关注点。
在实操中踩过的一系列错误也提醒我：学习数据库不能只看理论，一定要动手实操。很多知识点只有报错踩坑之后，才能真正记住限制条件。后续工作中，不管是做项目实施还是售前技术交流，我都要结合业务场景去判断应该选用哪一种数据库对象，而不是机械套用语法。同时在Oracle迁移到达梦的场景中，重点关注存储过程、函数的语法适配，提前做好验证，规避项目风险。