こんにちは、皆さま。
業務でIRISを用いて開発を行っている者です。

IRISにSQLを投げるときの動作について教えてください。

■適当なテーブルを作成
CREATE TABLE Mst.Test (id int, name varchar(10))

■データをINSERT
INSERT INTO Mst.Test VALUES (2, 'bbb ')
※文字列の末尾にスペースを追加。

■SELECT
SELECT * FROM Mst.Test WHERE name = 'bbb'
※whereの条件には末尾のスペースを入れない。

⇒上記の結果、INSERTされたデータがヒットしている。

[疑問点]
SQLの実行において、=を使って完全一致検索をしているつもりなのですが、
末尾のスペースはその条件を無視してヒットしてしまうものなのでしょうか？

何か情報をお持ちの方がいらっしゃれば、フォローいただけますと幸いです。

こんにちは、皆さま。
業務でIRISを用いて開発を行っている者です。

IRISに直接Insert文を発行する時と、JDBCを経由してInsert文を発行する時とで、
挙動差異があるように見受けれれまいたので、何かご存知な方がいらっしゃれば教えてください。

次の様なテーブルがあります。

それに対してDBeaverとIRIS管理ポータルからInsertを実行します。

★DBeaver

★IRIS管理ポータル

皆さんこんにちは！

VSCode の SQLTools エクステンションを使うと、VSCode から SQLTools に対応しているデータベースへ接続／クエリ実行が行えるようです。

1 つの IDE で 各種言語を操作でき、さらにクエリも発行できるなんて VSCode って便利ですね！👏👏

実は、まだプレビュー機能ではありますが、InterSystem IRIS も接続できます！🎊🎊

正式リリース前なのですが、どんな感じでご利用いただけるかをご紹介したいと思います。

解説ビデオ（4分ちょっと）もあります。ぜひご参照ください。

これはInterSystems FAQ サイトの記事です。

LAST_IDENTITY()　SQL関数を使用すると取得できます。
※ この関数は、埋め込み SQL または ODBC 利用時に使用できます。ダイナミック SQL、SQL シェル、または管理ポータルの SQL インタフェースによる値には設定されません。

簡単な埋め込み SQL での例をご紹介します。

これは InterSystems FAQ サイトの記事です。

新しいインデックスを定義した後、インデックスの再構築が完了する前にクエリを実行するとデータが存在しているにもかかわらず「検索結果0件」や検索結果数が徐々に増えるような状況が発生します。

インデックスを永続クラス定義（またはテーブル定義）に追加しコンパイルすることで今まで使用していたクエリ実行経路が削除され、再度同じクエリを実行するタイミングで新しいインデックス定義を含めた実行経路が作成されるためです。（この時にインデックス再構築が完了していないとインデックスデータが存在しない、または不完全であるため0件や徐々に検索結果数が増えるような状況を起こします。）

これを起こさなために、新しいインデックスの再構築が終了するまでクエリオプティマイザにインデックスを使用させないように指定する方法が用意されています。

※ 2024/8/2： 2024.1以降から利用できる方法を追加しました。

InterSystems 2022.2 では、IRIS SQL テーブルを永続化する新しいオプションとして、分析クエリを桁違いに向上させられるカラムナーストレージを導入しました。 2022.2 と 2022.3 ではこの機能は実験的としてマークされていますが、次の 2023.1 リリースでは、完全にサポートされた本番機能に「卒業」する予定です。

製品ドキュメントとこの紹介動画では、IRIS では現在でもデフォルトであり、全顧客ベースで使用されている行ストレージと、このカラムナーストレージの違いがすでに説明されており、ユースケースに適切なストレージレイアウトの選択方法に関する大まかなガイダンスが提供されています。 この記事では、このテーマについて詳しく説明し、業界で実践されているモデリング原則、内部テスト、および早期アクセスプログラム参加者からのフィードバックに基づく推奨事項をいくつか紹介します。

ローコードへの挑戦

こんな状況を思い浮かべてください。「ウィジェットダイレクト」というウィジェットとウィジェットアクセサリーを販売する一流のネットショップで楽しく勤務しています。先日、上司から一部の顧客がウィジェット商品にあまり満足していないという残念な話を聞き、苦情を追跡するヘルプデスクアプリケーションが必要となりました。さらに面白いことに、上司はコードのフットプリントを最小限に抑えることを希望しており、InterSystems IRIS を使って 150 行未満のコードでアプリケーションを提供するという課題をあなたに与えました。これは実際に可能なのでしょうか？

