搜索​​​​

InterSystems IRIS、IRIS for Health 以及 HealthShare Health Connect 的 2021.2 版本的预览版现已发布。 由于这是一个预览版，我们希望在下个通用版本发布之前了解您对这个新版本的体验。请通过开发者社区分享您的反馈，以便我们能够共同打造一个更好的产品。 InterSystems IRIS 数据平台 在 2021.2 版本中使开发、部署和管理用于连接数据、应用孤岛的增强型应用和业务流程变得更加容易。它有许多新的功能，包括： 为应用程序和界面开发人员提供的增强功能： 嵌入式Python 使用 Python 进行的互操作性Production开发 对Visual Studio Code ObjectScript扩展包的更新 增加了新的商业服务和操作，允许用户用最少的自定义编码来设置和运行SQL查询 对数据分析和人工智能的增强： 新的SQL LOAD命令有效地将CSV和JDBC源的数据加载到表中 增强自适应分析功能 对云和云上运营任务的增强： 新的云连接器使得在 InterSystems IRIS 应用程序中访问和使用云服务变得简单。 IKO的改进提高了Kubernetes 资源的可管理性 针对数据库和系统管理员的增强功能： 在线分片再平衡可以在不中断操作的情况下自动在各节点间分配数据 自适应 SQL 引擎使用快速块采样和自动化来收集高级表的统计数据，并利用运行时信息来改进查询规划 通过新的流类型数据和日志文件压缩设置，减少InterSystems IRIS的存储需求 使用系统提供的库，支持 TLS 1.3 和 OpenSSL 1.1.1 新的^TRACE工具报告详细的进程统计数据，如缓存点击率和读取率 关于所有这些功能的更多细节可以在产品文档中找到。 InterSystems IRIS 2021.1文档和发布说明 InterSystems IRIS for Health 2021.1 文档和发布说明 HealthShare Health Connect 2021.1 文档和发布说明 InterSystems IRIS 2021.2是一个持续交付（CD）版本，现在为所有支持的平台提供经典安装包，以及OCI（Open Container Initiative）又称Docker容器格式的容器镜像。 容器镜像可用于符合OCI标准的Linux x86-64和Linux ARM64的运行时引擎，详见支持平台。 每个产品的完整安装包都可以从WRC的产品下载网站获得。使用 "自定义 "安装选项，用户可以选择他们需要的选项，如 InterSystems Studio 和IntegratedML，以合理地缩小安装内容。 安装包和预览密钥可以从WRC的预览下载站点获得。 企业版、社区版和所有相应组件的容器镜像可以通过以下命令从 InterSystems容器注册中心获得。 docker pull containers.intersystems.com/intersystems/iris:2021.2.0.617.0 docker pull containers.intersystems.com/intersystems/iris-ml:2021.2.0.617.0 docker pull containers.intersystems.com/intersystems/irishealth:2021.2.0.617.0 docker pull containers.intersystems.com/intersystems/irishealth-ml:2021.2.0.617.0 关于可用镜像的完整列表，请参考ICR文档。 另外，所有容器镜像的tarball版本可以通过WRC的预览版下载网站获得。 该预览版的构建号是2021.2.0.617.0。

我在 InterSystems 工作了 35 年，期间见证了许多客户与我们共同成长。我们热忱地帮助客户取得成功——无论他们衡量成功的标准是什么——而成功的基石就是我们提供的技术。我们的名字现在通常与我们的 InterSystems IRIS 数据平台联系在一起，因为它实际上是我们经过验证的下一代数据管理软件。 在InterSystems IRIS 之前，我们以 Caché 和Ensemble 的强大功能而闻名，全球许多最重要的应用都是在它们的帮助下得以面世的。如果您也是我们的Caché 或 Ensemble 客户，这些平台如今无疑是您组织基础设施的重要组成部分，是一些优秀应用的基础。 然而，正如我们不断发展我们的技术，我们也希望帮助您发展现有技术，并使您能够利用最新的数据平台技术——即从人工智能(AI) 到云计算的各种最新技术。我们认为 InterSystems IRIS 的时代已来临，因此，我们将为所有现有的 Caché 和Ensemble 客户提供限时免费迁移到InterSystems IRIS 数据平台的机会。 我们理解，对业已成为您业务重要组成部分的现有解决方案进行任何更改，都将是一项艰巨的任务，但请相信我们，这一切都是值得的。我们的一面之词也许不足为信，但我们现有的许多客户已经做出了这样的转变，其中包括医疗软件公司Epic。 作为一个使用我们技术超过 40 年的忠实客户，Epic 去年决定迁移到InterSystems IRIS。其系统拥有 250 万并发用户，每秒处理大约 18 亿次数据库访问，因此，能够平稳迁移至关重要。通过我们的共同努力，迁移非常顺利。现在Epic 的客户体验到了更高的性能和更佳的可扩展性。 在此列举部分迁移到InterSystems IRIS 可拥有的优势： 更高的性能、可扩展性和资源效率 通过迁移，您将能够以小博大，用更少的资源做更多的事情，并同时管理多种不同类型的工作负载。为了让您更好地理解这一所指，我们通过速度测试（Speed Test）得出，与其他主流数据管理软件相比，InterSystems IRIS 在测试期间多摄取了 620.9% 的记录，在测试结束时多摄取了 717.3% 的记录。 开发人员生产力 InterSystemsIRIS 具有化繁为简的功能。您的开发人员可以在一个平台内构建和测试所有应用，现在使用嵌入式Python，您可以访问更大的开发资源池，以及数十万个可用的Python 库。从而让开发周期更短，控制和管理更简单。 云部署 作为一个“云中立”的平台，InterSystemsIRIS 不会将您与任何云供应商绑定。因此更加经济、高效和敏捷。 机器学习 我们的IntegratedML 功能为创建机器学习 (ML) 模型提供了一种简单的机制，让您更轻松地将 ML 模型实施到您的实时应用中。 Adaptive Analytics自适应分析 利用新的自适应分析 (Adaptive Analytics) 功能，您的组织无需依赖IT，即可更轻松地探索和分析数据。这意味着业务用户将能够获得他们所需的洞察力，从而做出明智的业务决策，并使您的 IT 团队专注于其他工作。 互操作性和 API 管理能力 通过迁移，您可以实时获得所有数据的统一视图。利用我们的数据平台，您可以连接不同的系统、技术和数据，为您的业务用户创建单一虚拟管理界面，或为您的企业应用创建实时连接。 轻松实现迁移 迁移到InterSystems IRIS 的理由，除了上述这些之外，还有很多。 如果您准备迁移到 InterSystems IRIS（已有数百个 Caché和 Ensemble 客户成功迁移），您可以登录www.intersystems.com/migrate了解更多关于如何迁移到 InterSystems IRIS 上的信息。 原文：Unleashing InterSystems IRIS: Why it’s time to migrate your Caché and Ensemble applications 关于作者 John Paladino负责InterSystems的支持、质量保证、内部计算机操作及客户教育工作。自1984年加入InterSystems以来，他帮助开发了自动化支持跟踪系统和针对所有InterSystems软件产品的客户培训项目，制定并实施了旨在改善响应性、提高客户满意度的服务标准，以及多个国内外团队建设计划。在加入InterSystems之前，他曾在New England Pathology担任了三年的系统工程经理，负责获取、实施和管理各类信息技术。Paladino曾在伍斯特理工学院和马萨诸塞大学卢维尔分校攻读电机工程专业。

