Guía del caso del metro de París de Ghost in the SQL Data: Resuelve el misterio del viajero

¿Atascado en el caso del metro de París de Ghost in the SQL Data? Esta guía desglosa la lógica de las consultas, las uniones de tablas y el encadenamiento de pistas que necesitas para cerrar el caso.

Por qué el caso del metro de París desconcierta a los nuevos investigadores

El caso del metro de París en Ghost in the SQL Data es donde muchos jugadores se topan por primera vez con un muro. La premisa es sencilla —un incidente sospechoso en la red de transporte de París, un montón de registros de llamadas y una base de datos que contiene la respuesta—, pero el camino de las consultas no es nada obvio. Si llevas veinte minutos mirando la misma tabla preguntándote qué columna es realmente importante, no estás solo. Los informes de la comunidad en los foros de Steam muestran que este caso es uno de los puntos de bloqueo más comentados, junto con los escenarios del Acosador del Hospital y el Robo al Banco de París.

Esta guía del caso del metro de París de Ghost in the SQL Data está hecha para solucionar eso. Recorreremos la mentalidad investigadora que el juego espera, los patrones SQL que realmente funcionan en su motor de consultas limitado y las trampas específicas que llevan a los jugadores a callejones sin salida. Al final, tendrás un proceso repetible que podrás aplicar a todos los casos del juego, no solo a este.

Una nota rápida antes de empezar: el juego usa un dialecto SQL simplificado. La experiencia de los jugadores confirma que funciones como DATEPART, DATEDIFF y EXTRACT no están disponibles, así que el filtrado de fechas y horas debe manejarse con funciones de cadena como SUBSTR o SUBSTRING. Tenlo en cuenta para todo lo que sigue.

Entender la estructura del caso antes de consultar

Todos los casos de Ghost in the SQL Data siguen el mismo esqueleto: un informe te da un gancho narrativo, la base de datos te da evidencia en bruto y el juego comprueba si tu respuesta final coincide con la verdad. El caso del metro de París no es diferente, pero incorpora datos específicos del transporte —nombres de estaciones, números de línea, marcas de tiempo y registros de pasajeros o llamadas—, lo que hace que las relaciones entre tablas sean más importantes que las filas individuales.

Qué te dice realmente el informe

Lee el informe dos veces. El texto narrativo no es ambientación: es una especificación. Te dice:

La ventana del incidente — el rango de tiempo aproximado sobre el que debes filtrar
La restricción de ubicación — qué estación o línea es relevante
El perfil del sospechoso o testigo — los atributos que necesitarás para hacer la coincidencia

Los jugadores que saltan directamente al editor de consultas y empiezan a adivinar suelen ser los que más tiempo pierden. El juego rara vez requiere más que un puñado de cláusulas WHERE para llegar a la solución, según las reseñas de la comunidad, así que la precisión siempre vence al volumen.

Asignar tablas a pistas

Antes de escribir una sola línea, enumera todas las tablas que expone el caso y para qué sirve cada una. Una asignación aproximada se ve así:

Tipo de tabla	Qué contiene	Cómo la usarás
Registro de incidentes / llamadas	Marcas de tiempo, eventos reportados, ubicaciones	Acotar primero la ventana de tiempo
Registros de transporte	Nombres de estaciones, IDs de línea, entradas/salidas	Filtrar a la estación o línea relevante
Registros de personas	Nombres, roles, atributos identificativos	Coincidir con el perfil del sospechoso o testigo
Tabla de referencias cruzadas	Vínculos entre las anteriores	Unir para conectar la evidencia

Si no puedes explicar en una frase por qué existe una tabla, probablemente aún no la necesitas. El caso del metro de París premia acotar, no unirlo todo a la vez.

La guía: lógica de consultas paso a paso

Esta es la secuencia que funciona para este caso en Ghost in the SQL Data. Trátala como un marco de trabajo y no como un script para copiar y pegar: el juego comprueba tu razonamiento, y entender cada paso importa más que memorizar la sintaxis.

Paso 1: Aislar la ventana de tiempo

Empieza extrayendo todos los registros que caen dentro de la ventana del incidente indicada en el informe. Como las funciones de fecha son limitadas, lo más probable es que filtres usando comparación de cadenas sobre una columna de marca de tiempo con formato, o SUBSTR para extraer la parte de la hora.

