Bueno, gracias por finalmente poner las sentencias de creación. Ahora algunas cosas resultan más claras.
Por lo pronto, el esquema de creación de todas las tablas, incluyendo las FK en la definición de la última, funciona bien:
Código MySQL:
Ver originalmysql>
Query OK, 0 rows affected (0.01 sec)
mysql>
Query OK, 0 rows affected (0.01 sec)
mysql>
mysql
> CREATE TABLE `relacion-primeratabla-segundatabla` (Query OK, 0 rows affected (0.06 sec)
Evidentemente, eso no tiene problemas de tipo de dato, o de sintaxis.
hacerlo en dos etapas requiere, como es evidente, no definirle más que la PK a la tercera tabla desde inicio:
Código MySQL:
Ver originalQuery OK, 0 rows affected (0.01 sec)
mysql>
Query OK, 0 rows affected (0.01 sec)
mysql>
mysql
> CREATE TABLE `relacion-primeratabla-segundatabla` (Query OK, 0 rows affected (0.01 sec)
mysql>
mysql
> ALTER TABLE `relacion-primeratabla-segundatabla`Query OK, 0 rows affected (0.03 sec)
mysql>
mysql
> ALTER TABLE `relacion-primeratabla-segundatabla`Query OK, 0 rows affected (0.07 sec)
Tampoco causa problemas, por lo cual no se ve defectos en ningún caso.
Francamente, llegado a este punto sólo puedo suponer que el problema está en la versión del phpMyadmin, o algo semejante, ya que al no ser parte de MySQL (es una interfaz programada en PHP), y realizar internamente la creación de las sentencias que envía a MySQL, hay un margen de error probable.
Como sea, ni la definición de las tablas está mal, ni tampoco las de las FK.
Finalmente, es posible que haya resultado demasiado áspera mi reacción, el problema es que me cansa sobremanera pedir
específicamente que posteen el CREATE TABLE, para que me terminen contestando con descripciones vagas, que ocultan mas cosas de las que aclaran.
Lo siento si fue excesivo. En algún momento me sacan de las casillas, porque es como si no leyesen lo que se les pide.
Como sea, mis disculpas.
Volviendo al tema, hay sí un par de consejos para que tengas en cuenta:
1)
Nunca uses caracteres reservados en los nombres de objetos de bases de datos. No se deben usar dentro de los nombres ni paréntesis, si signos aritméticos, porque en algún momento, por más precauciones que tengas, se producirá un error sintáctico a causa de ellos.
2) No pongas el "rango" de un tipo de dato numérico entero, sólo sirven en el DECIMAL. Ese "(3)" que le pusiste al SMALLINT no genera ningún tipo de efecto al rango de representación, y puede causarte problemas luego si usas VIEWs. Ese valor numérico
no representa el ancho de las cifras. Ponerlo, especialmente cuando es menor que el real, lo único que hará es confundirte y crearte problemas en el futuro.