您可能已经听说，我们目前正在为所有正在使用 Caché 和 Ensemble 的客户提供限时免费迁移到我们的下一代数据平台 InterSystems IRIS 的机会。 虽然我们依旧如往常一样全力支持那些正在使用 Caché 数据库和 Ensemble 集成引擎的客户，但我们还是认为 InterSystems IRIS 是未来的关键。它结合了 Caché 和 Ensemble 的所有功能，并添加了大量令人兴奋的强大功能，从机器学习到原生 Python。 这也正是我们为现有客户提供迁移到 InterSystems IRIS 并使用这些新功能的原因。 我们也通过就地迁移支持轻松迁移，这意味着无需数据库转换、分步迁移指南、教程等。 听起来挺有趣对吗？ 以下是我针对当前 Caché 和 Ensemble 应迁移到 InterSystems IRIS 的五个主要原因。 1. 根据您的需求量身定制的工具： InterSystems IRIS 本身有标准工具，例如根据 InterSystems IRIS 开发人员量身定制的 Visual Studio Code 编辑器。InterSystems IRIS 允许您在容器中运行应用程序，在 Kubernetes 中工作，并在您选择的云中轻松部署，这对于初学者有非常大的帮助。 2. 面向 SQL 开发人员的机器学习： 我们在 InterSystems IRIS 中嵌入了 IntegratedML 功能，使 SQL 开发人员无需成为数据科学或机器学习工具方面的专家，只需要几个类似 SQL 的命令即可轻松开发机器学习模型。 最重要的是，这些功能使您能够将机器学习模型无缝嵌入到 InterSystems IRIS 应用程序中，从而将它们转换为支持机器学习的智能应用程序。 3. 使用嵌入式 Python 提高生产力： 由于我们实现了 Python 的内置服务器端支持，我们的下一代技术使应用程序开发人员的工作效率更高。所有强大的功能都可以使用 Python 或 ObjectScript 调用，并且您的 Python 代码可以与 ObjectScript 代码无缝交互。 此外，我们为大量开发语言提供广泛的客户端支持，包括 Python、Java、C# 和 Node.js 等等。 4. 为 InterSystems IRIS 准备您的应用程序： 我们已经记录了 Caché 和 Ensemble 以及 InterSystems IRIS 之间的差异。在某些情况下，您可能需要对现有应用程序进行一些调整以满足与 InterSystems IRIS 相关的要求。 或者，您也可以采用与 Caché、Ensemble 和 InterSystems IRIS 兼容的通用代码库。这种方法的好处是您可以立即开始，确保您只有一个代码库需要维护，并在执行迁移时消除任何额外的调整。 这是我们许多大型企业客户经常采用的方法。 5. 易于迁移： 将您现有的 Caché 和 Ensemble 应用程序迁移到 InterSystems IRIS 是快速、简单且经过验证的。 查看我们的“迁移到 InterSystems IRIS”操作指南，您可以从我们的全球响应中心（需要登录 WRC）下载该指南，以确保无缝迁移。 现在是最好的时间 迁移只是旅程的开始，因此为了确保您从强大的 InterSystems IRIS 功能中获得最大收益，我们创建了各种文档、视频和在线学习资源，以帮助您解锁所有这些强大的功能。 现在是迁移到 InterSystems IRIS 的最佳时机。 只需联系您的 InterSystems 销售工程师或销售总监，即可享受此限时优惠。 了解更多信息：InterSystems.com/migrate。 关于作者：Jeff Fried InterSystems 产品管理总监 Jeff Fried 是一位长期从事数据管理的，尤其热衷于帮助人们创建强大的数据驱动应用程序。 在加入 InterSystems 之前，Jeff 曾担任 BA Insight、Empirix 和 Teloquent 的 CTO，并负责 FAST Search and Transfer 和 Microsoft 的产品管理。 他在数据管理、文本分析、企业搜索和互操作性方面拥有丰富的经验。Jeff是该行业的常客和作家；拥有15项专利；并撰写了 50 多篇技术论文并合着了三本技术书籍。 查看原文

InterSystems面向中国用户推出InterSystems IRIS医疗版互联互通套件，以满足医院信息化建设的标准化要求，促进业务协同，助力公立医院高效建设互联互通平台。

不是所有的多模型数据库都是相同的 作者：David Menninger 今天，许多现代应用程序需要的数据库管理能力往往不能通过一种方式就能实现。例如，当我建立一个支持旅游推荐和预订业务的应用程序时，我可能需要使用一些不同类型的数据库，包括用于用户会话的键值存储，用于产品目录的文档数据库，用于推荐的图形数据库，以及用于财务数据的关系数据库。由于各种原因，选择一个（关系型）数据库就可以了这种一刀切的数据库时代，已经离我们很远了。虽然关系型数据库仍然是许多应用的正确选择，但对于某些类型的应用，非关系型数据库提供了关系型数据库根本无法提供的优势。 关系型数据库用表和行表示数据，并使用结构化查询语言（SQL）来访问和操作数据。对于需要可靠性和ACID（原子性、一致性、隔离性和持久性）保证的事务性应用，以及需要SQL查询和报告的效率和简单性的应用，它们是一个很好的选择。 但是，关系型数据库是有代价的；它们需要数据库管理员，需要遵守预先定义的关系型结构，而且随着数据规模和工作负载的增加，它们的扩展也不经济。尽管如此，关系型数据库仍然是许多关键任务应用的正确选择，并继续为其提供动力。 相比之下，非关系型数据库，包括文档、对象、图形和键值数据库等，比关系型数据库具有某些优势--尤其是在灵活性和扩展性方面。非关系型数据库不需要DBA创建预先定义的模式，应用程序开发人员能够更容易地存储和管理数据，而不必担心映射固定的数据结构。 幸运的是，所有这些不同种类的数据库技术都是很成熟稳健的，也为应用开发者提供了丰富的功能，他们可以善加利用。 今天市场上有数以百计的数据库；非关系型数据库约占所有部署到生产中的数据库的一半。 但是，将多种数据库技术纳入一个应用程序并不总是那么简单。 多模型的一种方法--称为混合持久化--采用不同的数据库来支持每种类型的数据结构。 这是一种最佳的方法。 但是，在应用程序的整个生命周期中实施、同步和维护不同的数据库系统是复杂的，而且容易出错。 另一种方法是使用业界所称的多模型数据库；一种在同一 "产品 "中支持各种数据表示的数据库。但不是所有的多模型数据库都是一样的。有些数据库坚持混合范式，为不同的数据表示法采用多个独立的数据库引擎，造成数据的重复，并需要在不同的数据存储之间进行映射和整合。 还有一些支持引擎内的不同模型，但不支持相同的数据。 在InterSystems，我们已经开发了一种纯粹的多模型数据库管理方法。我们的产品，InterSystems IRIS数据平台存储了数据的单一表示。它利用了一个单一的数据库引擎，支持关系型和非关系型的数据访问和操作，没有重复。对于非关系型访问，它不需要预先定义的模式。它提供事务性的ACID保证，可以纵向和横向扩展，并支持本地、公共和私有云环境，以及混合（公共/公共、公共/私有、云/本地）部署环境。同样的数据可以使用SQL访问和操作，也可以作为文档、对象或键值数据。应用程序开发人员不需要使用多个数据库，也不需要在多个数据存储中整合和同步数据。 我们的多模型方法整合了关系型和非关系型技术的优点，而摒弃了其缺点，也没有与多角化持久性相关的复杂性或低效率。 所有这些都整合在我们从头开始建立的这个单一的数据库管理系统中了。 （David Menninger是Ventana Research的高级副总裁和研究总监，也是长期的行业老兵，他对多种数据表示的需求以及多模型数据库的各种方法的优势和劣势进行了深刻的分析。你可以在这里阅读他的报告。） https://www.intersystems.com/data-excellence-blog/not-all-multi-model-dbms-are-created-equal/

亲爱的社区开发者们，大家好！ 现在参与Gartner Peer Insight同业评审对我们的产品做出评价，可获得价值 $25 美元的礼品卡。评论观点需中立客观（InterSystems员工不允许参加）并被Gartner审核通过。点击此处开始： https://gtnr.it/3ulVX4K 。 对流程不熟悉的同学，可以参考一下我们此前发布的一篇旧贴。 调研仅花费您很少时间，欢迎大家积极参与！ 活动已经截止了。。。

