> 65

俺は製品の批判はするけど、RDB理論とSQL自体は批判しない。
普通のファイルアクセスだって、大量データの全なめ用途
だけなら最速の場合もある。
適用ゾーンと使い方を間違えずに、問題にフィットする
データ操作を行えばいいだけ。
中傷なんぞ勝手に言わせとけ。どうせプログラムしか
組んだことなくて、要件定義から運用保守までなぞ
したこともないし苦労したこともだろうから。

> 67、67

建設的な質問サンクス
上の例だと、";" を区切りにしたPIECE構造はあくまでデータで、
このデータを検索するキーとしては("db",1108952588,1)
＝板、スレ、投稿番号の３つでよいという構成ならOKと
いうことになるね。

キミが書いた例なら、そのあとの要素が規則的に続き、本文は
データとして扱うなら

^DAT("db")="データベース板"
^DAT("db",1108952588")="【M言語】キャシエ・CACHE【MUMPS】"
^DAT("db",1108952588,1,2,21,11,23,8)="医療、金融、物流、製造でいまだに活躍！<br>古参も新参者も、さー語ってくらっしゃい。"
^DAT("db",1108952588,2,2,21,11,24,46)="データベース新たな選択肢 〜 略 〜 "
^DAT("db",1108952588,3,2,21,11,24,46)="お仕事ですか？ 〜 略 〜 "

の方が効率的。
要素確保の分効率が悪くなると思いがちだけど、
同じ要素位置の値は、そのままストレージに格納されるのでは
なくて、その前の同じ要素構成の部分までは同じ、という
情報だけを持つので、このパターンだと、板とスレの要素値は
省略されてストレージに格納される。
この並びによって、実際の格納サイズも削減できるし、
RDBなら検索キーのカーディナリティ(多重度）が低い
場合でも、フルスキャンする量が減るので効果大

ソートは不要、ストアした時点で自動的に要素順に格納してくれる。
削除・更新したときのストレージの断片化も心配無用。
ストレージエンジンが自動デフラグしてくれる。
デフラグ負荷も実運用上ほとんど気にならない。

あくまでここまでは標準MUMPSのグローバルアクセス。
Cache’の拡張Mはまだいろいろある。スキーマも持たせたい
場合は、クラス定義をすることになる、ストレージには最終的に
クラスに対応するグローバルにストアされるが、その構成が
異なる。その辺はマニュアルを見るべし。

https://www.intersystems.co.jp/support/csp/main.html
https://www.intersystems.co.jp/support/csp/ggbl/ggbl.html
https://www.intersystems.co.jp/support/csp/ggbl/ggbl_sqlobj.html