no consigo hacer funcionar sum()

[gralf]

con esta consulta

Código MySQL:

select id_item, sum('compra'-'taller'-'venta'+'regula_mas'-'regula_menos') as stock from movimiento group by id_item;
 

obtengo
id_item 1 stock 0
352 stock 0

sobre esta tabla

Código MySQL:

id_mov  int(5) unsigned NO  PRI     auto_increment
venta   int(5) unsigned YES         
compra  int(5) unsigned YES         
taller  int(5) unsigned YES         
regula_mas  int(5) unsigned YES         
regula_menos    int(5) unsigned YES         
fecha   timestamp   NO      CURRENT_TIMESTAMP   on update CURRENT_TIMESTAMP
id_item int(5)  NO  MUL     
id_lente    int(2)  YES MUL     
id_cilindro int(2)  YES MUL     
id_esfera   int(5)  YES MUL
 

y tengo varios movimientos para esos id_items

Código MySQL:

1       100             2014-12-13 13:37:04 1           
2       58              2014-12-13 13:37:04 352         
5   1                   2014-12-13 13:38:48 1           
6           2           2014-12-13 13:38:48 1           
7               5       2014-12-13 13:41:25 352         
8                   2   2014-12-13 13:41:25 1
 

[gnzsoloyo]

Código SQL:

SELECT 
    id_item, SUM('compra'-'taller'-'venta'+'regula_mas'-'regula_menos') AS stock 
FROM movimiento 
GROUP BY id_item;
 

Estás sumando cadenas de texto, no valores...