大家好！ 我们很高兴地向大家介绍我们开发者社区中文版的新版主——段海华（ @Duan.Haihua）！ 让我们以热烈的掌声欢迎段海华（ @Duan.Haihua），以下是他的个人介绍。 段海华，东华医为利润中心副主管 以下是他的个人介绍 @Duan.Haihua： – 我主持参加了多家医院的互联互通评审工作，并主持了互联互通成熟度测评（Health Information Connectivity Maturity Evaluation, HICME）工具的开发与维护。我有丰富的基于InterSystems产品和项目工作经验，对互联互通测评相关标准有较深刻的理解。 – 通过开发者社区，我希望能够帮助刚开始接触互联互通标准的开发者快速理解相应内容，分享互联互通测评过程中常见问题的解决方案，为开发者对系统标准化改造过程提供参考意见。 热烈欢迎！ 感谢段海华的付出（ @Duan.Haihua）！我们相信你会成为一名优秀的版主！ 👏🏼 热烈欢迎👏！！！

当我和加州大学戴维斯分校健康中心的同事着手简化提供者对基因组数据报告的访问时，我们希望这些信息能帮助临床医生提供更好、更个性化的护理。 我们的基因组数据没有操作界面，既不可搜索，也不与患者图表相关联。 如果我们可以在 FHIR（快速医疗互操作性资源）连接器上利用SMART原则在平台之间实现单点登录，我们的护理团队就可以更早地获得数据，患者将能够更好地得到照顾，并在与癌症的斗争中取得积极成果。 而这也是正在实现的事情。 我们支持基因组数据报告的工作为临床医生带来了 50 个离散数据点，这意味着医生用于搜索报告的时间更少，也拥有了更多具有重要洞察力的离散数据，简化了对临床试验信息的访问，最终患者也得到了及时的护理。 但我们并没有停下脚步，这不过是迈向更广阔数字领域的第一步。在 InterSystems 的帮助下，我们拥有了规模越来越大、类型更多样的数据集。 回到本文的标题——什么是医疗数字领域的门户？它是某人（通常是患者）与您的医疗单位的每次虚拟来往的总和。根据研究公司 IDC 的数据，到 2023 年，65% 的患者都将会通过这样的门户和对应的医疗机构进行来往，但剩下的其他人呢？所以在加州大学戴维斯分校健康中心，我们决心建立一个欢迎所有人的数字门户——不仅是基因组数据供应商，还有患者、付款人和合作伙伴。 通过变得更加灵活和高效，我们不断推陈出新，提高整个健康中心的效率，并优化对患者的护理。 以下是我总结的为什么数字门户可以帮助每个医疗机构的观点： 1. 是时候加强互操作性工作了 在加州大学戴维斯分校健康中心，我们决定推动我们的数字门户战略，也因为我们不想被 FHIR 潮流所抛弃。随着苹果等公司的健康应用工具使用率的不断上升，基于SMART原则和FHIR构建的应用程序一直在不断提醒供应商们尽快去拿到多年来一直对第三方关闭的数据，而我们的数字门户成为了我们巧妙地驾驭 FHIR 潮流所需的工具和技术。 此外，很明显，《21世纪药物法案草案》将要求医疗系统支持更进一步的互操作性，以便患者访问其数据。 没有多少医疗机构为此制定了数字门户战略。 尽管我们花了数年时间从本土遗留系统和内部应用程序过渡到同类最佳技术，但互操作性描述了数据在内部移动，而不是外部移动。 我们本可以选择将付款人和合作伙伴直接连接到我们的 EHR，但这无法访问位于其他地方的数据。 对于我们的合作伙伴来说，这也可能意味着更高的成本和更大的难度，同时每个应用程序和合作伙伴连接都受制于各自的供应商。 现在，我们加州大学戴维斯分校健康中心使用首选的解决方案堆栈开发了自己的架构——InterSystems IRIS for Health™ 和 HealthShare® 处理了平台外存储的大量数据、连接的非 FHIR 应用程序，并使我们能够创建确保所有合作伙伴都能访问的规则。 在一年多一点的时间里，我们为 InterSystems API 管理器部署了一个开发端点，我们正在与几个合作伙伴合作开展试点项目，以将它们连接到我们的 API 库。 世界正在快速发展时，医疗行业也必须如此。 2. 你真的想用大量不同的技术去拼凑你的数字门户吗？ 加州大学戴维斯分校健康中心的数字门户之所以能脱颖而出，是因为我们决心要打造围绕一个互操作性的先进中心。 大多数医疗系统采用联合模型，在一个桶中解决临床数据聚合以及与 FHIR、接口和研究相关的举措。 在加州大学戴维斯分校健康中心，我们有一个专门的团队和一个支持模型来推动整个组织内的数据交换。这意味着强大的灵活性。 例如，新冠病毒的来临颠覆了一切，许多医院不得不与三个甚至更多的供应商争吵，以适应对虚拟服务不断增长的需求。 而我们只用一个小组就快速完成了工作。 随着美国互操作性核心数据 (USCDI) 标准的实施，医疗系统必须能够访问电子健康信息，这些信息存在于医疗系统、数字生态系统的每个角落和缝隙中。 共享存在于 EHR 中的临床数据是不够的。宽阔的数字门户——通过一个入口点就可以进入——是我们最好的选择。 3. 走在时代的前沿 我知道并非所有医疗系统都拥有相同的资源，但任何人都可以适应的技术才是真正的创新。 医疗机构需要根据 USCDI 标准为患者数据的访问去开发解决方案。 如果您具备了这样的开发能力，为什么不多做一步——授权患者、付款人和合作伙伴都能够使用这种资源呢？ 如果您这样做了，您会发现您已准备好应对围绕基因组学、远程患者监测以及未来的任何其他事物所带来的创新。 关于作者：Michael Marchant Michael Marchant 在过去 25 年多的时间里一直在和复杂的技术打交道，他一直致力于整合数据，以引领医疗机构的发展。Michael 一直与应用程序供应商、提供商组织以及政府密切合作，领导团队并提供所需的解决方案、技术、工作流程，致力于内部以及当地乃至全国的互操作性推动。 Michael 目前担任加州大学戴维斯分校健康中心的健康信息交换和系统集成总监，他和他的团队为他的组织和社区解决了大量复杂的技术难题和互操作性层面的挑战。 Michael 热衷于推动将患者和患者的健康信息联系起来的技术，并帮助患者能够控制何人、何时以及何地可以访问这些信息。 点击查看原文 2021年12月8日——全球领导力峰会，立刻注册！ InterSystems 可以帮助您实现互操作性和数据集成目标。立刻联系我们！

