La cuestión ahora es que si opto por la solución de:

1) el campo discriminatorio entonces no puedo definir la FK a nivel de base de datos pues una vez apuntará a una tabla y otras a otra.

2) las 2 FK resulta que las dos FK pueden estar a NULL y convertir al registro en corrupto (huérfano). Además de tener que hacer un alter table cada vez que incluya en mi modelo una nueva tabla ElementTypeX para crear la nueva FK.

3) lo de las dos tablas de SubElement es la que menos me gusta pues resultaría que objetos del mismo tipo se correspondería en BD con tablas diferentes, sin contar la multiplicación del trabajo en la capa DAO cada vez que aparece un nuevo objeto de tipo ElementTypeX que requiere SubElements.

4) no te gusta la 4.. joer.. sí se ve muy liosa :)

Pero…. si quieres seguir con ibatis… supongo que la solución sería del estilo de la tercera, en la que SubElement tiene un campo discrimatorio para saber a que corresponde. O tener dos FK y escoger tú según busques por un sitio o por otro. Aunque en ibatis no te costaría tampoco demasiado optar por el segundo (dos tablas separadas). Lo que te sea más cómodo y mejor se adapta el uso que le quieras dar (cantidad de registros, participaciones en joins, etc.)

La verdad es que la que no cogería es la 4 XD.

2) Uso Ibatis y el modelo lo defino yo a pelo, también toda la capa DAO.

Te resumo la historia:

Un SubElement sólo pertenece a un ElementTypeX, pero puede ser a un ElementType1 o a un ElementType2. ¿Cómo diseño una relación que aveces apunte a ElementType1 y otras a ElementType2? ¿O cómo demonios se hace esto? :)

1.- ¿Un Subelement puede pertenecer a la vez a ElementType1 y ElementType2?.

2.- Ya que hablas de beans, entiendo que partes del diseño de objetos para que te genere el relacional, ¿no puedes utilizar herencia para definir esa relación de en un AbstractElementTypeWithSubElements y que sea el ORM quién se encargue de discernir estas cosas?

esto es privado?

No encuentro en la base de datos algo que me permita incluir bifurcaciones lógicas a la hora de definir una clave externa. Sería una solución estupenda.

Entonces resumo toda la duda expuesta en este post con el siguiente enunciado:

¿Es posible definir una clave externa a partir de dos campos?:

Uno define a que tabla apunta y el otro contiene el id del registro de la tabla externa.

(Coincidimos exactamente en tú última frase)

en dvd studio pro pasa algo parecido, si yo tengo una pista de vídeo gigante que llama el tipo de botón: “ver la película” esa pista de vídeo gigante no ofrece ningún problema porque se reproduce de principio a fin. Pero si lo que queremos es llamar a los capítulos de esa pista de vídeo (esto no es exactamente tu sub element pero se parece mucho) yo coloco unas cositas que se llaman marcadores de manera que cada botón cap 1 ó 2 ó 3.. llaman a ése marcador y no a otro…
El problema viene si en lugar de que continúe de corrido yo quiero que el comportamiento de esos botones varíe y al finalizar vuelva al menú de capítulos en lugar de remitir al capítulo siguiente… (esto en una peli tal vez no, pero en otras situaciones puede tener su lógica) resulta que en el boton llamado “ver la peli” va a pasar lo mismo y eso no le gusta a nadie…estás viendo la peli y al final de cada capítulo te lleva al menú de capítulos en lugar de verla de seguido!!!

si ya aquí ves que no tiene nada que ver con lo tuyo pues deja de leerme…
Sería una tontería cortar la peli en chorizos-capítulos que linkar a los botones de capítulos y dejar la otra pista entera e impoluta linkada a ver toda la peli porque la info estarÍa duplicada y eso no le gusta al que lo hace, ni al dvd que no le cabe, ni es bonito ni nada…

la solución es una cosa maravillosa que en ese programa se llama script y que supone un enunciado para cada uno de esos botones, de manera que no asocias botón a marcador si no a script…
yo no sé cómo se traduce eso, pero imagino algo del tipo: si pulso capítulo 3 llévame al script q dice vas al marcador 3 y vuelves al finalizar al menú capítulos.
oye, que te quiero…