サポート > リポジトリ > Appendix > 項目の型とデータベースの関係

Wagbyの項目の型と、データベースの型の関係を説明します。

データベースに格納される文字列型の標準サイズは次のとおりです。

データベース 定義
Oracle varchar2(255 char)
SQL Server nvarchar(255)
DB2 varchar(255)
MySQL varchar(255) (*1)
PostgreSQL varchar(255)
HSQLDB (内蔵DB) varchar(255)
1. varchar 型で指定する数は MySQL のバージョンによって変わります。4.1 以前は「バイト」単位ですが、それ以降は「文字」単位です。詳細はMySQLのマニュアルでご確認ください。

データベースに格納される数値型の標準サイズは次のとおりです。

データベース 定義
Oracle 整数 number(10,0)
1バイト整数 number(3,0)
2バイト整数 number(5,0)
4バイト整数 number(10,0)
8バイト整数 number(19,0)
4バイト浮動小数 float
8バイト浮動小数 double precision
SQL Server 整数 int
1バイト整数 tinyint
2バイト整数 smallint
4バイト整数 int
8バイト整数 numeric(19,0)
4バイト浮動小数 float
8バイト浮動小数 double precision
DB 2 整数 integer
1バイト整数 smallint
2バイト整数 smallint
4バイト整数 integer
8バイト整数 bigint
4バイト浮動小数 float
8バイト浮動小数 double
MySQL 整数 integer
1バイト整数 tinyint
2バイト整数 smallint
4バイト整数 integer
8バイト整数 bigint
4バイト浮動小数 float
8バイト浮動小数 double precision
PostgreSQL 整数 int4
1バイト整数 int2
2バイト整数 int2
4バイト整数 int4
8バイト整数 int8
4バイト浮動小数 float4
8バイト浮動小数 float8
HSQLDB (内蔵DB) 整数 int4
1バイト整数 int2
2バイト整数 int2
4バイト整数 int4
8バイト整数 int8
4バイト浮動小数 float4
8バイト浮動小数 float8

文字列型の項目をテキストエリアに変更した場合(またはその逆に、テキストエリア指定を解除した場合)Wagby は関連するモデルのテーブル定義を変更することがあります。例えば外部データベースに MySQL を用いている場合、通常の文字列型は varchar 型を適用しますが、テキストエリアの場合は text 型を用いるようになります。

テキストエリアを指定した項目には「格納できる文字数」の上限があります。これはデータベースによって変動します。 これを変更する場合は"テーブル定義の型"を直接、指定してください。

データベース文字列文字列(テキストエリア)
HSQLDB(組み込みDB)varchar(4000)varchar(4000)
PostgreSQLvarchar(255)text (*1)
Oraclevarchar2(255)varchar2(4000)
SQL Servernvarchar(255)nvarchar(1000)
DB 2varchar(255)varchar(4000)
MySQLvarchar(255)text (*2)
1. PostgreSQL の text 型は 1G バイトです。
2. MySQL の text 型は 65,535 バイトです。

モデルを参照する側(参照元モデル)の項目では、参照先モデルのID値を保持します。内容部ではありません。

データベース上のテーブルを確認すると、ID値が格納されていることがわかります。

図6は、標準で用意されているアカウントモデル(juser)のテーブル構成を抜粋したものです。「所属グループ(jgroupid)」項目はグループモデル(jgroup)をチェックボックスとしてモデル参照しています。この項目は juser テーブルには存在しません。代わって「juser$jgroup」という名前のテーブルが作成されます。

図1 テーブルイメージ
  • テーブル名は「モデル名$項目名」です。
  • 所属先となるjuserテーブルの主キーを持ちます。
  • 「項目名jshid」という列が自動的に付加されます。これも主キーの一部になります。これは内部管理上、インデックス列として用意されるものです。
  • 「項目名jshid」の値は 0 から開始されます。また飛び番号はありません。

一つも選択していない状態は、別テーブルに一件もデータがないという状態になります。実際に保持する値(上の例では jgroupid 列の値)は、参照先モデル(jgroup)の主キーになります。

データベースを直接操作する場合、「項目名jshid」は 0 から開始かつ飛び番号なしというルールを遵守してください。不整合が生じた場合、チェックボックス項目は機能しなくなります。

繰り返し属性を指定した項目は、別テーブルに分割されます。(1:Nの関係になります。)そのため登録できるデータ数の上限はありません。

厳密には採用する外部データベースの、1テーブルに保持できるレコード数が理論的な上限となります。よって実運用での制約は、なしとみなすことができます。

生成されるテーブルは「モデル名$項目名」となります。

繰り返しコンテナは、別テーブルに分割されます。(1:Nの関係になります。)そのため登録できるデータ数の上限はありません。

厳密には採用する外部データベースの、1テーブルに保持できるレコード数が理論的な上限となります。実運用での制約は、なしとみなすことができます。

生成されるテーブル名は「モデル名$(繰り返しコンテナ)項目名」となります。このテーブルの命名規則は固定です。

繰り返しコンテナ項目は、物理カラムを指定しても無視されます。

繰り返しコンテナID

「繰り返しコンテナID」は、標準では "<コンテナ名>jshid" という名前のカラムが用意されます。型は整数型です。

  • 「繰り返しコンテナID」はデータベースに保存する必要があります。データベース非保存とすると正しく動作しません。
  • 「繰り返しコンテナID」はデータベースには "0" から開始される連番として値が保存されています。nullは許容しません。また、飛び番号も認められません。

この「繰り返しコンテナID」の物理カラムを指定することができます。

図2 「繰り返しコンテナID」の物理カラムを指定する