在医疗领域，开发创新可以挽救更多的生命。 这也是为什么我们更需要去倾听负责构建未来的人：开发人员。 他们需要什么工具才能更有效地使应用程序更加高效？ 他们面对着什么样的障碍？ InterSystems 不想去做无用的猜测，因此我们推动进行了一项研究，该研究综合了 200 名医疗行业开发者的反馈，深入了解了他们的最大需求。我们认为，这些研究结果为医疗单位和医疗技术公司提供了一个机会，可以帮助他们的开发团队为业务带来新机遇，同样也为临床医生和患者带来更光明的未来。 以下是三个关键要点： 1. 开发人员想要一个统一的医疗平台。 在接受本次研究采访的 200 名开发人员中，有88% 的受访者表示他们是医疗 IT 领域的专家或该领域的技术人员——他们都希望能有最好的、为他们的行业量身定制的开发工具。 这就是为什么一半的受访者将统一的、专注于医疗的数据平台列为购买新开发工具的关键原因。 一个合适的医疗行业开发平台应该包括互操作性/集成引擎、分析工具、面向医疗行业的自然语言处理功能、机器学习工具和 FHIR 服务器，以及其他组件。 如果一家公司能够提供一个包含所有上述组件的平台，那么超过 90% 的开发人员将对这项技术非常感兴趣。 2. 临床数据模型必不可少 近 90% 的开发人员表示，技术供应商提供的临床数据模型是必不可少的，如果按照 10 分制来统计，这个需求会达到8 分甚至更高。 来自 EHR 的临床数据被 60% 的开发人员列为最优先的一类。而其他数据还包括CRM、医疗设备、健康的社会决定因素、索赔、财务和运营的数据。 3. 健康数据是实现价值的最快途径 干净、健康的数据将高质量企业与其他企业区分开来。 在开发人员希望技术供应商提供更干净、更健康数据的大背景下，这次研究的受访者表示，选择能够提供最干净数据的平台尤为重要。 一站式医疗保健平台 根据该报告，一线开发人员及管理层都想要这样一个医疗保健数据平台： （1）专注于医疗IT行业 （2）可扩展性 （3）与现有的开发工具兼容 （4）安全 （5）便于使用 我们推动进行这项研究是为了帮助我们确定 InterSystems IRIS for Health™ 的发展方向，而这也是一个专门设计用于从医疗数据中提取价值的数据平台。 开发人员使用该平台、使用这些旨在满足现代医疗需求的、安全的工具来创建和扩展医疗应用程序。 我们对这次的研究结果感到鼓舞，我们也将继续专注以使平台变得更好！ 医疗 IT 软件开发人员面临的关键问题。 点击阅读最新研究结果！ 想试用 InterSystems IRIS 数据平台吗？立刻免费编码！ 关于作者：Chris Walker 领导 InterSystems 的业务开发团队，该团队正在帮助合作伙伴使用软件工具和服务来加速和增强他们推向市场的数字解决方案。 在他职业生涯的早期，他为麻省总医院开发了临床信息系统，并在健康和生命科学信息管理方面拥有超过 25 年的经验。 点击查看原文

亲爱的社区开发者们，大家好！ 我们欢迎您来参加 2021年欧洲医疗编程马拉松 ，这一赛事时间为2021年11月19日-21日，免费参赛，线上赛道（On-line Track）的申请截止日期延长至11月15日。 我们将有一个InterSystems的挑战:“用FHIR创新”。InterSystems赛道的奖金设置如下： 🥇第一名: 1500 EUR🥈第二名: 1000 EUR🥉第三名: 500 EUR我们为所有参加InterSystems挑战的人准备了奖品!参考下图，了解我们的挑战细节：）你愿意参加吗？请在下面的投票中告诉我们！ InterSystems挑战赛: 用FHIR创新 无论是IoMT的实现、更容易的患者参与，还是用于分析解决方案的临床数据的可用性，FHIR(医疗数据交换的标准)都可以推动创新。利用FHIR提供的合成数据来改善对患者及其治疗的了解，或者仅仅是在FHIR服务的帮助下，使您的解决方案在实践中立即可用，以收集和提供数据。 为您的解决方案使用一个或多个InterSystems FHIR服务，例如云中的FHIR存储库或HealthShare消息转换服务，并有资格获得InterSystems奖。InterSystems将为参与者提供免费访问服务以及在线和现场技术援助和指导。 在这次编程马拉松中，每个团队将由3位成员组成。如果你没有队伍，组织者会在比赛前安排好队伍。在这里上了解更多关于编程马拉松的信息。 期待与您相聚！如果你计划参加，请在下面告诉我们！

REF: https://docs.intersystems.com/healthconnectlatest/csp/docbook/Doc.View.cls?KEY=GREST REF: https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI.Page.cls?KEY=AFL_rest#AFL_C4838 开发REST服务有两个方式， 一个是生生的写代码， 定义接口的标准，被称为"Manually Coding"。第2个方式是目前越来越流行的"Sepcification-first"，也就是使用描述性的语言定义接口规范，然后通过这个规范生成接口代码。第2种方式更快捷，但这里我还是从第一种介绍起，对理解里面的代码层次更容易一些，而这是调试一个接口必须的。 从代码开发REST服务 不同于HTTP和SOAP, Ensemble里面没有REST的inbound Adaptor，也没有可用的BS组件。在Production里开发一个REST服务的步骤是： 1. 开发一个REST Service, 这个Service是一个CSP Page, 是一个网页服务，和Ensemble没关系。要在Production中使用这个服务，您需要在这个服务里调用一个Production的业务服务BS。 2. 要访问这个REST页面服务， 您需要配置一个Web Application。Web Application的配置项上有一个选项: "REST 分派类"。这样配置好之后， Web Application收到相应的URL后就会调用这个REST页面，页面再去调用Production的BS。 3. 最后，您需要在BS中处理收到的JSON, 发送给其他组件，以传递给接收方系统。 如果您看的了代码包里的EnsLib.REST.Service类， 它继承了%CSP.REST页面， 也继承了BusinessService，非常符合Ensemble的结构设计。But, 别用。在线文档中有专门的说明。 Although InterSystems IRIS defines a class EnsLib.REST.ServiceOpens in a new window, that is a subclass of %CSP.RESTOpens in a new window, we recommend that you not use this class because it provides an incomplete implementation of %CSP.REST Opens in a new window. 让我们开始开发一个简单的REST服务并加入Production: Step 1: 创建以下代码，解释一下： - 继承%CSP.REST，这是个专用于REST的CSP页面 - UrlMap是一个XData, 在COS语言里用于在代码里放置固定的xml数据结构。UrlMap定义从收到的URL到本类里不同的方法之间的映射。 - 方法中入参可以是任意的数据结构和用户定义的类结构，不需要出参。如果直接返回消息给调用者，直接"write"一个流或者字符串 Class SEDemo.IO.REST.SampleService Extends %CSP.REST { XData UrlMap [ XMLNamespace = "http://www.intersystems.com/urlmap" ] { } ClassMethod Test(pInput As %String) As %Status { write "Received: "_pInput，！ Quit 1 } ClassMethod GetPatientById(pID As %String) As %Status { Try{ Set tObj=##class(SEDemo.Common.Patient).%OpenId(pID),tStream = "" d ##class(%ZEN.Auxiliary.jsonProvider).%WriteJSONStreamFromObject(.tStream,tObj) w tStream.Read() } Catch (e) {Set tSC=e.AsStatus()} Quit tSC } } Step 2: 创建Web Application 在管理界面System Administration > Security > Applications > Web Applications，创建一个用于接收此REST服务的Web APPlication, 设置"Dispatch Class"为当前类。 假设创建的Web Applicaiton为"/CSP/myrest",注意： - 选中“Enable Application" - 权限: 分配本命名空间数据库的资源，默认是%DB_%Default。 后面会详细介绍权限和用户管理的细节。 Step 3: 测试你的REST service 你可以选择自己喜欢的测试方式，比如用浏览器，POSTMAN, SoapUI...， 下面是我测试的记录： CNMBPHMA:~ hma$ curl -v http://172.16.58.200:52773/csp/myrest/Test/333 * Trying 172.16.58.200... * TCP_NODELAY set * Connected to 172.16.58.200 (172.16.58.200) port 52773 (#0) > GET /csp/myrest/Test/333 HTTP/1.1 > Host: 172.16.58.200:52773 > User-Agent: curl/7.54.0 > Accept: */* > < HTTP/1.1 200 OK < Date: Wed, 14 Jul 2021 06:47:26 GMT < Server: Apache < CACHE-CONTROL: no-cache < EXPIRES: Thu, 29 Oct 1998 17:04:19 GMT < PRAGMA: no-cache < CONTENT-LENGTH: 15 < Content-Type: text/html; charset=utf-8 < Received: 333 * Connection #0 to host 172.16.58.200 left intact CNMBPHMA:~ hma$ 这里是一个匿名访问，如果需要用户认证，修改一下重发： CNMBPHMA:~ hma$ curl -u 'superuser:SYS' http://172.16.58.200:52773/csp/myrest/Test/333 Received: 333 CNMBPHMA:~ hma$ 注意两点： 1. 到目前为止我们测试的其实是一个HTTP请求和响应，虽然内部用了%CSP.REST的类， 但响应中'Content-Type'还是'text/html' 2. 代码中没有处理出错和查不到结果的情况 3. 到目前为止和Ensemble Production没有任何关系。 Step 4: 将服务加入Ensemble Production 加入Production的意思实际上时调用一个Production的BusinessService。 让我们先创建一个简单的Service. ///不使用Adapter, 收到任何请求，同步发送给目标组件 Class Test.BS.GeneralService Extends Ens.BusinessService { Method OnProcessInput(pInput As %RegisteredObject, Output pOutput As %RegisteredObject) As %Status { set tRequest=##class(Ens.StringRequest).%New() Set tStatus = ..SendRequestSync("Test.BO.dummyOperation", tRequest, .tResponse) set pOutput = tResponse Quit tStatus } } 当需要前面的REST服务来调用这个BusinessService的时候， 需要在method里面加入直接调用的语句，比如上面的GetPatientById() ClassMethod GetPatientById(pID As %String) As %Status { set status = ##class(Ens.Director).CreateBusinessService("Test.BS.GeneralService", .tService) if $$$ISOK(status) { set status = service.OnProcessInput(pID, .tResponse) } w tResponse,! }