免責事項: この記事は、非常に基本的なアプリケーションの構築を記すものであり、簡潔さを維持するために、セキュリティやエラー処理などの重要な部分は省略されています。このアプリケーションは参考としてのみ使用し、本番アプリケーションには使用しないようにしてください。この記事ではデータプラットフォームとして IRIS 2023.1 を使用していますが、それ以前のバージョンでは記載されているすべての機能が提供されているとは限りません。

本稿について

本稿では、InterSystems IRISを使用してSQLベースのベンチマークを行う際に、実施していただきたい項目をご紹介します。
Linuxを念頭においていますが、Windowsでも考慮すべき点は同じです。

メモリ自動設定をやめる

パフォーマンスに直結する、データベースバッファサイズの自動設定はデフォルトで有効になっています。自動設定は、実メモリの搭載量にかかわらず、データベースバッファを最大で1GBしか確保しません。

更新: 2020年11月20日 バージョン2020.3から、確保を試みるデータベースバッファが実メモリの25%に変更されました。

搭載実メモリ64GB未満の場合は実メモリの50%程度、搭載実メモリ64GB以上の場合は実メモリの70%を目途に、明示的に設定を行ってください。

これは InterSystems FAQ サイトの記事です。

永続クラス（＝テーブル）定義に提供される %BuildIndices() メソッドの引数に、インデックスを再構築したい ID の開始値と終了値を指定することにより、その範囲内のインデックスのみが再構築できます。

例えば、Sample.Person クラスにある NameIDX インデックスと ZipCode インデックスを ID=10～20 のみ再構築する場合は、以下のように実行します（ID の範囲は、第5引数、第6引数に指定してます）。

InterSystems IRIS Cloud SQL は、何千ものエンタープライズのお客様に利用いただいている InterSystems IRIS の優れたリレーショナルデータベース機能を実感いただける、幅広いアプリケーション開発者やデータ専門家のみなさまのためのフルマネージドサービスです。また InterSystems IRIS Cloud IntegratedML は、この DBaaS (Database-as-a-Service) のオプションであり、SQL ネイティブを通じて強力な自動機械学習機能を簡単にご利用いただけるサービスを提供します。シンプルな一連の SQL コマンドは簡単にアプリケーションコードに組み込むことができるため、データに近いところで動作する ML モデルにより、お客様のアプリケーションを拡張することができます。

本日は、これら2製品に関する 開発者アクセスプログラム を発表いたします。アプリケーション開発者は本サービスにみなさまご自身で登録いただくことで、デプロイメントの作成、構成可能なアプリケーションのビルド、そして本サービスによってプロビジョン、構成、システム管理が実行されるスマートデータべースを体験いただけます。

次回の Python コンテストでは、Python を使用して IRIS をデータベースとして使用する簡単な REST アプリケーションを作成する方法についての小さなデモを作成しようと思います。 以下のツールを使用します。

• FastAPI フレームワーク: 高パフォーマンス、学習しやすい、高速コーディング、プロダクション対応
• SQLAlchemy: Python SQL ツールキットで、アプリケーション開発者が SQL の全性能と柔軟性を活用できるオブジェクトリレーションマッパーです。
• Alembic: Python 用の SQLAlchemy データベースツールキットと使用する軽量のデータベース移行ツール。
• Uvicorn: Python の ASGI ウェブサーバー実装。

これはInterSystems FAQ サイトの記事です。

%SYSTEM.SQL クラスの Purge* メソッドを使用して削除することが可能です。

※各メソッドの詳細は、以下ドキュメントをご参照ください。

%SYSTEM.SQLクラスについて【IRIS】

%SYSTEM.SQLクラスについて

より産業向けのグローバルストレージスキーム

この連載の第1回では、リレーショナルデータベースにおけるEAV（Entity-Attribute-Value）モデルを取り上げ、テーブルにエンティティ、属性、および値を保存することのメリットとデメリットについて確認しました。 このアプローチには柔軟性という点でメリットがあるにもかかわらず、特にデータの論理構造と物理ストレージの基本的な不一致などによりさまざまな問題が引き起こされるという深刻なデメリットがあります。

こういった問題を解決するために、階層情報の保存向けに最適化されたグローバル変数を、EAVアプローチが通常処理するタスクに使用できるかどうかを確認することにしました。

パート1では、オンラインストア向けのカタログをテーブルを使って作成し、その後で1つのグローバル変数のみで作成しました。 それでは、複数のグローバル変数で同じ構造を実装してみることにしましょう。