#SQL

前言

ensemble里边实现分页比较麻烦，毕竟对于sql的书写比较麻烦，单表的查询相对简单，对于多表的关联查询单纯的sql不好查询，我们使用sql进行先查询出主表满足条件的rowId,在根据根据满足条件的rowid进行遍历取值。

思路

我们先取对比一下其他数据库实现的原理。

1. Mysql的实现原理
   总数：SELECT COUNT(*) AS total FROM person WHERE (name LIKE ?)
   分页：SELECT id,name,age,email FROM person WHERE (name LIKE ?) LIMIT ?,?

FHIR® SQL Builder或 Builder 是 InterSystems IRIS 医疗版数据平台 的一个组件。它是一种复杂的投射工具，用于将 InterSystems IRIS 医疗版数据平台FHIR 存储库中的数据创建为自定义的 SQL 模式，而无需将数据移动到单独的 SQL 存储库中。 Builder 专门设计用于与 InterSystems IRIS 医疗版数据平台中的 FHIR 存储库和多模型数据库配合使用。

InterSystems 常见问题解答

通过在持久类（=table）定义中提供的%BuildIndices() 方法的参数中指定要重建索引的 ID 的开始值和结束值，您可以仅重建该范围内的索引。

例如，要仅针对 ID=10 到 20 重建 Sample.Person 类中的 NameIDX 索引和 ZipCode 索引，请执行以下代码（ID 范围在第 5 个和第 6 个参数中指定）。

我用%SQLGatewayConnection把别人给我的数据转为sql 写入mysql的时候，如果数据里面有 ascii 码为57659 这样的数据的时候，

InterSystems IRIS 目前将类限制为 999 个属性。

但是，如果您需要为每个对象存储更多数据该怎么办？

本文将回答这个问题（附加了社区 Python 网关的客串以及如何将广泛的数据集传输到 Python 中）。

答案其实很简单 - InterSystems IRIS 目前将类限制为 999 个属性，但不限制 999 个基元(primitives)。 InterSystems IRIS 中的属性可以是具有 999 个属性的对象等等 - 该限制很容易被忽略。

案例描述

假设您是一名 Python 开发人员或拥有一支训练有素的 Python 专业团队，但您分析 IRIS 中某些数据的期限很紧迫。当然，InterSystems 提供了许多用于各种分析和处理的工具。然而，在给定的场景中，最好使用旧的 Pandas 来完成工作，然后将 IRIS 留到下次使用。
对于上述情况和许多其他情况，您可能需要从 IRIS 获取表来管理 InterSystems 产品之外的数据。但是，当您有任何格式（即 CSV、TXT 或 Pickle）的外部表时，您可能还需要以相反的方式执行操作，您需要在其上导入并使用 IRIS 工具。
无论您是否必须处理上述问题，Innovatium让我明白，了解更多解决编码问题的方法总是能派上用场。好消息是，从 IRIS 引入表时，您不需要经历创建新表、传输所有行以及调整每种类型的繁琐过程。
本文将向您展示如何通过几行代码快速将 IRIS 表转换为 Pandas 数据框架并向后转换。您可以在我的GitHub上查看代码，您可以在其中找到包含本教程每个步骤的 Jupiter Notebook。

如今，关于大语言模型、人工智能等的消息不绝于耳。向量数据库是其中的一部分，并且已经有非IRIS的技术实现了向量数据库。

为什么是向量？

• 相似性搜索：向量可以进行高效的相似性搜索，例如在数据集中查找最相似的项目或文档。传统的关系数据库是为精确匹配搜索而设计的，不适合图像或文本相似性搜索等任务。
• 灵活性：向量表示形式用途广泛，可以从各种数据类型派生，例如文本（通过 Word2Vec、BERT 等嵌入）、图像（通过深度学习模型）等。
• 跨模态搜索：向量可以跨不同数据模态进行搜索。例如，给定图像的向量表示，人们可以在多模式数据库中搜索相似的图像或相关文本。

还有许多其他原因。

因此，对于这次 pyhon 竞赛，我决定尝试实现这种支持。不幸的是我没能及时完成它，下面我将解释原因。

