Database」タグアーカイブ

4Dアプリ開発ガイドをv18対応に改訂、キーフィールドが必須に

4Dアプリ開発ガイドを改訂。v15対応(以下、旧ガイドと呼ぶ)をv18対応(以下、新ガイドと呼ぶ)にした。

4Dの仕様変更に従って一部内容を変えた。当時の4DはSQLと同様に「レコードのキーフィールドはなくてもいい」という仕様だった。Display selectionとModify recordでレコードを操作する場合はそれでよかった。しかし旧ガイドは、ハンズオンの目標としてリストボックスをダブルクリックするアプリを作る都合上「キーフィールドは必須」だ。そのためキーフィールドに格納するユニークなレコードIDを生成するためにシリアル番号テーブルを実装していた。SQLではよくやる手だ。

v18ではキーとなるIDフィールドの実装が必須になった。SQLとは異なる仕様だ。新ガイドではSQL的な実装をやめて4Dの機能を使うようにした。IDフィールドには、重複不可の属性をつけて自動入力属性でユニークIDを入れるという実装だ。これによりシリアル番号テーブルは不要になった。旧ガイドで実装していたのはシリアル番号テーブルとログインユーザテーブルの2つ。シリアル番号テーブルがなくなると、実装するのは「ログインユーザ」テーブル1つだけになる。これではガイドとして内容が薄いということで、新ガイドではログイン履歴を記録することにした。履歴の保存先としてアクションテーブルを実装。ログインユーザを表示すると、ユーザ名やパスワードとログイン履歴一覧を表示するアプリとした。

この結果として、新ガイドでは「ログインユーザ1件についてログイン履歴がN件あるリレーショナルデータベース」を実装することになり、1対Nのリレーショナル構造を実装するためのテーブル定義と画面表示について説明することになった。

ハンズオンのステップの多くは旧ガイドから流用した。誤字脱字は訂正し、デスマス調をデアル調に変えた。よく使うキーボードショートカットキーを示したり、コラム欄を追加して、なぜそのような実装にしているかの説明を増やした。附録のデバッグの章には、4Dのデバッガでよく使う機能についての説明を追加した。

4D 自力distinct

4D 自力distinctを作ってみたので紹介する。このコマンドはv17、v18で動作確認済み。

4DのDistinctコマンド

4DにはDistinctというコマンドがある。テーブルをクエリーしてセレクションができて、そのテーブルのフィールドの重複を排除したユニークな値の配列を取得できる便利なコマンドだ。

Distinctにはフィールドを一つしか与えることができない。たとえばユニークなコードの配列をください、そのコードに対応した名前の配列(ユニークでないかもしれない)を同時にください、というときは不便。Distinctを実行してもセレクションができるわけではないので、別のフィールドの値を取得するには、得られた配列のユニーク値をもとにしてクエリーし直さなくてはならない。

自力ディスティンクト

そこで「自力ディスティンクト」を作ってみた。ディスティンクトで得られるユニークなフィールドの配列を、データベース側のセットに実現することでセレクションを作る。このモジュールを呼び出すとIDがユニークな配列が返されると同時に、その配列の元になるカレントセレクションが用意される。呼び出し元ではユニークフィールド以外のフィールドの値はSelection to arrayで簡単に持ってこれる。セットを使っているので高速に動く。

このモジュールの特徴は、テーブル名を決め打ちしていることと、ユニークフィールドを整数に限定していること。別のテーブル用とかユニークフィールドが文字列以外の場合はこのモジュールを複製・修正して使う。MVCのモデルメソッドという位置付けである。

//JO_Distinct_byAC_ID
//20200821 wat
//自力Distinct //ジャーナルの勘定科目とカテゴリー
//セレクションは上位で作成しておく
//distinctキーとなるフィールドのポインタは整数、整数の結果配列を返す。

C_POINTER($1;$keyFldPtr)
$keyFldPtr:=$1
C_POINTER($2;$outIDAryPtr)
$outIDAryPtr:=$2 //結果の、IDの配列

C_LONGINT($ac_id)
C_LONGINT($i;$numOfRecs)
C_TEXT($setOrg;$setName)
$setOrg:=”set_org”
CREATE SET([JOURNAL];$setOrg) //最初は全件、評価したら除いていく
$setName:=”result_set”
CREATE EMPTY SET([JOURNAL];$setName) //最初は0件、まだないIDを追加していく

//元セットにレコードがなくなるまで繰り返す
USE SET($setOrg)
$numOfRecs:=Records in selection([JOURNAL])
FIRST RECORD([JOURNAL])
$ac_id:=$keyFldPtr->