Enfoque	¿Funciona en el juego?	Notas
`WHERE time_column BETWEEN 'A' AND 'B'`	Normalmente sí	Lo mejor si las marcas de tiempo se guardan en un formato ordenable
`WHERE SUBSTR(time_column, 1, 5) = 'HH:MM'`	Sí	Solución probada por jugadores para las funciones de fecha ausentes
`WHERE EXTRACT(HOUR FROM ...)`	No	No es compatible con el motor del juego
`WHERE DATEPART(...)`	No	No es compatible

La idea clave: filtra primero, une después. Una queja habitual de los jugadores es que el juego ordena implícitamente JOIN antes que WHERE, lo que puede producir resultados intermedios confusos si construyes una unión masiva sobre datos sin filtrar.

Paso 2: Filtrar a la estación o línea

Una vez que tengas el conjunto acotado por tiempo, añade la restricción de ubicación. Aquí es donde las tablas específicas del metro se ganan su lugar. Haz coincidir el nombre de la estación exactamente como aparece en la base de datos: los errores tipográficos y las coincidencias parciales son la causa número uno de conjuntos de resultados vacíos en este caso.

Comprueba la ortografía contra la tabla, no contra el informe
Usa LIKE '%station%' si no estás seguro del formato exacto almacenado
Confirma el número de línea si el caso menciona uno

Paso 3: Unir los registros de personas

Ahora incorpora a las personas. Este es el paso en el que la guía del caso del metro de París se diferencia de otros casos: no buscas un único nombre obvio, buscas una coincidencia de perfil. Espera múltiples candidatos y espera eliminarlos uno a uno.

Etapa de filtrado	Cantidad típica de resultados	Propósito
Solo ventana de tiempo	Decenas de filas	Establecer el alcance del incidente
+ Estación/línea	Un puñado de filas	Acotar a la ubicación
+ Perfil de persona	1–3 candidatos	Identificar al sospechoso
+ Verificación cruzada final	1 fila	Confirmar la respuesta

Los informes de la comunidad señalan que algunos casos (como el Acosador del Hospital) producen múltiples coincidencias plausibles, y los jugadores han cuestionado si la respuesta prevista es siempre la más lógica. El caso del metro de París es generalmente más limpio, pero aun así deberías verificar tu fila final contra los detalles del informe antes de enviarla.

Paso 4: Verificar y enviar

Antes de fijar tu respuesta, ejecuta una consulta final que confirme que tu sospechoso aparece en todas las tablas relevantes. Si tu candidato falta en los registros de transporte pero está presente en el registro de llamadas, probablemente hayas coincidido con la fila equivocada.

Errores comunes que estancan la investigación

La mayoría de los jugadores que se atascan en este caso en Ghost in the SQL Data cometen uno de unos pocos errores predecibles. Aquí está la lista corta, basada en la experiencia de los jugadores y las discusiones del foro:

Error	Síntoma	Solución
Unir antes de filtrar	Conjuntos de resultados enormes, razonamiento lento	Aplica condiciones `WHERE` a cada tabla primero
Usar funciones de fecha no compatibles	Errores de consulta, sin resultados	Cambia a `SUBSTR`/`SUBSTRING`
Filtrar en exceso con `AND`	Cero filas devueltas	Elimina una condición a la vez para encontrar la culpable
Ignorar el rango de tiempo del informe	Sospechoso equivocado identificado	Vuelve a leer el texto del caso para la ventana exacta
Asumir que la primera coincidencia es la correcta	El juego rechaza la respuesta	Verifica el candidato en todas las tablas

La trampa del "filtrado excesivo" merece especial atención. Los jugadores nuevos a menudo apilan cinco condiciones WHERE a la vez, obtienen cero filas y asumen que los datos están rotos. En realidad, una condición suele estar ligeramente mal: una ortografía de estación diferente, una hora desfasada en una hora o un formato de nombre que no coincide. Construye tu consulta de forma incremental y comprueba el conteo de filas en cada etapa.

Cómo encaja este caso en el juego en general

El caso del metro de París es un escenario de mitad del juego, y asume que has interiorizado lo básico del tutorial y de los primeros casos. Las reseñas de Ghost in the SQL Data describen sistemáticamente la dificultad del SQL como "extremadamente básica": un reseñador señaló que terminó la mitad del juego en menos de una hora usando poco más que cláusulas WHERE. Ese es un contexto útil: si estás teniendo dificultades aquí, el problema es casi con certeza la estructura de la consulta, no la sintaxis avanzada.