查看原文 近日，国家卫健委统计信息中心发布了两则通知—— 2021年10月25日，国家卫健委统计信息中心发布《关于开展国家医疗健康信息互联互通标准化成熟度评测工作的通知》，这意味着新一年的评测工作开始启动。 2021年11月5日，国家卫健委统计信息中心发布了“关于2020年度国家医疗健康信息互联互通标准化成熟度测评结果（第二批）公示的通知”，公布了第二批10个区域和92家医院的测评结果。 这两则通知，再次将“互联互通”带到了医疗IT人的面前。而每每谈到互联互通，就不可避免地要谈到集成平台、信息平台和数据中台等项目建设问题，本文将从供应商选择、技术选型等从八个核心问题，浅谈关于平台和中台的那些事。 一、如何选择供应商？ 如上图所示，如果我们把平台/中台项目的实施方称作解决方案提供商，那么每一家解决方案提供方背后还会有一家产品技术提供方解决方案，因为解决方案提供方往往需要借助成熟的产品来实现信息平台和数据中台项目，以聚焦所服务医院客户的具体需求，并加速实施效率，所以一个平台/中台供应链条相对比较长。也因此，医院/医疗集团需要花费更多的精力在产品和解决方案的组合中进行选型。选型的标准也成为许多信息中心或者CIO们关注的首要问题。 首先要考虑平台/中台解决方案提供方本身的品牌和实力：通常而言，选择全国性的解决方案提供方更安全一些，这类厂商的解决方案相对成熟、成功案例多，技术能力强，实施经验丰富；但是对于一些规模略小的医院而言，可能会顾虑这些厂商的客户太多，对本院的支持力度不够，或者是在该厂商在当地没有分公司，存在技术服务跟不上等问题，也可能会更倾向于初创企业或者本地解决方案提供方来做项目的集成或者实施，这两种选择都没有问题，关键是所选择的合作伙伴要值得信赖。 另外要考虑厂商背后的产品技术提供方：通常产品技术提供方不直接面向最终客户提供实施服务，而是通过本地合作伙伴向最终客户（即医院或者医疗集团）提供服务。但是作为解决方案的基础，该产品或者技术本身的先进性、可靠性以及未来的可扩展性都是需要重点衡量的因素。例如医院建设集成平台或者互联互通平台通常都会本着以评促建以评促用的目的，利用信息平台的建设契机，打通院内的信息和数据流程。此时，产品技术提供方有多少业务建模和流程整合的案例与经验也将在很大程度上影响项目的交付质量。 同样，医院也可以参考该产品技术提供方的行业积累、案例详情、服务承诺以及业界口碑等等。 总结一下，在选择方案时，需要考虑的实际上是产品本身的技术能力和对应的解决方案提供方的服务能力。因此，我们建议大家基于成熟的产品，选择能提供较好技术服务的解决方案提供方。如果产品并不成熟，那么即使解决方案提供方愿意常年提供驻场技术服务，也很难应对故障，也难以制订预案保障平台稳定运行。 二、技术路线的选择 在医疗行业进行业务和数据整合时，用户常常会需要在点对点集成模式、消息路由模式以及SOA架构模式进行技术决策。 事实上，从来就未曾出现过集成模式的最终解决方案。医院和医疗集团用某种特定的集成模式搭建自己的数字化高速公路时需要充分考虑该模式是否适合自己的场景，投入产出比是否符合自己的预期，以及是否能够充分利用该模式的优势。 举例而言，当医院考虑采用SOA架构时，需要考虑到遗留系统是否能够提供服务接口；在当前的业务运行条件下，是否能够承受由于接口的侵入式设计引入的风险，是否可能通过预案规避风险；以及医院是否已经或者将在平台投产前后具有实时数据分析的需求和技术储备。否则就将面临投入无法得到回报的质疑，甚至是规划无法落地的尴尬。 再看一个例子，如果要采用点对点模式集成，那么医院就需要考虑在平台投产可预见的周期（如3～5年）内，是否会面临跨部门跨系统数据利用需求快速增长的前景。如果有，那么，由于缺乏SOA架构能够提供的业务抽象和整合的能力，爆炸性增长的接口数量和数据整合需求会成为信息科难以应对的直接威胁。 正是由于集成模式的高度个性化，我们认为作为基础设施的集成平台类产品必须能够支持所有集成模式。一方面是满足各种不同类型的医院的需要，另一方面，医院也需要认识到，基础设施的建设从来都不是一蹴而就的“一锤子买卖”。您完全可以在集成需求数量较低时选用点对点模式快速投产，在需要进行流程和数据整合时应用SOA架构以获得企业全景视图的整合优势。而一个能够支持所有模式的产品才能赋能于客户，使之具备进行策略选择的优势。 三、开源策略的潜在风险 采用开源组件迅速获得能力，结合DevOps快速迭代开发是应对快速变化的市场环境和需求，进行产品化开发时的优先选择。在进行应用开发时，这样的策略通常有效。 然而优势与代价总是如影随形。借助开源组件的优势是能够快速获得能力，但开源组件的稳定性、可靠性和安全性则是每一个技术决策者都需要考察的关键风险，甚至开源组件许可证的更新都有可能为企业引入巨大的知识产权风险。 例如久负盛名的ElasticSearch，作为一款企业级搜索和分析引擎，它对于文本检索的能力和效率都有保障，被许多产品集成用于检索。但ElasticSearch及其依赖的其他组件已被检测出大量的安全性漏洞，例如可以引入中间人攻击的CVE-2021-22138，可以允许用户查看未授权敏感信息的CVE-2021-22147，以及可以允许用户通过ElasticSearch在服务器上运行任何OS指令的CVE-2014-3120等，风险列表每年都在更新。（风险列表可参见https://www.elastic.co/community/security）同样是ElasticSearch，在将开源授权更新为SSPL之后，如果业务用到了ElasticSearch并打包为可盈利产品，则ElasticSearch公司有权要求用户开放源码并收取费用。 因此，在使用大规模集成开源组件构建的产品时，医院需要评估产品技术提供方是否能够及时更新开源组件以获得安全性更新，并评估产品技术提供方是否能够及时跟踪和处理因授权变化会引入的法律风险。 集成平台、数据中台甚至是数据库这样的基础设施如果构建在大量的开源组件上，频繁的版本变动通常意味着组件集成风险的大幅升高，而跟踪和处理版本变更的技术和法务影响也将成为需要持续投入的持有成本。因此，一体化、完整知识产权的集成平台或数据中台产品在简化技术堆栈的同时也将大幅降低长期持有成本。对于医院用户来说，需要平衡评估一体化商业产品和开源集成产品的购买和持有成本，更需要考察产品技术提供方对开源组件的跟踪、更新和维护能力。 四、关注稳定与可靠性保障 核心业务系统、集成平台和数据中台这一类的关键系统，事关医院业务是否能持续运行，其运行稳定性与可靠性的重要意义不言而喻。基于主备、多活等冗余技术的平台高可用和灾备方案仍是为平台运行保驾护航的关键手段。 在市场上可见到的诸多产品中，有采用原生高可用方案的产品，也有集成第三方或开源技术高可用方案的产品。在这里，各位信息中心负责人或者技术决策者不得不考虑一个问题，即高可用方案的责任归属问题。 因此，即使一些非核心部件采用第三方技术，高可用方案也应采用产品原生技术。即使退一步来说，在没有原生高可用方案的情况下，您的解决方案提供方也应当承担起解决平台可用性和可靠性问题的技术服务角色。试想，当高可用方案失效或处于故障状态时，解决方案提供方采用了非原生高可用方案，届时难道能依赖开源社区的随机问答解决问题？ 五、跨越技术门槛 医疗数字化进程与人工智能等目前的热点技术有很大不同，即必须基于当前业务。但由于医疗业务本身面临与新技术的融合，因此数字化进程也必须具备足够的灵活性，能够迅速应对业务过程的演化。而医疗业务流程或数据流程的演化，是需要业务专家、开发工程师、运维保障团队协作共同完成的，每一种角色都需要在平台上工作。因此，纯粹面向开发工程师的技术平台将无法有效应对业务流程本身的快速迭代。我们认为，一个成熟的集成平台/数据中台，需要为团队中不同角色的成员提供适合他们的开发/维护/测试工具，使各成员能以较低的成本各施所长。这些工具至少包括： · 图形化的流程、数据转换和业务规则建模工具，使得业务专家即使不了解业务组件的技术实现，也能利用平台上的组件搭建出适合医院的业务/数据流 · 专业的IDE和管理工具，供研发工程师扩展业务组件和对现有组件进行跟踪和组件级调优 · 监控和管理工具，供运维工程师监控平台运行的健康状况和性能，必要时对平台运行参数进行调优 六、集群的选择 我们理解一些工程师非常关心产品是否支持负载均衡。需要注意的是，对于现代的集成平台和数据中台而言，它们本身应当是由一系列的集群共同构成的分布式系统。 比如院内集成平台拥有基于Web的操作管理页面，运行API实现或数据流程的容器，有消息引擎，有数据库，因此，可以构成一个典型的由Web程序，API/应用服务器，消息引擎和数据库分层构建的分布式系统，而其中的每一层，都可以根据高可用与负载需求以不同目的的集群形态搭建出来。 以集成平台产品为例，通常，集成平台的Web管理程序由于并发操作的人很少，不需要单独进行集群化；而API/应用服务器层默认会采用高可用集群，对于业务量极大的用户，则可以采用负载均衡+高可用集群；数据库层同样如此，必要时还可以考虑部署读写分离+负载均衡+高可用集群；消息引擎则比较特别，如果不需要保障消息的先进先出特性，可以部署高可用和负载均衡集群，而对于需要保障消息处理时序的场景，则通常不能依赖负载均衡集群，或即使部署了负载均衡集群，也需要控制消息分规则，由单一实例处理这样的消息。 但是否采用及采用何种集群架构，则完全应当基于业务的实际需要和产品能力。举例而言，InterSystems产品可以支持负载均衡+高可用集群，还可以部署为读写分离+负载均衡+高可用集群，但通常我们并不会作为默认配置推荐给集成平台用户。原因在于，我们的产品在单台服务器上经性能测试可以达到20亿消息/天的处理效率。而根据我们对国内数百家三家医院的实际调查，即使在国内顶尖的三甲医院中，也未发现超过2千万消息/天的性能需求。因此，对于单体医院，高可用集群已足够使用。基于奥卡姆剃刀原理和成本控制的基本需求，负载均衡集群并无必要，反而会由于加大了架构的复杂性使持有、维护成本都大幅提升。而对于医疗集团客户，由于需要集成数十家三甲与二级医院，同时还需要控制单个服务器的成本，因此我们的一部分医疗集团客户部署了负载均衡+高可用集群并可进行弹性横向扩展。 当然，不同的产品有不同的性能指标，如果产品的本身性能表现无法支撑医院业务量，那么部署为负载均衡集群支撑医院的实际需求还是非常必要的。 七、技术服务保障 相比开源产品，基于商业产品搭建平台/中台解决方案最显著的附加价值主要来源于技术服务。无论是最终用户还是解决方案提供方，都能受益于产品提供方的技术服务。技术服务也是项目能否成功上线、持续稳定运行或者二次开发的重要保障，对于技术服务，需要考虑产品技术提供方是否能够提供下面的三种或者以上的方式： · 故障处理和技术支持：对于产品应用、二次开发的疑问，是否可获得技术支持资源以解决疑问？对于在产品运行过程中可能遭遇的软硬件故障，尤其是系统崩溃、宕机等高等级事件，是否能够获得直接的技术支持解决、定位和调查问题？ · 产品培训：是否具备成体系的产品应用、二次开发和维护培训体系 · 在线课程 · 产品文档库 · 开发者社区：非工程师的客户往往不重视开发者社区的力量。实际上，作为可供全球开发者沟通的场所，在开发者社区往往能找到常见问题的解决方案，具体问题和场景的最佳实践，前瞻性技术研究等非常有价值的资料。 对于医院或是医疗集团客户来说，如果需要掌握信息平台或数据中台，能够达到自主维护、持续演进的目标，那么，无论是通过解决方案提供方还是通过产品技术提供方，都需要获得上述的多种技术服务支持。 八、选型中的常见问题 对于采用商业产品这一策略本身，需要经过大量的选型工作。产品技术提供方和解决方案提供商都会积极宣传自己的产品，而医院则需要对产品的特性，服务体系，性能表现，案例的代表性，综合实施效果等做出评估，方可得出对自己有利的评估结果。在这个过程中，客户往往还是需要综合运用多种手段，包括自行评估、走访典型案例和开展验证测试等手段，避免常见的一些问题，例如： · 技术的可执行性评估不足 例如对于仅支持消息引擎的集成平台，往往需要按照一种特定的消息类型进行通信，使系统间交互具备统一协议，并且系统都需要改造以接入消息引擎。这样的规划不能说不好，但医院的遗留系统能不能都配合平台进行改造或医院有没有足够的预算支撑改造项目落地，以及业务系统现场改造的风险，都会影响实施效果。因此需要切实评估和核实。 · 产品特性不能达到预期 例如对于具有ETL能力的产品，需要评估其对于大容量数据（例如初始化数据加载过程）进行批量采集、转换和落盘的处理效率，以便与借助简单的SQL JDBC连接逐条抽数和转换的SQL适配器相区别。由于两种模式在处理速度上通常有数量级的差别，如果使用SQL适配器模式，在大批量对数据进行ETL操作时将不可避免地遭遇瓶颈。 · 产品对主流技术的覆盖不全面 在现在的技术条件下，即使对同一类型的接口，也往往有多种技术选择。如产品不能提供对这些技术的覆盖，则用户需要投入额外的成本和风险完成接入。例如对常见的负载均衡方案而言，通常对于推模式接口（由外部调用触发的接口），例如SOAP WebService或者REST API，往往都能提供负载均衡；而对于拉模式接口（由产品自身自动触发），例如SQL扫描或一些CDC功能接口，则无法直接受益于负载均衡技术。假如实际业务中有大量需要通过SQL获取数据的接口，则负载均衡集群并没有多少意义。 再如SQL接口可以基于JDBC或ODBC连接，如果产品只能支持其中一种连接，那么对于遗留系统的接入能力将大打折扣。 · 缺乏技术验证过程和约束 对于架构和技术的落地，通常需要验证过程，用户才可能获得预期的效果。例如市场上存在对架构模式进行过度简化与概念偷换的现象。例如将SOA架构等价于ESB、将ESB的概念偷换为接口引擎、或将集成平台概念偷换为消息引擎，而在实施时更进一步地简化为接口的注册和连接，实际上变成了点对点模式。由于集成架构将影响未来3～5年的医院数字化转型过程中的难度和成本，点对点模式的后续实施成本将随接口的数量增加指数上升，导致后期的实施成本居高不下。 当然，充分了解到以上关于供应商选择与技术选型的8个问题，才是真正的互联互通建设的起点，更重要的是，医院信息负责人还需要真正读懂评测要求，并了解本院建设互联互通的整体目标以及医院管理层、临床业务部门等相关部门的不同述求，把这些目标与述求一一映射到平台/中台解决方案中，才是成功通关的秘籍。

