INSERT con seleccion de 2 datos no me funca!

[tokkaido]

Hola, aprovechando la buena disposicion de la gente del foro quisiera preguntar que esta mal en mi consulta que no me resulta:

Código MySQL:

INSERT INTO temporal_cambioentrantes (codigo,posicion,prof,id_inventario)
VALUES (0,1,(
SELECT st.profundidad AS prof,st.id_interno as id_inventario 
FROM  (stock_bodegas  st INNER JOIN tipos_neumaticos tn ON tn.id_interno)
WHERE st.medida=9
LIMIT 1
))
 

cuando ejecuto esta parte sale bien:

Código MySQL:

SELECT st.profundidad AS prof,st.id_interno as id_inventario 
FROM  (stock_bodegas  st INNER JOIN tipos_neumaticos tn ON tn.id_interno)
WHERE st.medida=9
LIMIT 1
 

incluso cuando omito el:

st.profundidad AS prof

y su correspondiente campo en el insert se inserta bien, pero necesito insertar la profundidad y me arroja el sgte error:

1136 - Column count doesn't match value at row 1

o sea estoy clarito que me dice que no me calzan el numero de datos que quiero ingresar con las columnas:

ahora bien, mientras escribia esto me di cuenta que podia hacerlo de la sgte manera:

Código MySQL:

INSERT INTO temporal_cambioentrantes (codigo,posicion,profundidad,id_inventario)
VALUES (0,1,(
SELECT st.profundidad AS profundidad
FROM  (stock_bodegas  st INNER JOIN tipos_neumaticos tn ON tn.id_interno)
WHERE st.medida=9
LIMIT 1
),(
SELECT st.id_interno as id_inventario 
FROM  (stock_bodegas  st INNER JOIN tipos_neumaticos tn ON tn.id_interno)
WHERE st.medida=9
LIMIT 1
))
 

¿pero me pregunto si no habrá otra manera mas eficiente de hacer la consulta?

[gnzsoloyo]

Yo te advertí que era ineficiente...: multiples filas/ mismos datos/ un solo INSERT

Código MySQL:

INSERT INTO temporal_cambioentrantes(codigo, posicion, profundidad, id_inventario)
SELECT 0, 1, ST.profundidad, ST.id_inventario
FROM stock_bodegas  ST INNER JOIN tipos_neumaticos TN USING(id_interno)
WHERE st.medida=9
LIMIT 1;
 

[tokkaido]

pero si es otra consulta y que surgio precisamente por hacerte caso, jaja. esto es de cuando hago un cambio de neumatico a un bus usando un neumatico nuevo que saco del stock donde no estan individualizados para que se conviertan en entes individualizables (el que los individualice buen individualizador será).

gracias por la respuesta

[gnzsoloyo]

El tema es que el concepto es el mirmo, por eso lo decía.
Si vas a hacer un volcado de datos desde una tabla o un JOIN de tablas a otra, no te conviene tomar los valores individuales como subconsultas en el SELECT, porque eso hace que esa/s subconsulta/s se hagan una vez por cada campo en cada registro que se lea... y el hecho de que pueda haber más de un resultado en ese JOIN significa que lo hará primero con todos los registros, para recién entonces tomar el primero.
Por eso se considera poco eficiente.
A eso debes sumarle que si el WHERE campo = valor se hace sobre un campo que no es PK o no tiene índice definido sobre él, la consulta deberá leer al menos la mitad de la tabla (estimativamente hablando) antes de encontrar el valor buscado, y hará en toda esa tabla las subconsultas, una por vez....

O sea, si puedes hacer un INSERT ... SELECT sin meterle subconsultas en el SELECT, mejor.

Detalle: Si las subconsultas son parte del FROM o el WHERE, no tienen tanto impacto y son optimizables. Las que les pongas como campos del SELECT, no.

[tokkaido]

voy a analizar tus sugerencias, muy bienvenidas en todo caso, soy muy novato en esto de las BD y por alguna razon (obviamente ignorancia por mi parte) no he podido crear FK's para los tipos_neumaticos, de ahi la razon de usar los JOIN, las bases las he hecho desde Navicat y me arroja un error "Can't create table 'xxx' (errno: 150)". He googleado un poco pero no logro encontrar el porque, debe ser algun error mio, definitivamente

[gnzsoloyo]

) no he podido crear FK's para los tipos_neumaticos, de ahi la razon de usar los JOIN, las bases las he hecho desde Navicat y me arroja un error "Can't create table 'xxx' (errno: 150)".

Si tienes datos ya cargados, es posible que se esté produciendo una inconsistencia al intentar crear la contraint. Eso suele suceder cuando algún valor ya existente no cumple con la FK.
Otra posibilidad es que los campos que se intenta relacionar no sean exactamente iguales. Esto significa que, por ejemplo un campo INT UNSIGNED no puede usarse para una FK de un campo INT SIGNED, porque los rangos de representación son distintos; en el caso de un VARCHAR, por ejemplo, tienen que tener el mismo ancho, y del mismo CHARSET. Si intentas crear una FK entre un latin1 y un utf8, no podrás.