Habria que analizar
semanticamente el esquema para ver que esta relacionado con que....
Una cosa es que el motor no te permita crear las claves foraneas, con todas sus ventajas, y otra que la información no este relacionada entre si.
El programa que estas usando trabaja a nivel de sql estandar, no a nivel semàntico, con lo que al no encontrar ninguna sentencia de definición de claves foraneas indica que no existen....
Cita: reference_definition:
REFERENCES tbl_name (index_col_name,...)
[MATCH FULL | MATCH PARTIAL | MATCH SIMPLE]
[ON DELETE reference_option]
[ON UPDATE reference_option]
reference_option:
RESTRICT | CASCADE | SET NULL | NO ACTION
Fuente
y efectivamente puedes ver que no hay, cosa que es logico puesto que MyISAM daria error.
Por otro lado
Cita: O esto se considera clave foranea? KEY `group_active` (`group_enabled`)
quiere decir que crea un clave llamada
group_active sobre el campo
group_enabled se trataria de un indice.....
En este caso deberias dibujar tu las relaciones en el esquema a partir de los objetos, tablas, que si te habra dibujado automaticamente...
Cita: Es posible que un sistema de tickets como el conocido OSTICKET no utilice claves foraneas en su tablas?¿
yo NO lo conozco luego me es mas dificil hacer el anàlisis semantico.... es decir ver que papel juega cada tabla y por tanto cuales son los campos comunes que las relacionan....
Es decir en MyISAM un simple sistema de reservas de pistas de tenis donde tengamos las tablas usuarios, reservas, pistas se puede construir, sin claves foraneas, pero la tabla reservas tendra el identificador del usuario y de la pista reservada que la relacionaran con las otras tablas...no? Siempre y cuando la bbdd este minimamente normalizada claro.
Quim