MendixのDBの中身を見てみると分かること

こちらの記事でMendixのDBの中身を直接見る方法を書きました。
実際にDBの中身を見てみると、いろいろ分かることがあります。

全てのEntityやAttributeがあるわけじゃない

非永続Entity（Non-Persistent Entitiy）やCalculate項目はDB上には存在しません。

そもそも

• 非永続Entityは一時的な用途に使うためのもの。メモリ上にのみ存在
• Calculate項目はRetriveされた時にMicroflowで計算される項目

なので、当然と言えば当然ではあります。

内部IDが払い出されている

DomainModelのEntityにはありませんでしたが、テーブルの方にはID列があり、ユニークな値を持っています。

このIDはオブジェクトを生成したタイミングでMendixによって採番されますが、その採番ルールは不明です。（なんとなく連番になっているように見えるが、その保証は無い）
従って、Mendixの内部DBのテーブルに対して外からSQL等でレコードを直接INSERTすることはできません。必ずMendixのロジックを介してレコードを生成する必要があります。

Associationは関連テーブル

Associationは同名の関連テーブルになります。

日時はUTC

このドキュメントに書いてあるように、Date and time型のAttributeはUTCとして格納されます。

The platform stores all dates in the UTC time zone.

継承しているEntityはどうなっているか

DomainModelの特徴の一つである継承はRDBではどのように展開されているのでしょうか。
例えば以下のようにParentを継承した子Entityが2つあり、それぞれに1件ずつレコードを登録したとします。

親Entityのテーブルを見てみると、子Entityに登録したレコードがそれぞれ存在します。
また、「submetaobjectname」という列が存在します。どの子Entityのオブジェクトか、を示す列です。

子Entityのテーブルを見てみると、親Entityのレコードと同じID値を持っていることが分かります。
レコードとしては分かれているけれども、オブジェクトとしては同一ということなのでしょう。

参考

• MendixのDBの中身を直接見てみる