Mendix의 DB 내용을 보시면 알 수 있습니다.

여기.라는 글에서 메인덱스의 DB 내용을 직접 보는 방법을 썼다.
실제로 DB의 내용을 보면 많은 것을 알 수 있다.
모든 Enity와 Attribute가 다 있는 것은 아닙니다.
비영구 Enity(Non-Persistent Enity) 및 Calculate 프로젝트는 DB에 존재하지 않습니다.


말하기 시작하다

비영구 Enity는 임시 어플리케이션에 사용됩니다.스토리지에만 있음

Calculate 항목이 Retrive에서 마이크로플로우로 계산된 항목

그래서 당연하다고 한다.
내부 ID가 나왔어요.
Domain Model의 Enity에는 없지만 테이블에는 ID 열이 있고 독특한 값이 있습니다.

이 ID는 객체를 생성하는 동안 Mendix에서 번호를 매기지만 번호 규칙이 불분명합니다.(왠지 연호 같은데 장담이 없다.)
따라서 Mendix 내부 DB의 표는 외부에서 SQL 등을 통해 직접 INSERT로 기록할 수 없다.Mendix의 논리를 통해 기록을 생성해야 합니다.
관련 테이블
Association은 동일한 이름의 연관 테이블입니다.


시간은 UTC
이 문서에 기재된 대로 Date and time형의 Attribute는 UTC로 저장됩니다.
The platform stores all dates in the UTC time zone.


상속된 Enity 는 어떤 제품입니까?
Domain Model의 특징 중 하나인 상속은 RDB에서 어떻게 전개될까.
예를 들어 Parent를 상속받은 두 명의 아이 Enity가 각각 기록을 등록했다.

부모의 테이블을 들여다보면 아이 에니티가 등록한 기록이 각자 존재한다.
"submetaobjectname"열도 있습니다.어떤 하위 Enity 객체의 열을 나타냅니다.

아이의 Enity 책상을 보면 부모의 Enity 기록과 같은 ID 값을 가지고 있다는 것을 알 수 있다.
음반으로는 분리됐지만 대상으로는 동일하죠.


참고 자료

Mendix의 DB 내용을 직접 보십시오