Caso	Habilidad central evaluada	Dificultad (consenso de jugadores)
Casos del tutorial	`SELECT` básico y filtrado	Muy fácil
Acosador del Hospital	Eliminación en varios pasos, `SUBSTRING`	Moderada
Robo al Banco de París	Reconocimiento de patrones entre registros	Moderada, con quejas de ambigüedad
Metro de París	Filtrado por tiempo/ubicación más uniones	Moderada
Casos posteriores	Lógica combinada, cadenas más largas	Más difícil para principiantes

El juego también es compatible con Workshop, y ya están apareciendo escenarios de la comunidad. Eso significa que las habilidades que desarrollas en el caso del metro de París —filtrado incremental, uniones cuidadosas, verificación entre tablas— se trasladarán directamente al contenido creado por jugadores. Si quieres ver qué está construyendo la comunidad, la página oficial de Ghost in the SQL Data en Steam es el mejor lugar para empezar.

Consejos para resolver más rápido en todos los casos

Unos cuantos hábitos reducirán tu tiempo de resolución en todos los casos, no solo en este:

Escribe tu hipótesis antes de consultar. "El sospechoso entró en la estación entre las 07:00 y las 08:00" es una afirmación comprobable; "déjame mirar por aquí" no lo es.
Comprueba el conteo de filas obsesivamente. Un salto de 3 filas a 300 significa que tu unión está multiplicando registros.
Usa las pistas de error del juego. El juego proporciona retroalimentación de sintaxis, y los principiantes informan que es genuinamente útil para aprender.
No temas a los resultados vacíos. Cero filas es información: te dice que una de tus suposiciones está mal.
Vuelve a leer el informe después de cada respuesta fallida. La pista que se te escapó suele estar a la vista.

Si eres completamente nuevo en SQL, el tutorial de SQL de W3Schools es una referencia gratuita sólida para los patrones de sintaxis que usa el juego, y cubre las funciones de cadena que sustituyen a las funciones de fecha ausentes aquí.

Preguntas frecuentes: Caso del metro de París de Ghost in the SQL Data

¿Por qué no puedo usar EXTRACT o DATEDIFF en el caso del metro de París? El motor SQL del juego no admite esas funciones. Los informes de la comunidad confirman que DATEPART, DATEDIFF y EXTRACT fallan, y los jugadores lo sortean con SUBSTR o SUBSTRING sobre cadenas de marca de tiempo con formato. Construye tus filtros de tiempo en torno a la comparación de cadenas.

¿Cuántas consultas debería llevar el caso del metro de París? La mayoría de los jugadores lo resuelven en tres a cinco consultas si filtran de forma incremental. Si ya pasaste de diez consultas, probablemente estés uniendo demasiado pronto o te falte una restricción del informe. Da un paso atrás, vuelve a leer el texto del caso y reconstruye desde el filtro de tiempo.

Encontré varias personas coincidentes: ¿cuál es la correcta? Verifica cada candidato contra todas las tablas relevantes. La respuesta correcta aparece en todas ellas, mientras que los señuelos suelen aparecer solo en una. Esta guía del caso del metro de París de Ghost in the SQL Data recomienda verificar la fila final antes de enviar, ya que el juego rechazará a un sospechoso plausible pero equivocado.

¿Es el caso del metro de París más difícil que el Acosador del Hospital? El consenso de los jugadores los sitúa en una dificultad similar, pero por razones diferentes. El Acosador del Hospital requiere eliminación en varios pasos y ha recibido quejas por pistas ambiguas, mientras que el caso del metro de París se centra más en el filtrado limpio y las uniones. Si has resuelto uno, el otro debería resultarte familiar.

¿Necesito conocimientos avanzados de SQL para este caso? No. Las reseñas describen sistemáticamente el SQL requerido como básico: principalmente SELECT, WHERE, JOIN y funciones de cadena simples. El desafío es la lógica investigadora, no la sintaxis. Céntrate en acotar tus datos paso a paso y las consultas se mantendrán cortas.

Reflexiones finales

El caso del metro de París es un rompecabezas de filtrado disfrazado de escena del crimen. Una vez que dejas de intentar consultarlo todo a la vez y empiezas a acotar —primero la ventana de tiempo, segundo la ubicación, tercero el perfil de la persona—, la solución aparece rápidamente. Esta guía del caso del metro de París de Ghost in the SQL Data te da el marco; la práctica es tuya.

Mantén tus consultas pequeñas, verifica cada unión y recuerda que el dialecto SQL limitado del juego es una característica, no un error. Las restricciones te obligan a pensar como un investigador en lugar de como un administrador de bases de datos, y eso es exactamente lo que Ghost in the SQL Data está diseñado para enseñar.