Cuando usas apóstrofos (') todo lo que contengan es una cadena de texto. Si lo que quieres es sumar los contenidos de campos con ese nombre deben ir sin apostrofos:

Código SQL:

SELECT 
    id_item, SUM(compra - taller - venta + regula_mas - regula_menos) stock 
FROM movimiento 
GROUP BY id_item;
 

Lo que puede es que estés confundiendo los acentos agudos (`) con los apóstrofos (') y no son los mismos caracteres, ni tampoco MySQL los usa para lo mismo.

[gralf]

Iniciado por gnzsoloyo

Código SQL:

SELECT 
    id_item, SUM('compra'-'taller'-'venta'+'regula_mas'-'regula_menos') AS stock 
FROM movimiento 
GROUP BY id_item;
 

Estás sumando cadenas de texto, no valores...

Cuando usas apóstrofos (') todo lo que contengan es una cadena de texto. Si lo que quieres es sumar los contenidos de campos con ese nombre deben ir sin apostrofos:

Código SQL:

SELECT 
    id_item, SUM(compra - taller - venta + regula_mas - regula_menos) stock 
FROM movimiento 
GROUP BY id_item;
 

Lo que puede es que estés confundiendo los acentos agudos (`) con los apóstrofos (') y no son los mismos caracteres, ni tampoco MySQL los usa para lo mismo.

Pues tal y como lo pones

Código SQL:

SELECT 
    id_item, SUM(compra - taller - venta + regula_mas - regula_menos) stock 
FROM movimiento 
GROUP BY id_item;
 

lo he probado y el resultado es el mismo :(

[gnzsoloyo]

OK, ahora una pregunta crítica: Los espacios vacios que a parecen en esta muestra:

Código MySQL:

1       100             2014-12-13 13:37:04 1           
2       58              2014-12-13 13:37:04 352         
5   1                   2014-12-13 13:38:48 1           
6           2           2014-12-13 13:38:48 1           
7               5       2014-12-13 13:41:25 352         
8                   2   2014-12-13 13:41:25 1
 

¿Son columnas que contienen NULL?

Porque te comento que sumar, restar, multiplicar, dividir o concatenar cualquier cosa con NULL da... NULL.
NULL no es un dato, es un estado de indefinición y no se debe hacer operaciones contra él, sino en todo caso verificar si algo es o no NULL y proceder en consecuencia.
Para que la query funcione si el campo es NULL, sólo puede hacerse con funciones:

Código MySQL:

SELECT 
    id_item, SUM(IFNULL(compra, 0) - IFNULL(taller, 0) - IFNULL(venta, 0) + IFNULL(regula_mas, 0) - IFNULL(regula_menos, 0)) stock 
FROM movimiento 
GROUP BY id_item;
 

¿Qué devuelve así?

[gralf]

Pensé que esos campos estarían mejor con null por defecto, como suelo hacer con los id que refieren a otras tablas.

Lonmejor sera cambiar compra, venta, taller, regulamas,regulamenos a notnull entonces, verdad? O les pongo valor por defecto 0, que es lo mejor?

Y gracias por tus respuestas

[gnzsoloyo]

DEFAULT NULL es suficiente, o de lo contrario te verás obligado a recordar en cada consulta que hagas que debes usar IFNULL() para evitar problemas.
En cuanto a poner NOT NULL, es una decisión de diseño. Si son datos opcionales, es decir qu eno es mandatorio que se ingresen, no hace falta. Poner NOT NULL obliga a MySQL a realizar una validación en cada INSERT y UPDATE para verificar esos campos, lo que cuando se trata de millones de registros peude tener impacto en la performance. Pero si son opcionales, le pones un valor por defecto y listo.

[gralf]

Iniciado por gnzsoloyo

DEFAULT NULL es suficiente

pero, ¿este no es precisamente el problema que tengo?

la tabla es esta




el uso que quiero darle es que en cada inserción, la inserción se hará

o en el campo venta
o en el campo compra
o en el campo taller
o en el campo regulamas
o en el campo regula menos
y en el campo id_item

o sea que he hecho cuatro inserciones
para unas pruebas y por eso salen tantos campos con null, ¿no es así?

digo yo entonces, lo suyo sería que compra, venta, taller, regulamas y regula menos tuvieran 0 por default y como NULL llevaran NO?

voy aprobar

la tabla queda así



los movimientos así



y el resulado


Error Code: 1690. BIGINT UNSIGNED value is out of range in '(`stocklentesbrujuleando3`.`movimiento`.`compra` - `stocklentesbrujuleando3`.`movimiento`.`venta`)'


ya he brujuleado por internet y parece ser que el problema está en los unsigned, pero es que meparecen importantes para que nadie meta movimientos en negativo, lo cual estropearía los resultados, ¿no?


auqnue lo que no entiendo es que ningun resultado da por debajo de 0

[gnzsoloyo]

Creo que deberías aprender a interpretar los errores ajenos... Es medio evidente que quería referirme en realidad a DEFAULT '0', ¿no te parece?
Precisamente estamos discutiendo eso...

Error Code: 1690. BIGINT UNSIGNED value is out of range in '(`stocklentesbrujuleando3`.`movimiento`.`compra` - `stocklentesbrujuleando3`.`movimiento`.`venta`)'

Eso es medio evidente si miras con mucho más cuidado los datos y haces lo que se denomina una "prueba de escritorio". Es altamente probable que estés intentando insertar en un campo que es UNSIGNED un valor negativo, porque el cálculo aritmético interior del SUM() se hace en cada registro, cuando primero deberías obtener las sumas de cada columna...

Código MySQL:

SELECT id_item, (compra - taller - venta + regula_mas - regula_menos) stock 
FROM
  (SELECT 
    id_item, 
    IFNULL(SUM(compra), 0) compra, 
    IFNULL(SUM(taller), 0) taller, 
    IFNULL(SUM(venta), 0) venta, 
    IFNULL(SUM(regula_mas), 0) regula_mas,
    IFNULL(SUM(regula_menos), 0) regula_menos
  FROM movimiento 
  GROUP BY id_item) T1
ORDER BY id_item;
 

La verdad es que para hacer pruebas tan específicas y crear consultas que te sirvan, necesitaríamos contar con tu propia base, y entender con mucha claridad lo que haces. Pero esa es tu parte de la tarea.

[gralf]

Iniciado por gnzsoloyo

Creo que deberías aprender a interpretar los errores ajenos... Es medio evidente que quería referirme en realidad a DEFAULT '0', ¿no te parece?
Precisamente estamos discutiendo eso...


Eso es medio evidente si miras con mucho más cuidado los datos y haces lo que se denomina una "prueba de escritorio". Es altamente probable que estés intentando insertar en un campo que es UNSIGNED un valor negativo, porque el cálculo aritmético interior del SUM() se hace en cada registro, cuando primero deberías obtener las sumas de cada columna...

Código MySQL:

SELECT id_item, (compra - taller - venta + regula_mas - regula_menos) stock 
FROM
  (SELECT 
    id_item, 
    IFNULL(SUM(compra), 0) compra, 
    IFNULL(SUM(taller), 0) taller, 
    IFNULL(SUM(venta), 0) venta, 
    IFNULL(SUM(regula_mas), 0) regula_mas,
    IFNULL(SUM(regula_menos), 0) regula_menos
  FROM movimiento 
  GROUP BY id_item) T1
ORDER BY id_item;
 

La verdad es que para hacer pruebas tan específicas y crear consultas que te sirvan, necesitaríamos contar con tu propia base, y entender con mucha claridad lo que haces. Pero esa es tu parte de la tarea.

jejejejjejej, tienes razón, pero te veo tan seguro que me hiciste dudar, de todos modos ya has visto que lo he arreglado como te imaginabas.

el error del unsigned me lo daba al hacer la consulta

Código MySQL:

SELECT id_item, (compra - taller - venta + regula_mas - regula_menos) stock 
FROM movimiento group by id_item)
 

la verdad me extrañaba, porque los resultados no son negativos, pero he pensado que por el orden igual si en algun momento llegaba a un resultado negativo, con lo que lo ha cambiado por

Código MySQL:

SELECT id_item, (compra +regula_mas- taller - venta  - regula_menos) stock 
FROM movimiento group by id_item)
 

et voilá

ha quedado solucionado

[gralf]

me respondo a m i mismo, NO queda solucionado, si un articulo quedda con stock - , el error aparece de nuevo




lo unico que hago es consultar esto

select sum(compra+regula_mas-venta-taller-regula_menos) as stock from movimiento

Código MySQL:

-- phpMyAdmin SQL Dump
-- version 4.3.2
-- http://www.phpmyadmin.net
--
-- Servidor: localhost
-- Tiempo de generación: 14-12-2014 a las 10:23:31
-- Versión del servidor: 5.5.28-log
-- Versión de PHP: 5.3.26
 
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";
 
--
-- Base de datos: `stocklentesbrujuleando3`
--
 
-- --------------------------------------------------------
 
--
-- Estructura de tabla para la tabla `movimiento`
--
 
CREATE TABLE IF NOT EXISTS `movimiento` (
  `id_mov` int(5) unsigned NOT NULL,
  `venta` int(5) unsigned DEFAULT '0',
  `compra` int(5) unsigned DEFAULT '0',
  `taller` int(5) unsigned DEFAULT '0',
  `regula_mas` int(5) unsigned DEFAULT '0',
  `regula_menos` int(5) unsigned DEFAULT '0',
  `fecha` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `id_item` int(5) NOT NULL,
  `id_lente` int(2) DEFAULT NULL,
  `id_cil` int(2) DEFAULT NULL,
  `id_esf` int(5) DEFAULT NULL
) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=utf8;
 
--
-- Volcado de datos para la tabla `movimiento`
--
 
INSERT INTO `movimiento` (`id_mov`, `venta`, `compra`, `taller`, `regula_mas`, `regula_menos`, `fecha`, `id_item`, `id_lente`, `id_cil`, `id_esf`) VALUES
(9, 0, 100, 0, 0, 0, '2014-12-13 16:08:17', 1, NULL, NULL, NULL),
(10, 0, 0, 2, 0, 0, '2014-12-13 16:09:03', 1, NULL, NULL, NULL),
(11, 1, 0, 0, 0, 0, '2014-12-13 16:09:03', 1, NULL, NULL, NULL),
(12, 0, 58, 0, 0, 0, '2014-12-13 16:10:50', 352, NULL, NULL, NULL),
(13, 0, 0, 0, 0, 12, '2014-12-13 16:10:50', 352, NULL, NULL, NULL),
(14, 125, 0, 0, 0, 0, '2014-12-14 07:23:13', 1, NULL, NULL, NULL);
 
--
-- Índices para tablas volcadas
--
 
--
-- Indices de la tabla `movimiento`
--
ALTER TABLE `movimiento`
  ADD PRIMARY KEY (`id_mov`), ADD KEY `fk_movimiento_cilindro1_idx` (`id_cil`), ADD KEY `fk_movimiento_esfera1_idx` (`id_esf`), ADD KEY `fk_movimiento_lentes1` (`id_lente`), ADD KEY `fk_salida_item1_idx` (`id_item`), ADD KEY `fk_movimiento_item_idx` (`id_item`);
 
--
-- AUTO_INCREMENT de las tablas volcadas
--
 
--
-- AUTO_INCREMENT de la tabla `movimiento`
--
ALTER TABLE `movimiento`
  MODIFY `id_mov` int(5) unsigned NOT NULL AUTO_INCREMENT,AUTO_INCREMENT=15;
--
-- Restricciones para tablas volcadas
--
 
--
-- Filtros para la tabla `movimiento`
--
ALTER TABLE `movimiento`
ADD CONSTRAINT `fk_movimiento_cilindro1` FOREIGN KEY (`id_cil`) REFERENCES `cilindro` (`id_cil`) ON DELETE NO ACTION ON UPDATE NO ACTION,
ADD CONSTRAINT `fk_movimiento_esfera1` FOREIGN KEY (`id_esf`) REFERENCES `esfera` (`id_esf`) ON DELETE NO ACTION ON UPDATE NO ACTION,
ADD CONSTRAINT `fk_movimiento_item` FOREIGN KEY (`id_item`) REFERENCES `item` (`id_item`) ON DELETE NO ACTION ON UPDATE NO ACTION,
ADD CONSTRAINT `fk_movimiento_lentes1` FOREIGN KEY (`id_lente`) REFERENCES `lentes` (`id_lente`) ON DELETE NO ACTION ON UPDATE NO ACTION;
 

[replica]

Bueno, ya se ha dicho, pero quería compartir que el Default a 0 lo utilizo en la mayoría de los campos con valores numéricos.

Sobre todo si se tratan de saldos, cuotas, importes, cantidades, iva, descuentos, totales o cualquier cosa que implique dinero. Básicamente porque hay que sumar, restar, multiplicar y dividir.

Siempre lo he hecho así, y no estaba seguro de que NULL no evaluaba automáticamente a 0. Ahora ya lo sé.

[gnzsoloyo]

Bueno, ya se ha dicho, pero quería compartir que el Default a 0 lo utilizo en la mayoría de los campos con valores numéricos.

Es mucho una decisión de diseño, no hay una regla constante.
En general, en la empresa en que trabajo se suelen usar estos criterios para usar DEFAULT '0':
- No se usa con campos FK.
- No se usa si el dato es mandatorio (obligatorio), aunque no sea FK, por ejemplo cuando debe tener un valor entre un set fijo.
- No se usa en campos nuevos que se agregan a una tabla, a fin de detectar fácilmente los registros que se agregaron antes y después de ese cambio. Esto es importante para ciertas consultas y reportes.

Sobre todo si se tratan de saldos, cuotas, importes, cantidades, iva, descuentos, totales o cualquier cosa que implique dinero. Básicamente porque hay que sumar, restar, multiplicar y dividir.

Eso es correcto. poner DEFAULT '0' en esos casos ayuda a evitar errores por parte de los programadores que omitan algún valor en algún momento.

[gralf]

Yo si no me afecta a mis cuentas, que es lo que entiendo que haceis, lo dejo así.

Pero el probl!ma del error en sum, tiene arreglo?

[gnzsoloyo]

Iniciado por gralf

Yo si no me afecta a mis cuentas, que es lo que entiendo que haceis, lo dejo así.

Pero el probl!ma del error en sum, tiene arreglo?

Lo que tienes no es un problema de consulta, sino una inconsistencia de datos...

Según lo que posteaste, lo que tienes en esa tabla es esto:

Código MySQL:

mysql> use stocklentesbrujuleando3
Database changed
mysql> SELECT
    ->     id_item,
    ->     IFNULL(compra, 0) compra,
    ->     IFNULL(taller, 0) taller,
    ->     IFNULL(venta, 0) venta,
    ->     IFNULL(regula_mas, 0) regula_mas,
    ->     IFNULL(regula_menos, 0) regula_menos
    ->   FROM movimiento ;
+---------+--------+--------+-------+------------+--------------+
| id_item | compra | taller | venta | regula_mas | regula_menos |
+---------+--------+--------+-------+------------+--------------+
|       1 |    100 |      0 |     0 |          0 |            0 |
|       1 |      0 |      2 |     0 |          0 |            0 |
|       1 |      0 |      0 |     1 |          0 |            0 |
|     352 |     58 |      0 |     0 |          0 |            0 |
|     352 |      0 |      0 |     0 |          0 |           12 |
|       1 |      0 |      0 |   125 |          0 |            0 |
+---------+--------+--------+-------+------------+--------------+
6 rows in set (0.00 sec)
 

Si te fijas con cuidado, en el último movimiento tienes una venta de 125 unidades, pero sólo 100 en stock (primer registro)
Sencillamente tienes un error de aplicación porque no estás validando que existan unidades en stock antes de realizar la venta...

Por otro lado, observando tus tablas, quisiera hacerte una aclaración...
Ese número "(5)" que estás poniendo es un error porque no representa la cantidad de dígitos que se almacenan. Eso se usa para otras cosas, y eventualmente puede causarte problemas.

Este es un tema recurrente, y para el caso aplica lo que dice el manual de referencia:

MySQL supports an extension for optionally specifying the display width of integer data types in parentheses following the base keyword for the type. For example, INT(4) specifies an INT with a display width of four digits. This optional display width may be used by applications to display integer values having a width less than the width specified for the column by left-padding them with spaces. (That is, this width is present in the metadata returned with result sets. Whether it is used or not is up to the application.)

The display width does not constrain the range of values that can be stored in the column. Nor does it prevent values wider than the column display width from being displayed correctly. For example, a column specified as SMALLINT(3) has the usual SMALLINT range of -32768 to 32767, and values outside the range permitted by three digits are displayed in full using more than three digits.

Esto que te resalto dice: "El valor mostrado no restringe el rango de valores que pueden ser almacenados en la columna. Tampoco previene que valores mayores de la columna sean mostrados correctamente".
El único uso que tiene ese numero es para que ciertas aplicaciones que sólo tienen un rango dado fijo de salida, puedan recibir la columna "formateada" adecuadamente, pero no representa al dato.
El rango del dato está dado por su tipo de columna. Lo correcto es que un INT UNSIGNED tenga un ancho de salida de 10, cosa que MySQL pone automáticamente si sólo le indicas el tipo de dato, sin ese valor.

Por otro lado, como ciertas funciones de MySQL leen esa definición de ancho para ciertas tareas (generación de vistas, por ejemplo), podría darse que valores mayores sean leídos incorrectamente, dando resultados erróneos en las consultas, porque MySQ "cortaría" el número, descartando parte de su valor.

En síntesis: No los uses. Deja que MySQL ponga el que corresponda.

Sí se usan con los DECIMAL, pero eso es otro caso completamente distinto, y alli sí tiene sentido usarlos.

[gralf]

Iniciado por gnzsoloyo

Lo que tienes no es un problema de consulta, sino una inconsistencia de datos...

Según lo que posteaste, lo que tienes en esa tabla es esto:
Código MySQL:

Ver original

mysql> use stocklentesbrujuleando3
Database changed
mysql> SELECT
-> id_item,
-> IFNULL(compra, 0) compra,
-> IFNULL(taller, 0) taller,
-> IFNULL(venta, 0) venta,
-> IFNULL(regula_mas, 0) regula_mas,
-> IFNULL(regula_menos, 0) regula_menos
-> FROM movimiento ;
+---------+--------+--------+-------+------------+--------------+
| id_item | compra | taller | venta | regula_mas | regula_menos |
+---------+--------+--------+-------+------------+--------------+
| 1 | 100 | 0 | 0 | 0 | 0 |
| 1 | 0 | 2 | 0 | 0 | 0 |
| 1 | 0 | 0 | 1 | 0 | 0 |
| 352 | 58 | 0 | 0 | 0 | 0 |
| 352 | 0 | 0 | 0 | 0 | 12 |
| 1 | 0 | 0 | 125 | 0 | 0 |
+---------+--------+--------+-------+------------+--------------+
6 rows in set (0.00 sec)



Si te fijas con cuidado, en el último movimiento tienes una venta de 125 unidades, pero sólo 100 en stock (primer registro)
Sencillamente tienes un error de aplicación porque no estás validando que existan unidades en stock antes de realizar la venta...

bueno, en principio esto lo he hecho para hacer pruebas desde phpmyadmin, para ver que pasaba si me encontraba con un artículo en stock negativo, ya se que no tiene mucho sentido, pero ya digo, era en plan pruebas.

1- sea como sea, se puede arreglar para que te de el resultado negativo sin dar error?
2- cómo tendría que hacer para esa validación de stock previa?

Por otro lado, observando tus tablas, quisiera hacerte una aclaración...
Ese número "(5)" que estás poniendo es un error porque no representa la cantidad de dígitos que se almacenan. Eso se usa para otras cosas, y eventualmente puede causarte problemas.

Este es un tema recurrente, y para el caso aplica lo que dice el manual de referencia:
Cita:
MySQL supports an extension for optionally specifying the display width of integer data types in parentheses following the base keyword for the type. For example, INT(4) specifies an INT with a display width of four digits. This optional display width may be used by applications to display integer values having a width less than the width specified for the column by left-padding them with spaces. (That is, this width is present in the metadata returned with result sets. Whether it is used or not is up to the application.)

The display width does not constrain the range of values that can be stored in the column. Nor does it prevent values wider than the column display width from being displayed correctly. For example, a column specified as SMALLINT(3) has the usual SMALLINT range of -32768 to 32767, and values outside the range permitted by three digits are displayed in full using more than three digits.
Esto que te resalto dice: "El valor mostrado no restringe el rango de valores que pueden ser almacenados en la columna. Tampoco previene que valores mayores de la columna sean mostrados correctamente".
El único uso que tiene ese numero es para que ciertas aplicaciones que sólo tienen un rango dado fijo de salida, puedan recibir la columna "formateada" adecuadamente, pero no representa al dato.
El rango del dato está dado por su tipo de columna. Lo correcto es que un INT UNSIGNED tenga un ancho de salida de 10, cosa que MySQL pone automáticamente si sólo le indicas el tipo de dato, sin ese valor.

Por otro lado, como ciertas funciones de MySQL leen esa definición de ancho para ciertas tareas (generación de vistas, por ejemplo), podría darse que valores mayores sean leídos incorrectamente, dando resultados erróneos en las consultas, porque MySQ "cortaría" el número, descartando parte de su valor.

En síntesis: No los uses. Deja que MySQL ponga el que corresponda.

Sí se usan con los DECIMAL, pero eso es otro caso completamente distinto, y alli sí tiene sentido usarlos.

pues la verdad no lo sabía, si es un error, no me queda otra que reescribir de nuevo todo, porque las fk deben referenciarse a campos iguales, verdad?

[gnzsoloyo]

1- sea como sea, se puede arreglar para que te de el resultado negativo sin dar error?

La consulta en sí no debe dar error (a mi no me lo da probando en MySQL), pero te puede dar error en otros contextos, como INSERT, o SP.
No estoy seguro de cómo haces la prueba, así que sin saberlo no te puedo asegurar donde está el fallo.

2- cómo tendría que hacer para esa validación de stock previa?

Las validaciones no son tema puramente de SQL, sino fundamentalmente de programación; es en el foro de PHP donde vas a ver eso, pero previendo el asunto te comento que más que usar PHP puro, las validaciones en una web se hacen con Ajax, donde parte es JavaScript y parte PHP.
Pero de todos modos toda validación contra datos de una base va a implicar hacer consultas puntuales a la base para verificar cada cosa. Eso será inevitable.
De hecho, en una web, donde las cosas son asíncronas, una operacion de venta tiene varios nivele s de validación, y todo dato se valida al menos tres veces:
1) Cuando el usuario/cliente busca algo.
2) Cuando ese usuario/Cliente confirma algo.
3) Cuando la operación se registra finalmente.

Y no... es inevitable hacer tres veces la validación en tres etapas diferentes, porque siendo la web concurrente (mas de un usuario/cliente al mismo tiempo) siempre existe la posibilidad de que mientras uno esté haciendo la compra, otro ya haya terminado su compra y ya no tengas existencias suficientes para la operación.
¿Se entiende?

Peor como sea, eso tiene que ver con el diseño del sistema, y no sólo con los datos.

pues la verdad no lo sabía, si es un error, no me queda otra que reescribir de nuevo todo, porque las fk deben referenciarse a campos iguales, verdad?

Eso es inevitable... Por eso el diseño de la base debe estar terminado antes de empezar a usarlo productivamente...