HarmonyOS数据库篇之三——ORM对象关系映射数据库 原创

starLWW
发布于 2022-1-7 10:50
浏览
2收藏

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

![img](assets/md12/clip_image008.jpg)

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

**WAL日志模式:**

预写日志(WAL,Write Ahead Log)是关系型数据库中用于实现事务性和持久性的一系列技术。简单来说就是,做一个操作之前先讲这件事情记录下来。

举个例子:很多人都会有自己的备忘录,记录自己干了哪些事,这里的WAL日志就好比备忘录,记录了你做了哪些操作。

为什么要使用WAL呢?比如你的备忘录里面有如下记录:

2021.12.25 理发

2021.12.28 整容

2021.12.31 修指甲

如果某一天你忘记了自己是如何变成现在这个样子的,那你可以去翻看你的备忘录,然后按照备忘录的记录依次执行,你就能找到答案。

为什么要使用WAL呢?上面的解释比较秀逗,本节说一下真正的原因:真正的执行操作可能数据量会比较大,操作比较繁琐,并且写数据不一定是顺序写,所以如果每一次操作都要等待结果flush到可靠存储(比如磁盘)中才执行下一步操作的话,效率就太低了。换一种思路,如果我们在做真正的操作之前,先将这件事记录下来,持久化到可靠存储中(因为日志一般很小,并且是顺序写,效率很高),然后再去执行真正的操作。这样执行真正操作的时候也就不需要等待执行结果flush到磁盘再执行下一步,因为无论在哪一步出错,我们都能够根据备忘录重做一遍,得到正确的结果。

摘自: <https://blog.csdn.net/weixin_29188043/article/details/112963585>

**FULL模式:**

**1.Simple 简单恢复模式,**

Simple模式的旧称叫”Checkpoint with truncate log“,其实这个名字更形象,在Simple模式下,SQL Server会在每次checkpoint或backup之后自动截断log,也就是丢弃所有的inactive log records,仅保留用于实例启动时自动发生的instance recovery所需的少量log,这样做的好处是log文件非常小,不需要DBA去维护、备份log,但坏处也是显而易见的,就是一旦数据库出现异常,需要恢复时,最多只能恢复到上一次的备份,无法恢复到最近可用状态,因为log丢失了。 Simple模式主要用于非critical的业务,比如开发库和测试库,但是道富这边的SQL Server(即使是生产库)大都采用Simple模式,是因为这边的SQL Server大都用于非critical的业务(critical的数据库大都采用Oracle和DB2),可以忍受少于1天的数据丢失(我们的job每天都会定时备份全库)。

 如果需要压缩数据库日志(Shrink语句),将数据库模式切换到简单恢复模式后压缩率才是最高的,如果你的数据库在完整恢复模式或大容量日志回复模式下采用日志压缩,压缩后的日志大小并不会很理想。

 **2.Full 完整恢复模式,**

和Simple模式相反,Full模式的旧称叫”Checkpoint without truncate log“,也就是SQL Server不主动截断log,只有备份log之后,才可以截断log,否则log文件会一直增大,直到撑爆硬盘,因此需要部署一个job定时备份log。Full的好处是可以做point-in-time恢复,最大限度的保证数据不丢失,一般用于critical的业务环境里。缺点就是DBA需要维护log,增加人员成本(其实也就是多了定时备份log这项工作而已)。

 **3.Bulk-logged 大容量日志恢复**

Bulk-logged模式和full模式类似,唯一的不同是针对以下Bulk操作,会产生尽量少的log: 1) Bulk load operations (bcp and BULK INSERT). 2) SELECT INTO. 3) Create/drop/rebuild index 众所周知,通常bulk操作会产生大量的log,对SQL Server的性能有较大影响,bulk-logged模式的作用就在于降低这种性能影响,并防止log文件过分增长,但是它的问题是无法point-in-time恢复到包含bulk-logged record的这段时间。 Bulk-logged模式的最佳实践方案是在做bulk操作之前切换到bulk-logged,在bulk操作结束之后马上切换回full模式。

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

**注:**只有insert操作需要flush()方法,update()、delete()不使用flush()也可以实现数据的更新与删除操作。

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

**案例:假设使用对象关系模型数据库存储“单词表”,数据库名为“wordDB.db”,数据表名为“wordtable”,表字段包括:id、name、trans。能够实现单词的增删改查,以及数据变化的检测。**

准备工作:布局文件

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

1. 修改config.json

ohos {

​    **compileOptions{**

​        **annotationEnabled true**

**}**

……

}

2. 在Slice中初始化组件并给按钮注册监听器

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

3. 创建数据库及数据表

数据表实体类

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

数据库类

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

4. 实现按钮点击事件

**初始化数据库**

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

**插入数据**

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

**查询数据**

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

**更新数据**

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

**删除数据**

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

5. 自定义数据变化观察者类

HarmonyOS数据库篇之三——ORM对象关系映射数据库-鸿蒙开发者社区

©著作权归作者所有,如需转载,请注明出处,否则将追究法律责任
已于2022-1-7 10:50:15修改
2
收藏 2
回复
举报
回复
    相关推荐