Empecemos por el principio:
El error 150 se produce simplemente porque algún inconveniente impidió crear la tabla, modificarla, o bien crear algún indice o constraint index de algún tipo. En esencia, lo principal es que fue una acción que implicó escribir un archivo descriptor de estructura. El cuál sea, depende de lo que se encuentre.
Hay algunas razones comunes para el error:
Se intentó establecer una FK que entre campos que no cumplen las condiciones:
- Tipos de columna incompatibles, como numéricos de diferente rango, tipos mezclados, o con collations diferentes. El primer caso es, por ejemplo, que uno sea sólo INT y el otro INT UNSIGNED, lo que daría un error por diferentes rangos de representación. El último caso se produce cuando usas un VARCHAR de collation utf8 y otro latin1, por ejemplo.
- Datos inválidos en la tabla, en el campo definido como FK. Al crear la FK una de las primeras cosas que hace el sistema es verificar si la tabla donde está la FK contiene en ese campo algún valor que no se encuentre presente en la tabla referenciada (donde ese valor es PK). Es el error más habitual al modificar tablas que ya contienen datos, precisamente porque antes no tuvieron consistencia sostenida desde el DBMS, y se ingresaron datos basura.
- Incompatibilidad de motores de tablas: Se intenta definir FK en una tabla que es MyISAM y otra InnoDB.
- Nombres de consrtaint solapados: Se ingresó el nombre de la constraint al momento de crear la FK, pero se usó algún nombre que ya existía en la base, usado por otro componente.
- FK refiriendo a campos no PK o UNIQUE en la tabla referida. Una FK sólo puede apuntar a una PK. Excepcionalmente, MySQL admite que se apunte a un campo que es UNIQUE en esa tabla, aunque no sea la PK (en los hechos es una CC).
En tu caso, si el error se sigue produciendo con las tablas vacías, sólo se puede excluir el tema de los datos, pero hay que revisar todas las otras posibilidades.
Cita: ¿como hago en el mysqlquerybrowser para que si modifico el codigodebarras en la tabla producto tambien se modifique el mismo codigodebarras que tengo en la tabla ventas?
Para eso se le pone a la definición de FK la cláusula ON DELETE CASCADE ON UPDATE CASCADE. Pero atención: todas, absolutamente todas las veces que se use la FK, deberá en esa tabla estár incluida esta cláusula, ya que la misma sólo se define para una tabla en especial, y no es generico.
Cita: pero bien, ando batallando con eso ahorita. ya que tengo un dia para entregar, quisiera entregarlo ya con las relaciones.
¿Un día para entregar?
Considerando que es algo que debería haber estado desde el inicio, y que afectará completamente la performance de toda la base...
Deberías haberte asesorado antes. Ahora... sólo puedo desearte lo mejor.
Con un día no tenemos ni para hacer las primeras pruebas.
Nota bene: Una de las cosas que me olvidé aclararte al principio, es que otra de las características de la presencia de las FK es que las consultas pueden llegar a tener una performance muy diferente, porque el uso de las relaciones definidas como FK ayuda en toda consulta donde se usen, ya que esas FK se controlan por índices específicos... los que mejoran muchísimo la performance.
O sea... hay más razones.