While ($numOfRecs>0)
//結果セットを日付でクエリして、なければ追加、
USE SET($setName)
QUERY SELECTION([JOURNAL];$keyFldPtr->=$ac_id)
If (Records in selection([JOURNAL])=0)
//DB全体をクエリして最初のレコードを取得して、セットに追加
QUERY([JOURNAL];$keyFldPtr->=$ac_id)
FIRST RECORD([JOURNAL])
ADD TO SET([JOURNAL];$setName)

End if

//元のセットを日付でクエリして、元のセットからのぞく
USE SET($setOrg)
QUERY SELECTION([JOURNAL];$keyFldPtr->=$ac_id)
For ($i;1;Records in selection([JOURNAL]))
GOTO SELECTED RECORD([JOURNAL];$i)
REMOVE FROM SET([JOURNAL];$setOrg)

End for

//リデュースされた元セットの最初のレコードを取得
USE SET($setOrg)
$numOfRecs:=Records in selection([JOURNAL])
FIRST RECORD([JOURNAL])
$ac_id:=$keyFldPtr->

End while
CLEAR SET($setOrg)

//転送
USE SET($setName)
CLEAR SET($setName)


SELECTION TO ARRAY($keyFldPtr->;$outIDAryPtr->) //カレントセレクションがあるので、呼び出し元ではお好みのフィールドの値をSELECTION TO ARRAYで取得できる

使い方

呼び出し元では次のようにコーディング。この例では元となるセレクションは全件、このように元となるセレクションを作っておいて、そのセレクションの中でユニーク評価をして新たなセレクションを作る。呼び出し後に必要なフィールドの値を転送。

READ ONLY([JOURNAL])
ALL RECORDS([JOURNAL])<;br> JO_Distinct_byAC_ID (->[JOURNAL]JO_D_AC_ID;->$aryAC_ID)
SELECTION TO ARRAY([JOURNAL]JO_D_AC_CODE;$aryAC_CODE)
// SELECTION TO ARRAY(…

4D: TEXT型のフィールドにインデックスを張るときの注意

TEXT型のフィールドにインデックスを張るときの注意

フィールドに保存した文字列を検索しても該当しない、という現象にはまりました。(はまりレベル3)

テーブルHBにテキスト型のフィールドを追加しました。そのフィールドにHBのすべてのレコードについて、メソッドで求めた文字列を保存しました。その保存した文字列で検索しても該当しない、のです。

1対N構造のテーブルがあって(テーブルHBとテーブルKJ)、N側(テーブルKJ)のラインナップが同じであるテーブルHBのレコードを探す、という機能を実装していたときのことです。ロジック的には、テーブル HBの各レコードについてテーブル KJをクエリして判定すればいいのですが、テーブルHBにはレコードが1万件以上あって、遅くてとても実用になりません。テーブルKJをキャッシュして配列に持たせても同様に遅い、という状況でした。

処理の高速化を図るため、テーブルHBに「HB_KJLINE」というフィールドを用意して、KJ_IDをコンマ区切りの文字列で連結して保存します。こうしておくと上記のクエリはテーブルHBだけをクエリすればよいことになります。検索時に遅いので保存時に一つ余計なフィールドを用意して検索のための値を保存しておく、というデータベース高速化の常套手段です。

高速化のためのコーディングですから、追加したHB_KJLINEにはインデックスを作成しました。HB_KJLINEの文字列は255文字を超えるでしょうからテキスト型です。そして実行、値はHB_KJLINEに入っていますが、あるはずの文字列で検索しても該当なし、です。

カレントテーブル表示(コマンド+Uキー)でクエリ(コマンド+Y)して、そのフィールドに入っている文字列で検索してみても、該当しません。一つレコードを保存してみると、保存したレコードだけ正常に該当します。

(4D Japanのサポートに電話して解決しました。)

原因はインデックスにありました。テキスト型のフィールドにインデックスを作成した場合、最初の1,024文字までしか結果が保証されない、という4Dの仕様です。HBには380個以上のKJを持つものがあり、この場合KJ_IDがコンマを入れて一つ4〜5文字とするとKJLINEの文字数は1,024文字を超えます。インデックスのチェックを外したら検索できるようになりました。

教訓1:

テキスト型のフィールドにはインデックスを作成しない。高速化を図る場合は別の方法を考えること。

ここで次の教訓も覚えておきましょう。

教訓2:

4Dでは、レコード数が32000件以上の場合、FInd in Arrayの該当レコード番号が保証されなくなる。(はまりレベル5)