亲爱的开发者们，我们很高兴地跟大家分享一个好消息！ 我们的社区全球注册会员突破10000名！中国开发者社区不到一年时间突破270人！增速全球第一！这是一个了不起的成就！感谢大家的支持🎊 在InterSystems，我们相信社区的力量。所以我们非常感谢你们在过去六年里所做的贡献，并期待未来的道路! 我们希望与大家分享一些有趣的数据，全球社区： 2015年12月上线 总计发布 - 8,600篇 共计提问 - 5,500次 总计浏览 - 430万 中文社区 2021年1月上线 总计发布 - 748篇 共计提问 - 100+次 总计浏览 - 21000+ 不到一年的时间，能够有如此大的成绩，非常感谢所有人的参与和贡献，感谢你们的热情和分享！我们非常感谢大家的帮助，使我们的社区成为InterSystems乃至整个医疗信息化开发人员更好的地方。大家真的很棒! 请随时分享您成为InterSystems开发人员全球和中国大家庭一员的感受! 再次感谢大家，共同成就了这个可爱的大社区！ 敬上，开发者社区团队 ❤️

Gartner Peer Insight 一直持续公开对各类第三方软硬件的对比，是IT行业的“大众点评“。综合转载如下，仅供参考。 原文链接：https://www.gartner.com/reviews/market/cloud-database-management-systems/compare/product/cloudera-enterprise-data-hub-vs-intersystems-cache-vs-microsoft-sql-server-vs-oracle-database Gartner Peer Insights 是Gartner 提供的由专业最终用户用来对企业级技术解决方案进行打分和评估供企业使用的平台。Gartner 会将用户意见和他们的专业意见综合起来形成魔力象限。 Cloudera EDH（Hadoop企业版） MS SQL Server Oracle ISC Caché 总分--Overall Ratings 4.4 4.5 4.4 4.6 分项评分--Overall Capacity整体技术能力 4.5 4.6 4.6 4.6 分项评分--评估与合同（商务）Evaluation & Contracting 4.2 4.3 4.1 4.5 分项评分--集成与部署Integration & Deployment 4.2 4.5 4.3 4.6 分项评分--服务与支持Service&Support 4.3 4.4 4.2 4.7