TuneTable(调整表)收集数据库中表的统计信息，用来为SQL引擎制定最优的执行计划。在其他数据库产品里，这个动作被称为“gather stats job"或者类似的名字，相比较TuneTable不是那么直白，但作用是一样的。

TuneTable是否要人工执行

一定要。

在IRIS 2023版本， 第一次加入了TuneTable的自动执行功能，在此之前的所有IRIS/Caché版本， 如果没有人工执行TuneTable, SQL引擎无法保证给出最好的查询计划。 即使是IRIS2023有了自动执行功能，也还需要人工执行TuneTable的操作，后面解释。

IRIS/Caché查询慢，主要原因有以下几个：

• 应用是一个事务型的数据库， 数据模型的设计不适合某些复杂的分析查询

这是慢的原因，不是慢的离谱的原因。数据模型是产品设计的范畴， 这里不讨论， 本文只讨论优化。

• 历史原因，有些表的索引不够优化

虽然还是设计问题，但可以在实施中或者维护中给出优化方案。

• 产品运行中的问题造成的查询效率下降

IRIS/Caché数据平台的一个特点是允许跳过SQL约束，对底层数据的直接修改。坏的代码或者应用可能破坏表数据和表索引的约束，造成SQL性能的下降。维护人员应该知道怎么避免，和处理这样的问题。

• 维护工作缺乏造成

比如Tune Table(调整表), 这是必须做的工作，但可惜很有些项目没有执行过。

这个帖子内容有点深。如果您读的有困难，请直接跳过这篇，对绝大多数IRIS/Caché使用者，它一点都不重要。

数据库表的Collation(排序规则)本来是一个非常简单的概念。说到它是因为曾经发现过由Collation引起的性能问题。

我试图用一句话来解释数据库的排序规则：

• 绝大多数数据库因为业务查询需要，保存的字符型数据是不分大小写的。当你执行一个 order by, group by, distinct，like等等条件查询时，因为这个不分大小写的collation，你得到的结果也不分大小写。例如，对名字做group by， James, james一定是在一组。
• 如果非要区分大小写，会在查询的时候使用一个函数
• 因为要操作非英语的字符集，以及可以被当作字符看待的数字类型，适应不同的排序规则，一个数据库可能有很多种Collation类型。

很简单，在表一级定义Collation的SQL语句是：

复合索引(combined index)也被称为组合索引或者联合索引，顾名思义，就是一个索引建立在多个字段上。当用这些字段为条件查询时，相比对每个字段单独做索引，复合索引能给出很好的性能，还能减少索引的数量。

为什么能减少索引的数量？ 通常来说，也就是在其他数据库，联合索引符合”最左匹配“的原则。在BING上搜索“复合索引，得到的第一个搜索结果的这篇文章就说的就很简单明了：

下面这个SQL语句在 列X，列Y，列Z 上建立了一个复合索引。

mysql
CREATE INDEX 索引名 ON 表名(列名X, 列名Y, 列名Z);

其实这相当于建立了三个索引，分别是：

为什么要读Query Plan, 在线文档中有句话是这么说的：

While the SQL compiler tries to make the most efficient use of data as specified by the query, sometimes the author of the query knows more about some aspect of the stored data than is evident to the compiler. In this case, the author can make use of the query plan to modify the original query to provide more information or more guidance to the query compiler.

翻译一下是这样：系统给你的查询计划并不总是最好的，如果您能对查询计划，可以人工做更精细的优化。

Caché/IRIS的特点是运行Global的修改，而这个修改和SQL是无关的，因此非常容易出现数据库表数据完整性的问题，也就是表中的数据是不是符合定义的表约束。

这样的情况非常常见。有些是人为的对Global的错误修改， 有些是应用系统的事务性管理写的不对，造成事务回滚的时候破坏了索引的完整性。无论什么原因，只要使用Global操作，破坏SQL的完整性非常难以避免。结果就是SQL查询给出错误结果。

最简单的解决方法就是执行“索引检查(Validate Indices)"

我们来做个实验

- 先修改一个global： 如下图， 将Patient表的一个记录的SEX字段，从'M'改到‘F'.

运行索引检查, 结果会提示您问题在什么地方。