データベースの詳細

最終更新日: 2024年3月18日
R8 | R9

モデルはデータベース内のテーブルに関連付けられます。この詳細を設定することができます。

概要

「画面 > その他 > データベースの詳細」を指定することができます。

テーブルを作成する

標準では有効となっています。この場合、モデルに対応するテーブルが作成されます。
この設定を無効にすると、テーブルが用意されません。正確には、利用データベースに対して CREATE TABLE 文を発行しません。(*1)

次の場合に利用できます。

*1 テーブルを作成しないと設定した場合でも、テーブル定義(DDL)は用意されます。DDLの詳細...

物理テーブル名

テーブルを作成し、かつ物理テーブル名を指定した場合、ここで指定されたテーブル名で CREATE TABLE 文を実行します。

テーブルを作成しないとし、かつ物理テーブル名を指定した場合、既存システムのテーブルを操作するようになります。

注意

物理テーブル名に利用できる文字は、ご利用のデータベースの制約に準じます。Wagbyではチェックしていないため、データベースのマニュアルでご確認ください。（例えば MySQL ではテーブル名にハイフン '-' が利用できません。）

異なるモデルで同じテーブルを共有する

異なるモデル A,B をそれぞれ定義したとき、モデルBで「テーブルを作成しない」とし、かつ「物理テーブル名にモデルA」を指定することで、モデルAとBは同じテーブルを共有することになります。(*2)

*2 同様の仕組みに「サブモデル」があります。サブモデルを設定すると、Wagbyがメインモデルとサブモデルに関係がある、と解釈できるため、ロックやキャッシュの処理は適切に行われます。一方、サブモデル設定ではなく、単に物理テーブルを共有した場合、そのような対応は行われません。両方のモデルでの整合性の維持は、開発者が注意して行うようにしてください。[詳細...]

スキーマを指定することはできない

物理テーブル名にスキーマを含めることはできません。

代案として、データベースの「シノニム」が使う方法があります。例えば Oracle では、シノニムを使って別スキーマのテーブルを別名のテーブルとして扱える仕組みがあります。詳細はご利用のデータベースのマニュアルをご確認ください。

日本語テーブル名を指定する

物理テーブル名に日本語テーブル名を指定することができます。[Appendix > DDL > 文字エンコード...]

キャッシュを有効にする

Wagbyはデータベースから読み込んだ値をメモリにキャッシュします。これによりデータベース操作回数を減らし、パフォーマンスを向上させています。標準ではキャッシュは有効となっています。

注意

本設定を無効にすると、常にデータベースを操作して最新のデータを取得するようになります。パフォーマンスに影響があるため、理由がなければキャッシュは有効とすることを推奨します。

1リクエスト間のキャッシュは常に有効

キャッシュを無効にした場合でも、1リクエスト間（WebブラウザとWebサーバ間の通信のやりとり）で発生したデータベースとのやりとりはメモリにキャッシュされます。[詳細...]

モデルのキャッシュ情報を定期的に消去する

ジョブを使ってモデルのキャッシュ情報を定期的に消去することができます。

Wagbyを通さずにデータベースを直接、変更する運用を行う場合

Wagbyを通さずに直接、データベースの値が変更されても Wagby はこれを検知できません。そのため古い情報がキャッシュとして残ります。運用上、データベースの値と画面上の値が異なることになります。

データベースの値を変更するような運用を想定している場合は、そのモデルのキャッシュを無効としてください。パフォーマンスに影響しますが、不正確な値が画面に表示される問題が解消されます。

識別子の区切り文字

Wagby は標準で、SQL文における識別子の区切り文字を設定するようになっています。詳細は「環境 > データベース > 識別子の区切り文字」をお読みください。

ロック方式

「ロック方式」をお読みください。

サブデータベース

「サブデータベースを指定する」をお読みください。

既存テーブルを再利用する場合の注意点

既存テーブルを再利用する場合の注意点をまとめました。

「テーブルを作成する」を無効とし、既存テーブル（またはビュー）名を「物理テーブル名」に記載します。
モデル内の項目は、既存テーブル（またはビュー）の項目と同じとなるようにします。物理カラム名や型も指定することができます。
Wagbyで定義したモデルの主キーと、既存テーブルの主キーは必ず一致させてください。
パフォーマンスのため、Wagbyのキャッシュはできるだけ有効としてください。既存テーブルが更新された場合、Wagbyのキャッシュを定期的に再作成する方法があります。またはマテリアライズドビューを使う方法も有効です。
既存テーブルが読み込み専用であれば、ロックについて考慮する必要はありません。既存テーブルをWagbyからも更新し、かつ既存システムからも更新される可能性がある場合は"テーブル操作に関する注意点まとめ > ロック"をお読みください。

トラブルシューティング

主キーの扱い

Wagbyで定義したモデルの主キーと、既存テーブルの主キーは必ず一致させてください。

ここが異なった場合、異常動作となります。（技術サポート対象外となります。）

必須項目の扱い

Wagbyで定義したモデルで「必須」とした項目で、実際には既存テーブル（またはビュー）側に NULL が存在していないかどうかを確認してください。Wagby は必須項目では NULL は存在しないという前提であるため、NULL が見つかると正しくデータを取得できず、エラーになります。

日付型項目の扱い

既存テーブルで日付を文字列で定義している場合があります。例: yyyyMMdd の 8文字。この場合、Wagby のモデル定義でも文字列とするしかありませんが、日付型の範囲検索やカレンダー補助入力機能が利用できなくなります。回避策として、既存テーブルのビューを定義し、データベースの関数を使って文字列から日付型へ置き換えることを検討してください。ビューで日付項目となっていれば、Wagbyの日付型を利用できるようになります。