Duda sobre ID's

[MikiBroki]

Hola buenas,

Tengo una tabla CONTADORES en la que guardo los nombres de tablas y el ID actual de cada una de ellas.

En primer lugar, cada vez que voy a insertar un registro en una determinada tabla, busco en la tabla CONTADORES el que corresponde a la tabla en la que quiero insertar y con un update incremento su campo 'idActual'.

Después hago una select también sobre CONTADORES para localizar el nuevo 'idActual' para devolverlo y usarlo en el insert.

La duda que tengo es si con este método podría haber algún problema si dos usuarios simultaneamente actualizan el mismo registro de CONTADORES y los dos en la select obtuviesen el mismo ID.

Hace años, en Clipper, se usaba un sistema de bloqueo de registro, pero no he visto cómo hacerlo en MySQL.

Muchas gracias

[quimfv]

Si, las tres consultas que estas haciendo pueden generar problemas de concurrencia si tienes mas de un usuario al mismo tiempo, puesto que son consultas que para el motor son totalmente independientes, debes definirlas como una unica transacción para que se produzcan los bloqueos necesarios.

Busca en el manual el tratamiento de "TRANSACCIONES" solo podràs usarlo en tablas tipo imnodb.

El sistema de ID que usas, es ingenioso, pero tienes el tipo de datos autoincremental que soluciona todo el proceso que para ti son tres consultas (UPDATE, SELECT y INSERT) con una sola (INSERT), en php, no se si es lo que usas, a demas tines la funcion mysql_insert_id() que te dara el id introducido por el ultimo insert... No veo que justificacion puedes tener para una estructura de este tipo... ten en cuenta que tienes los metadatos de la bbdd que tambien te pueden decir el siguiente id de las tabla con id auto incrementales...

Código sql:

SELECT TABLE_NAME, AUTO_INCREMENT
FROM information_schema.TABLES
WHERE table_schema = 'Nombre de bbdd'
 

esto te da el proximo autoinc de todas las tablas de una bbdd

si agregas esto

Código sql:

AND TABLE_NAME = 'Nombre tabla'
 

sabras el de una tabla concreta. Si le restas 1 tendrás el último. Por lo que tu tabla de contadores no tendria sentido, el propio motor ya crea una...

Quim

[MikiBroki]

El caso es que desde que estudié, y posteriormente en las empresas en que he trabajado, me han recomendado siempre las personas con más experiencia en bases de datos que evitase el uso de campos autoincrementales en la medida de lo posible, de hecho, el sistema que comento lo usan desde hace mucho tiempo en una empresa grande, pero a mi no me termina de convencer tampoco

Las transacciones y su uso las conozco, pero sólo afectan a actualizaciones en las tablas, pero si tras ella hago un SELECT para obtener el último id (con mi método) no me siento seguro de que devuelva el insertado por cada usuario independientemente de que otro realice una inserción posterior.

Realmente, el tema de bases de datos no es mi fuerte.

[gnzsoloyo]

siempre las personas con más experiencia en bases de datos que evitase el uso de campos autoincrementales en la medida de lo posible,

Eso es debido a la normalización de las tablas. En la inmensa mayoría de los casos es innecesario usar autoiincrementales, pero no en todos (la 3FN admite su posibilidad ante la inexistencia de determinantes).
En cuanto a las transacciones, el problema está en el ISOLATION LEVEL, que es lo que tienes que manejar para evitar precisamente lectura de datos "fantasma" en las transacciones concurrentes.
Mira esto:
15.10.3. InnoDB y TRANSACTION ISOLATION LEVEL

[MikiBroki]

Muchísimas gracias por la info, y también por el enlace, lo explica de forma un tanto enrevesada para mis conocimientos pero seguiré estudiando el tema por ahí (entiendo que con ello sería posible usar mi método sin problema) Gracias

[MikiBroki]

Bueno creo que he encontrado algo de luz, ejecutando las consultas

SELECT @@global.tx_isolation;
SELECT @@tx_isolation;

... me devuelven 'REPEATABLE-READ' (supongo que se podrá configurar para otro modo), y por lo tanto si según la descripción:

"la consulta ve los cambios realizados exactamente por aquellas transacciones confirmadas antes de ese momento, y no los cambios hechos con posterioridad o por transacciones no confirmadas. La excepción a esto es que la consulta ve los cambios efectuados por la transacción a donde pertenece"

... no tendría problema usando mi método de tabla de CONTADORES, mientras hiciera un UPDATE en dicha tabla y a continuación un SELECT sobre el mismo registro.

Lo que no termino de entender es cuál sería el flujo correcto, pues me parece un poco contradictoria la descripción:

1) BEGIN - UPDATE - COMMIT - SELECT --> "ve los cambios realizados exactamente por aquellas transacciones CONFIRMADAS ANTES de ese momento"
2) BEGIN - UPDATE - SELECT - COMMIT --> La excepción a esto es que la consulta ve los cambios efectuados por la transacción a donde pertenece

[gnzsoloyo]

1) BEGIN - UPDATE - COMMIT - SELECT --> "ve los cambios realizados exactamente por aquellas transacciones CONFIRMADAS ANTES de ese momento"
2) BEGIN - UPDATE - SELECT - COMMIT --> La excepción a esto es que la consulta ve los cambios efectuados por la transacción a donde pertenece

En el primer caso, la transaccion está terminada y confirmada, por lo que los datos están fijos en la tabla.
En el segundo caso, el select devuelve los datos actualizados, pero solamente en el entorno en donde está funcionando la transaccion, es decir, solamente en el proceso que está ejecutando la transacción y son invisibles para el resto de los usuarios, porque los datos no están realmente en la base, ya consolidados.

[MikiBroki]

Muchísimas gracias !!! parece justo lo que necesito entonces !