$LISTBUILD (IDs of referenced objects) should do the trick. The "parent" table here is only storing the corresponding IDs not the entire objects. You need to save each object individually and then link them.

While the object counterpart takes care of saving/inserting both objects in memory, the same is not true for SQL. You need to treat each object as individual rows on different tables.

It is a best data management practice to add restrictions to fields if they have them. So adding the maxlen is "recommended"

Adding the maxlen won't result in wasted storage since storage is not reserved based on field definitions. If that were the case, in your particular scenario, you'd be actually saving storage since all string fields are defaulted to maxlen = 50 if you don't specify a value. 

Maybe I'm missing something, but, beyond how nulls are treated, if you want parent to be unique within this definition you must define a unique index on parent (alone). The index you have defined only guarantees that the combination (parent, name) will be unique.

Even if you declare the property as required it wouldn't still solve the uniqueness requirement. 

Few options without knowing much about current setup and the use case (eg. how much involvement you want to have in the process)

  • Synchronizing(shadow) between the 2 instances - Global export/import
  • Global mapping from one instance to another
    • You could merge global from source to target
  •  File transfer (traditional ETL) and manipulating the global directly (risky but doable) 

We may need more clarity to answer the specific question you have but here are some answers to things I could pull from your post:

- The reason relationships are not showing in ERD is because adding an object reference from one class to another doesn't generate a ForeignKey (only relationships do this automatically) thus no relationship is defined in the generated ERD. If a FK is required then it should be defined manually.

- The primary keys for the tables in the ERD diagram are listed in your posted image. The fields listed there are the ones that correspond to the primary key of each of the tables displayed. If you're looking for a programmatically way to see the primary (assuming you don't have access to the code) then you could check information_schema.key_column_usage for constraint_type = "PRIMARY KEY". You may need to look deeper depending on whether table correspond to a global mapped (legacy) table or a "pure" SQL table. 

- As for the different results, it may be you're passing the wrong value to the query (eg. ID for one table being used to query another) or indices are out of sync or corrupted (rebuilding indices should fix this).

Flyway (and Liquibase) allows migrations to be written in SQL so you don't need a fully integration to be able to use them with Cache/IRIS. Fully integrating (e.g. extending Flyway) would provide access to other automations and features that otherwise are not available with just SQL e.g. using the same script in different DBMS. In the case of Liquibase, automated rollback generation, etc.