Obtener valor id AUTO_INCREMEN.

[llnitoll]

Estoy desarrollando una aplicación (PHP y Mysql) en que los usuarios pueden postear, y por simple seguridad he decidido guardar la ip y timestamp de cada post.

Pero la idea es que sera una tabla muy grande, por lo tanto la optimización es primordial, entonces quiero guardar la ip en un documento de texto, ya que serian datos que en principio no tengo que utilizar, solo desde la parte de administración del sitio por algún reporte.

Entonces yo hago la consulta:
INSERT INTO posts (post_title,post_user_id,post_cont) VALUES('{$title}','{$user_id}','{$p_cont}',')

Y obtengo la ip y el timestamp para añadirlos al txt, pero me interesaría poner también el id que es autoicremen.

Claro que con el titulo del post y el usuario pues ya es algo. El caso es que guardaría la ip de varias acciones, comentarios, mensajes, etc y seria mejor guardar el id si es posible.

Resumen: Como obtengo el id (que es autoincremen) de un insert que acabo de hacer sin realizar una segunda consulta.

Si utilizo LAST_INSERT_ID() seguidamente podría haber un cruce de datos.

[gnzsoloyo]

Pero la idea es que sera una tabla muy grande, por lo tanto la optimización es primordial

¿A qué le llamas "muy grande" en cuanto a tabla?

Y obtengo la ip y el timestamp para añadirlos al txt, pero me interesaría poner también el id que es autoicremen.

Para eso en PHP existe la función mysql_insert_id().

Si utilizo LAST_INSERT_ID() seguidamente podría haber un cruce de datos.

¿Cruce de datos? ¿A qué te refieres?

[llnitoll]

Iniciado por gnzsoloyo

¿A qué le llamas "muy grande" en cuanto a tabla?

Pues no lo se, pero si estoy trabajando en esto es porque tengo la esperanza de que asi sea, varios millones de posts, si ya se que no va a ser asi me dedico a otra cosa, pero almenos la aplicación estara preparada por si cumple espectativas.

Iniciado por gnzsoloyo

Para eso en PHP existe la función mysql_insert_id().

mysql_insert_id() no es lo mismo que LAST_INSERT_ID() ?? o bueno la forma correcta de hacerlo, es decir devuelve el ultimo id intoducido en la tabla?. Si no es asi y devuelve el id de la ultima consulta de ese codigo, ahora ya lo comprendo.

Iniciado por gnzsoloyo

¿Cruce de datos? ¿A qué te refieres?

Me refiero a que hago el insert, y segidamente hago la petición de el ultimo id instertado en la tabla; si entre esos dos instantes otro post se inserta, me va a devolver el que no es.

El caso es que al leer en http://php.net/manual/es/function.mysql-insert-id.php
"Como mysql_insert_id() en la última consulta que ha funcionado, asegúrese de llamar a mysql_insert_id() inmediatamente despues de la consulta que genera el valor."
Crei entender que deves ponerlo inmediatamente despues de la consulta para evitar en lo posible ese cruze de datos con otra peticion que pueda estar realizando otro visitante, pero ahora supongo se refiere simplemente a ponerlo despues ya que devuelve el id de la ultima consulta de esa instancia de codigo que se esta ejecutando y no el ultimo id introducido en la tabla por cualquiera.

[gnzsoloyo]

Crei entender que deves ponerlo inmediatamente despues de la consulta para evitar en lo posible ese cruze de datos con otra peticion que pueda estar realizando otro visitante, pero ahora supongo se refiere simplemente a ponerlo despues ya que devuelve el id de la ultima consulta de esa instancia de codigo que se esta ejecutando y no el ultimo id introducido en la tabla por cualquiera.

Técnicamente esa es la ida, pero siempre hay alguna solución, como usar transacciones, o realizar toda la operación en un procedimiento almacenado (que se ejecutan en la base y en una sola transacción). Las primeras evitan inserciones entremedio y las dejas en espera hasta que se libera todo, además de servir para asegurarse d que todo funcionó bien, y los datos se guardaron bien antes de confirmar todo.
Por otro lado, mysql_insert_id() opera sobre la conexión y recurso devuelto por la ejecución de la consulta de inserción, así que técnicamente debería ser independiente de las nuevas inserciones.
En cuanto a la tabla que mencionas, si el problema es que puede que llegue a millones de registos lo más importante en realidad nos son tanto los IDs que tenga, sino que esté correctamente definida y normalizada. En otras palabras, lo que debes modelar bien en ese caso es la base de datos, y no preocuparte tanto todavía por los IDs, que son asunto procedimental.
Empieza por optimizar la base. Para la aplicación siempre hay tiempo.

[llnitoll]

Iniciado por gnzsoloyo

Por otro lado, mysql_insert_id() opera sobre la conexión y recurso devuelto por la ejecución de la consulta de inserción, así que técnicamente debería ser independiente de las nuevas inserciones.

Usare mysql_insert_id() entonces.

Iniciado por gnzsoloyo

En cuanto a la tabla que mencionas, si el problema es que puede que llegue a millones de registos lo más importante en realidad nos son tanto los IDs que tenga, sino que esté correctamente definida y normalizada. En otras palabras, lo que debes modelar bien en ese caso es la base de datos, y no preocuparte tanto todavía por los IDs, que son asunto procedimental.
Empieza por optimizar la base. Para la aplicación siempre hay tiempo.

Cierto, tendre que dedicar más tiempo a eso, pero en todo caso no me parece mala idea separar las ip desde un principio.

Muchas gracias por tus respuestas.

PD: He estado dandole vueltas a lo que me comentas de la normalización, y quizas es buena idea crear dos tablas, relacionar los campos entre si y a la segunda tabla añadirle los campos ip y timestamp, y realizar las consultas en la primera. No tengo ni idea de como pero ya lo estudiare. Esta formula aumenta el tamaño (respecto a usar la formula del txt) de la DB pero entiendo que la rapidez de las consultas no se verian afectadas, y la inserción del post seria más rapida ya que no tendria que añadir los datos en dos recursos.

[gnzsoloyo]

Exactamente. El sentido de las normalizaciones es ente otras cosas evitar las redundancias y mantener las consistencias. Cuando una tabla está bien normalizada no sólo has tenido que definir bien las PK, sino que además la carga se "aliviana" en cuanto a bytes, porque no tienes valores repetido, por ejemplo.
Este proceso se paga con consultas más compleja, pero también se gana con índices más pequeños, menores cantidades de bloques de lectura por consulta (más rápidas), y estas cosas permiten que el algoritmo planificador de consultas tenga más opciones para generar optimizaciones por sí mismo.
Hay muchas ventajas, pero es un terreno muy teórico para la mayoría. Las explicaciones puedrn sonar confusas.

[gnzsoloyo]

Estaría bueno que nos postearas las estructura (el CREATE TABLE e esa tabla), si quieres alguna sugerencias adicionales de normalización.