# 第七十三章 SQL命令 SET OPTION 设置执行选项。 # 大纲 ```java SET OPTION option_keyword = value ``` # 描述 `SET OPTION`语句用于设置执行选项，如编译模式、`SQL`配置设置和控制日期、时间和数字约定的区域设置。 每个`set option`语句只能设置一个关键字选项。 `SET OPTION`支持以下选项: - `AUTO_PARALLEL_THRESHOLD - `COMPILEMODE` - `DEFAULT_SCHEMA`` - `EXACT_DISTINCT` - `LOCK_ESCALATION_THRESHOLD` - `LOCK_TIMEOUT` - `PKEY_IS_IDKEY` - `SUPPORT_DELIMITED_IDENTIFIERS` - `Locale Options (date, time, and numeric conventions)` `SET OPTION`可以在动态SQL(包括`SQL Shell`)和嵌入式SQL中使用。 为了`SQL`兼容性，IRIS会解析其他`SET OPTION`参数(这里没有文档)，但不执行任何操作。 因为`SET OPTION`的准备和执行速度很快，而且通常只运行一次，所以`IRIS`不会在`ODBC`、`JDBC`或动态SQL中为`SET OPTION`创建缓存查询。 IRIS支持下列选项: ## `AUTO_PARALLEL_THRESHOLD` `AUTO_PARALLEL_THRESHOLD`选项被设置为一个整数`n`，用于确定当启用自动并行处理时是否应该对查询应用并行处理。 由于与并行处理相关的性能成本，因此需要为并行处理的优势确定一个阈值。 `n`越高，SQL查询使用并行处理执行的可能性就越低。 默认为`3200`。 这是一个系统范围的设置。 值n大致对应于所访问的映射中发生并行处理所需的最小元组数量。 当自动并行被禁用时，`AUTO_PARALLEL_THRESHOLD`选项没有作用。 也可以使用`$SYSTEM.SQL.Util.SetOption()`方法`AutoParallelThreshold`选项设置该选项。 ## COMPILEMODE `COMPILEMODE`选项将当前名称空间的编译模式设置为`DEFERRED`、`IMMEDIATE`、`INSTALL`或`NOCHECK`。 默认为`IMMEDIATE`。 从`DEFERRED`编译模式更改为`IMMEDIATE`编译模式会导致`DEFERRED compile Queue`中的任何类立即被编译。 如果所有类编译都成功，IRIS将`SQLCODE`设置为0。 如果有任何错误，`SQLCODE`设置为`-400`。 类编译错误记录在`^mtemp2 ("Deferred Compile Mode"，"Error")`中。 如果将`SQLCODE`设置为`-400`，则应该查看此全局结构以获得更精确的错误消息。 `INSTALL`编译模式类似于`DEFERRED`编译模式，但它应该只用于表中没有数据的`DDL`安装。 `NOCHECK`编译模式与`IMMEDIATE`编译模式类似，只是在编译时忽略了以下约束:如果一个表被删除， IRIS不检查引用被删除表的其他表中的外键约束。 如果添加了外键约束， IRIS不会检查现有数据以确保它对这个外键有效。 如果添加了`NOT NULL`约束， IRIS不会检查现有数据是否为`NULL`，也不会指定字段的默认值。 如果删除了`UNIQUE`或`Primary Key`约束 IRIS不会检查该表或其他表中的外键是否引用了被删除的键。 也可以使用`$SYSTEM.SQL.Util.SetOption()`方法`CompileMode`选项设置该选项。 ## DEFAULT_SCHEMA `DEFAULT_SCHEMA`选项为所有名称空间设置系统范围的默认模式。 在显式更改之前，此默认值将保持有效。 默认模式名用于为所有未限定的表、视图或存储过程名提供模式名。 可以指定一个文字模式名或指定`_CURRENT_USER`。 如果指定`_CURRENT_USER`作为默认模式名， IRIS会将当前登录进程的用户名作为默认模式名。 ## EXACT_DISTINCT `EXACT_DISTINCT`布尔值选项指定是否在系统范围内使用`DISTINCT`处理`(TRUE)`或`Fast DISTINCT`处理`(FALSE)`。 系统范围的默认值是使用`Fast Distinct`处理。 当`EXACT_DISTINCT=TRUE`时，`GROUP BY`和`DISTINCT`查询生成原始值。 当`EXACT_DISTINCT=FALSE`时，启用快速`Distinct`，通过更好地使用索引(如果有索引)，使涉及`Distinct`或`GROUP BY`子句的SQL查询更有效地运行。 但是，这些查询返回的值以与存储在索引中的相同的方式进行排序。 这意味着此类查询的结果可能都是大写的。 这可能对区分大小写的应用程序有影响。 这个选项也可以使用`$SYSTEM.SQL.Util.SetOption()`方法`FastDistinct boolean`选项来设置。 ## `LOCK_ESCALATION_THRESHOLD` `LOCK_ESCALATION_THRESHOLD`选项被设置为一个整数`n`，用于确定何时将行锁定升级为表锁定。 默认值是`1000`。 值`n`是单个事务中单个表的插入、更新或删除次数，当到达时将触发表级锁。 这是针对所有名称空间的系统范围设置。 例如，如果锁阈值为`1000`，并且进程启动一个事务，然后插入`2000`行，那么在插入第`1001`行之后，进程将尝试获取表级锁，而不是继续锁定各个行。 这有助于防止锁表变得太满。 这个选项也可以使用`$SYSTEM.SQL.Util.SetOption()`方法`LockThreshold`选项来设置。 ## LOCK_TIMEOUT `LOCK_TIMEOUT`数值选项允许为当前进程设置默认的锁定超时。 `LOCK_TIMEOUT`值是SQL执行期间试图建立锁时等待的秒数。 当锁定冲突阻止当前进程对`lock`、`INSERT`、`UPDATE`、`DELETE`或`SELECT`操作立即锁定一条记录、表或其他实体时，使用此锁定超时。 `SQL`继续尝试建立锁，直到超时超时，这时将生成`SQLCODE -110`或`-114`错误。 可用的值是正整数和零。 超时设置是每个进程的。 可以使用`$SYSTEM.SQL.Util.GetOption(“ProcessLockTimeout”)`方法确定当前进程的锁定超时设置。 如果没有为当前进程设置锁定超时，则默认为当前系统范围的锁定超时设置。 如果您的`ODBC`连接断开并重新连接，重新连接的进程将使用当前系统范围的锁定超时设置。 系统范围的锁定超时默认为10秒。 ## PKEY_IS_IDKEY `PKEY_IS_IDKEY boolean`选项指定主键是否也是系统范围内的ID键。 取值为`TRUE`、`FALSE`。 如果为`TRUE`，且该字段不包含数据，则将主键创建为`ID`键。 也就是说，表的主键也成为了类定义中的`IDKey`索引。 如果字段不包含数据，则没有定义`IDKey`索引。 如果将主键定义为`IDKey`索引，则数据访问将更加有效，但主键值一旦设置，就永远不能修改。 一旦设置，就不能更改分配给主键的值，也不能将其他键指定为主键。 使用此选项还将更改主键排序规则的默认值; 主键字符串值默认为`EXACT`排序规则。 如果为`FALSE`，则主键和`ID`键被定义为独立的，效率较低。 但是，主键值是可修改的，主键字符串值默认为当前排序规则类型`default`，默认为`SQLUPPER`。 要设置`PKEY_IS_IDKEY`选项，必须具有`%Admin_Manage:USE`权限。 否则，将收到一个`SQLCODE -99`错误(特权违反)。 一旦设置，该选项将在系统范围内对所有进程生效。 该选项的系统范围默认值也可以通过以下方式设置: - `$SYSTEM.SQL.Util.SetOption()`方法配置选项`DDLPKeyNotIDKey`。 要确定当前设置，调用`$SYSTEM.SQL.CurrentSettings()`，它显示通过DDL创建的是主键而不是ID键; 默认值是1。 - 管理门户配置设置。 选择系统管理，配置，SQL和对象设置，SQL。 查看或修改通过DDL创建的表的“将主键定义为ID键”的当前设置。 `PKEY_IS_IDKEY`设置保持有效，直到通过另一个SET OPTION `PKEY_IS_IDKEY`重置或直到 IRIS `Configuration`被重新激活，将该参数重置为IRIS System `Configuration`设置。 ## SUPPORT_DELIMITED_IDENTIFIERS 默认情况下，系统范围内支持分隔标识符。 `SUPPORT_DELIMITED_IDENTIFIERS`布尔选项允许您更改系统范围内对分隔标识符的支持。 取值为`TRUE`、`FALSE`。 如果为`TRUE`，用双引号分隔的字符串被认为是SQL语句中的标识符。 如果为`FALSE`，由双引号分隔的字符串被认为是SQL语句中的字符串字面值。 要设置`SUPPORT_DELIMITED_IDENTIFIERS`选项，必须具有`%Admin_Manage:USE`权限。 否则，将收到一个`SQLCODE -99`错误(特权违反)。 一旦设置，该选项将在系统范围内对所有进程生效。 `SUPPORT_DELIMITED_IDENTIFIERS`设置将保持有效，直到通过另一个设置选项`SUPPORT_DELIMITED_IDENTIFIERS`进行重置，或者直到由`$SYSTEM.SQL.Util.SetOption()方法delimitedifiers`选项在系统范围内进行更改。 ## Locale Options 区域设置选项是关键字选项，用于为当前进程的日期、时间和数字约定设置IRIS区域设置。 可选关键字有`AM、DATE_FORMAT、DATE_MAXIMUM、DATE_MINIMUM、DATE_SEPARATOR、DECIMAL_SEPARATOR、MIDNIGHT、MINUS_SIGN、MONTH_ABBR、MONTH_NAME、NOON、NUMERIC_GROUP_SEPARATOR、NUMERIC_GROUP_SIZE、PM、PLUS_SIGN、TIME_FORMAT、TIME_PRECISION、TIME_SEPARATOR、WEEKDAY_ABBR、WEEKDAY_NAME、YEAR_OPTION`。 所有这些选项都可以设置为文字，并且都采用默认值(美式英语惯例)。 `TIME_PRECISION`选项是可配置的(参见下面)。 如果将这些选项中的任何一个设置为无效值，InterSystems IRIS将发出`SQLCODE -129`错误(`set OPTION`区域设置属性的非法值)。 Date/Time Option Keyword| Description ---|--- `AM` |`String`. 默认 `'AM'` `DATE_FORMAT` |`Integer`. 默认值为`1`。取值范围为`0 ~ 15`。 `DATE_MAXIMUM`| `Integer`. 默认为`2980013(12/31/9999)`。可以设置为更早的日期，但不能设置为更晚的日期。 `DATE_MINIMUM`| `Positive Integer`. 默认为0`(12/31/1840)`。可以设置为较晚的日期，但不能设置为较早的日期。 `DATE_SEPARATOR`| Character. Default is '/' `DECIMAL_SEPARATOR`| Character. Default is '.' `MIDNIGHT`| String. Default is 'MIDNIGHT' `MINUS_SIGN`| Character. Default is '-' `MONTH_ABBR`| String. Default is ' Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec'. (注意，该字符串以空格字符开始，这是默认分隔符.) `MONTH_NAME`| String. Default is ' January February March April May June ... November December'. 注意，该字符串以空格字符开始，这是默认分隔符.) `NOON`| String. Default is 'NOON' `NUMERIC_GROUP_SEPARATOR`| Character. Default is ',' `NUMERIC_GROUP_SIZE` |Integer. Default is 3.PM String. Default is 'PM' `PLUS_SIGN`| Character. Default is '+' `TIME_FORMAT`| Integer. Default is 1. 取值范围为1 ~ 4。 `TIME_PRECISION`| Integer from 0 through 9 (inclusive). Default is 0. 小数秒的位数。 `TIME_SEPARATOR`| Character. Default is ':' `WEEKDAY_ABBR`| String. Default is ' Sun Mon Tue Wed Thu Fri Sat'. (注意，该字符串以空格字符开始，这是默认分隔符.) `WEEKDAY_NAME`| String. Default is ' Sunday Monday Tuesday Wednesday Thursday Friday Saturday'. (注意，该字符串以空格字符开始，这是默认分隔符.) `YEAR_OPTION`| Integer. Default is 0. 取值范围为0 ~ 6。有关表示2位数和4位数年份的这些方法的解释，见ObjectScript $ZDATE函数。 要在系统范围内配置`TIME_PRECISION`，请进入管理门户，选择“系统管理”、“配置”、“SQL”和“对象设置”、“SQL”。 查看和编辑`GETDATE()`、`CURRENT_TIME`和`CURRENT_TIMESTAMP`的默认时间精度的当前设置。 它指定小数秒的精确位数。 默认值是`0`。 允许的值的范围是`0`到`9`位精度。 小数秒中有意义的数字的实际数目与平台有关。