|
经过数次技术革新，iVX在iH5的基础上做出了重大升级，其中涉及到数据库访问和操作的优化。为了使用户更好的了解和使用iVX进行应用开发，本文将系统的介绍iVX和iH5在数据库方面的区别。
一、数据库访问机制  iH5与iVX数据库访问机制对比图
在iH5中，客户端作为逻辑处理中枢，可以直接访问和更新数据库，相应的逻辑运算与鉴权等也都是在前端进行的，这样会使得应用存在一定程度的性能问题和安全隐患，容易被黑客破解前端协议后直接访问并修改数据库的数据。因此，iH5不适合用于大规模或对安全性要求高的应用，例如投票和抽奖等。
出于以上考虑，iVX将前后台进行了分离，并增加了一个服务层。服务层作为中间层和逻辑处理中枢，负责处理前端的各种请求。数据库的访问和相关后台运算等都封装到服务中完成，所有前后端的数据交互，都需经由服务实现。当前端需要访问或操作后台数据库数据时，首先需要在前端发起服务请求，并将相关查询参数一起发送至后台；服务开始后，调用后台逻辑实现数据库的输出、更新，并返回相应数据至前端。因此，相较于iH5来说，iVX只将服务暴露出来，安全性得以有效提升。对于抽奖、投票以及其它大型应用的开发，更推荐使用iVX进行开发。
二、新增后台逻辑
在iH5中，所有的鉴权与逻辑运算，都是通过将数据库数据输出至前端，然后在前端进行判断和运算，这种方式在性能上不够优化，逻辑上也不够清晰，且存在安全性问题。另外，如果直接让数据库逐个输出，还会出现数据返回时间不一致的情况。
对于复杂的大型应用而言，通常需要实现多个数据库配合存储或输出数据，以及对数据进行一系列运算处理。针对这一问题，iVX新增了后台逻辑，可以在同一个服务中同时完成多个数据库的操作及数据处理，能够解决数据的一致性问题，同时也使得业务逻辑更加清晰明了，增强了应用的可维护性。
以投票应用为例，通常需要两个数据库进行关联操作，一个用于鉴权或判断用户投票次数，另一个用于记录候选人所得票数，当符合投票条件后才能进行投票。在iH5中，要实现这一逻辑，就需要发送两个请求。首先发起用户鉴权或查询投票次数请求，返回前端判断符合投票条件后，再发起第二个投票请求。由于鉴权与投票分为了两步请求，用户等待时间相对更长，黑客也可以绕过第一步直接访问第二个请求进行刷票。而在iVX中，用户投票权限验证与投票操作可以在同一个服务中一并完成，从而减少了请求次数，并且用户投票鉴权是在后台验证的，有效防止了刷票行为。 
三、后台使用量限制
如果某个案例滥用数据库操作消耗过多后台计算资源，可能导致整个数据库平台运行缓慢，从而会影响平台其它应用的正常访问和运行。为了防止这一情况出现，iVX对每个案例的后台使用量进行了限制。iVX应用默认托管到公共服务器上，支持的同时最大连接数为50/应用。如果当前已经超过了最大连接数限制，那么在有服务运行完毕释放连接之前，后续的服务请求将无法执行，访问者将接收到“服务器繁忙，请稍后再试。”的提示。对于有更高的计算量和并发量需求的应用开发，例如参与人数较多的抽奖或投票活动，iVX提供了独立虚拟机服务，用户可按需购买不同配置的虚拟机以保证大型应用的高并发运行。
四、新增特殊功能数据库
iVX除了提供普通的应用数据库和账号数据库外，还提供了一些带有特殊功能的数据库，例如用户表、电商、投票、路由表。这些特殊功能数据库，是在通用功能的数据库之上添加了特定的额外功能。用户数据库提供用户的注册与登录服务，投票组件提供了候选人信息和投票流水的记录，电商组件提供了商品清单、购物车及订单相关的服务。用户在开发相应类型的应用时，可按需选择iVX提供的这些特殊功能数据库。
五、新增数据库索引
在iVX中可以为数据库的字段索引，这一功能在iH5中不支持。
索引是对数据库中一个或多个列的值进行排序的一种结构，其主要目的是加快数据库的查询速度。例如需要从用户表中查询ID等于10000的用户数据，如果没有索引，必须遍历整个表，直到ID等于10000的这一行被找到为止；有了索引之后(必须是在ID这一列上建立的索引)，即可在索引中查找。由于索引是经过某种算法优化过的，因而查找次数要少的多，查询速度也就更快。
虽然索引的建立在提高检索效率方面具有诸多积极的作用，但还是存在一些弊端，例如，在对表中的数据进行增加、删除或者是修改操作时，索引还需要进行动态的维护，会减慢数据库写入的速度。因此，建议在优化数据库性能时，只为经常用作查询条件的字段添加索引。
六、新增全文搜索
在iVX中新增了数据库的全文搜索功能，它是另一种索引，也是一个非常强大的功能。
全文搜索会自动根据用户搜索内容进行自动分词，并在数据库中匹配，返回相关性最高的结果。任何勾选了“全文搜索”的字段，就会进入全文搜索库，可通过数据库的“全文搜索”动作来进行查询。
全文搜索使用方法如下，首先在数据库中设置全文搜索索引，然后调用数据库的“全文搜索”动作即可。 
iVX的全文搜索使用了elasticSearch结合当前mysql数据库的组合功能，尽管在使用中不会有任何察觉，但全文搜索是一个很消耗后台资源的操作，因此，请务必不要将无关的字段勾选上全文搜索功能，否则会造成不必要的后台消耗。另外，全文搜索新建索引需要时间，如果案例已经有很多数据了，然后再勾选全文搜索索引，将需要几分钟的时间建立索引，因此建议在案例开始运营前就确定全文搜索字段。
七、新增数据库事务
iVX新增了数据库事务，以保证数据的一致性和完整性。
数据库事务通常指对数据库进行读或写的一个操作序列，例如投票应用中插入投票流水并更新票数。它为数据库操作提供了一个从失败中恢复到正常状态的方法，同时提供了数据库即使在异常状态下仍能保持一致性的方法。当多个应用程序在并发访问数据库时，也可以在这些应用程序之间提供一个隔离方法，以防止彼此的操作互相干扰。
以投票应用为例，限制每个用户只有一次投票机会。用户点击投票后，首先要向投票流水数据库写入该用户的投票记录，然后再更新候选人表中相应候选人的票数。如果第一步投票记录提交成功，但第二步的票数更新失败，那么该用户就无法再次投票，这种情况下，就可以使用数据库事务进行数据回滚，以保证投票记录和票数的一致性。
使用iVX开发应用时，可以将一系列相关数据库操作添加到事务中，然后在服务中调用事务并执行事务内部动作。当其中某一步操作失败时，可调用“回滚事务”动作来撤销当前事务内对数据库进行的所有操作。
八、新增数据库视图
在iVX中新增了数据库视图功能。视图是从一个或几个基本表中导出的虚拟的表，能够简化复杂的数据库查询，同时也是一种增加数据安全性的方法。视图数据随着基表的更新而更新，用户通过视图只能查询他们所能看到的数据，不可随意更改和删除。 
九、新增字段类型及条件 
iH5数据库字段  iVX数据库字段
在iH5中，数据库字段可以选择文本、数值和图片三种类型。在iVX中，新增了时间和Json这两种字段类型，以便存储与时间相关的数据和结构化的数据。
“时间”类型的字段对应于对应于MySQL中的datetime类型的字段，用来存储一个特定的时间点，比如：“2019-12-03 12:00:00”，可精确到毫秒。时间字段提供了更方便的时间处理，用户可在数据库输出时，选择输出大于或小于某个时间字段的记录。“JSON”类型非常适用于结构化的数据存储，可将某个数组或对象的值直接存储至JSON字段。
另外，iVX还新增了字段的提交条件与大小写区分。勾选“不可插入重复数据”后，可防止向数据库提交重复的数据；勾选“搜索区分大小写”，可使数据库筛选输出时严格区分英文大小写（默认情况下不会区分大小写。例如，搜索字段名为“abc”的记录，那么值为“ABC”时也符合条件）。
十、预览版与发布版数据库
在iVX中，应用分为预览版和发布版，以保证更高效开发和更安全生产。其中，预览版通常用于开发测试，发布版则用于正式上线使用。iVX应用的后台也分别对应了预览环境和发布环境。为了让应用运行时数据更加稳定，iVX将预览版的数据库与发布版数据库进行了分了，因此任意一个数据库组件，都分别对应了预览数据表和发布数据表。 
iVX数据库
预览版与发布版的数据完全隔离。每次发布案例时，系统都会将预览版数据表的结构（字段名称、类型及顺序）同步至发布版数据表。如需将预览版的数据同步至发布版，可点击发布版数据表头部的“同步预览版数据”进行同步。
鉴于iVX在以上各个方面对数据库进行的优化，建议用户在开发大型复杂案例或高安全性需求的应用时，优先使用iVX进行开发。在另一篇文章中，我们也对一些常见应用场景中的数据模型进行了总结，详情请查看《iVX应用中常见的数据模型》。
|
