El tema que toca esta semana es otro de esos que desata encendidas discusiones en los foros de póquer y en las tertulias entre aficionados. En este caso, solo atañe a los jugadores de póquer online. Se trata, como se puede inferir con facilidad del título del artículo, de los bots de póquer.

Si me he animado a escribir este artículo es por varias razones. En primer lugar, porque para el jugador medio, sin demasiados conocimientos de informática, es una cuestión misteriosa que le plantea enormes dudas. Además, es un tema que se suele tratar y argumentar desde el más absoluto desconocimiento; y, por definición, se teme a lo que no se conoce.

Últimamente, hay un gran número de noticias y alertas de bots que juegan al póquer y que amenazan con hundir el juego por internet o cambiarlo para siempre. Sin ir más lejos, un programador estadounidense llamado James Devlin, que sostiene que ha desarrollado un bot que juega con éxito en varias salas, está desglosando los pormenores de su trabajo en este blog.

Los artículos (en inglés) están muy bien elaborados y explicados. Hay mucha información interesante, tanto para los que tienen conocimientos de programación como para los que no. Se nota que sabe de lo que habla. En estas líneas, y en las que sigan en próximas entregas, voy a tratar de reflejar la realidad de la situación actual. Para ello, ayudándome de los conocimientos propios que tengo como programador, he investigado, resumido y anotado todo aquello que he podido encontrar por la red sobre el particular. Espero que lo que viene a continuación disipe la mayor parte de las dudas que se puedan tener y los lectores se queden más tranquilos (o no).

Antes de continuar, voy a explicar a qué me refiero cuando hablo de bot de póquer. De manera simple, un bot de póquer es un programa informático (o varios) que juegan en una sala de póquer online sin -en principio- necesidad de que una persona esté dirigiendo el proceso. Tan sencillo como arrancar una aplicación de nuestro escritorio y ganar mucho dinero sin mover un dedo. Pero, evidentemente, esto no es tan fácil; se necesitan muchos conocimientos y trabajo duro para conseguir algo que funcione de verdad. Aquí no voy a filosofar sobre otro tipo de trampas tales como colusión, troyanos que permiten ver las cartas de otro jugador, cuentas de superusuario, etc. Eso es otro cantar que considero completamente diferente al caso que nos ocupa.

Volviendo a los bots de póquer, podemos encontrar varios disponibles en la red a cambio de una cantidad económica (o incluso gratuitos). Seguro que os suenan nombres como WinHoldEm, ICMBot, etc. Se supone que son capaces de ganar en límites bajos (alguno es programable mediante ciertas reglas escritas por nosotros) y son indetectables. No los he probado, ni pienso hacerlo. No solo porque pudieran cerrarme la cuenta si soy descubierto, sino además, entre otras cosas, porque no me fiaría ni un pelo de instalar una aplicación que podría estar espiando todos mis datos como contraseñas de salas de póquer. Luego profundizaré más sobre estos bots comerciales.

Para tener todo controlado es mejor hacerlo uno mismo pero, tal y como dije anteriormente, eso no es una tarea sencilla. Los requisitos para desarrollar un bot son cuantiosos y muy especializados. Para empezar, es necesario haber estudiado programación, conocer y haber trabajado durante un tiempo sobre el lenguaje escogido para la aplicación, tener ciertas habilidades sobre técnicas de hacking y manejar las interioridades del sistema operativo. Además, seguro que el trabajo lleva implícitas muchas lecturas de libros y artículos, búsquedas por la red, cientos y cientos de horas de desarrollo, infinitas pruebas…

La ventaja es que toda la información imprescindible para elaborar un bot se encuentra disponible para quien le interese. Incluso hay un proyecto de código abierto (que se puede descargar, modificar y usar), basado en WinHoldEm que es un buen punto de partida para quien quiera empezar a desarrollar su propio bot: OpenHoldEmBot. En realidad, no hace falta ser un hacha para codificar la mayoría de tareas que debe realizar el programa. Eso sí, son laboriosas y requieren de mucho tiempo y paciencia. La parte más complicada es la que tiene que decidir las acciones a realizar, es decir, la inteligencia artificial.

Por si esto fuera poco, también es preciso ser un buen jugador de póquer. No solo eso, sino además, tener un conocimiento matemático del juego para poder enseñar al bot a jugar o a “aprender a jugar”. Porque, al igual que ocurre con muchos profesores que, a pesar de ser unas eminencias en su campo, no logran transmitir con eficiencia los conceptos a sus alumnos, no es lo mismo saber de una cosa que tener facilidad para explicarla. Es imprescindible saber estadística, probabilidad, estrategia…

Si, como se puede comprobar a simple vista, es necesario tanto esfuerzo y conocimiento, ¿por qué alguien va a querer desarrollar un bot de póquer? La respuesta obvia e inmediata es la que hace girar el mundo: dinero. La industria del juego mueve unas sumas mareantes y están a solo unos clics de ratón de un programador inteligente que reúna las características necesarias.

Un bot que ni gane ni pierda en las mesas de juego, simplemente con los programas de rakeback o similares ofrecidos por las salas, supone muchos miles de dólares al año. Multiplicado por varias cuentas y salas, resulta en más dinero del que la mayoría de personas pueden lograr en toda su vida. Estímulo más que suficiente como para dedicarle parte de nuestro tiempo. Pero ése no es para muchos el más importante. Porque, como parece ser el sentimiento generalizado de varios desarrolladores, la mayoría de bots caseros son perdedores.

Perdonad que me ponga por un momento en la piel de un desarrollador de un bot de póquer; lo que pretendo conseguir es que se entienda su punto de vista (es más, la mayoría de ellos, jugar con un bot no lo ven como hacer trampas). La perspectiva de ganar mucho dinero es tentadora para todo el mundo, incluido el programador. Pero lo que hace a la idea realmente llamativa para él es ser capaz de lograr que su creación sea capaz de ganar al resto de jugadores, humanos o no. Lo encuentra algo fascinante, es su pasatiempo, su reto. Conseguir al mismo tiempo burlar la seguridad de las salas y la habilidad de los rivales. Al final, para muchos, que sea ganador es lo de menos. Con el desarrollo de la aplicación han conseguido unir y perfeccionar dos actividades que son muy lucrativas: póquer y programación. No es tiempo perdido ni mucho menos.

El principal problema de los bots comerciales se da el día que se logra detectar a uno de ellos; en cuanto quiera la sala de póquer podría congelar las cuentas de todos los que usan ese programa, y dejar a los usuarios sin su fuente de ingresos. Por eso, aunque costoso, es mucho mejor desarrollarlo de manera privada. La discreción es una de las claves de un bot exitoso. Porque, que no os quepa ninguna duda, los bots son reales y están jugando en las salas. Otra cosa es si deberíamos temerles y si a las casas les interesa detectarlos. Pero eso, para la próxima semana.

El problema de la beta actual es que no posee un HUD para visualizar los datos de los rivales mientras se juega; y parece que van a tardar aún un tiempo en sacarlo (quizás a mitad de Febrero de 2008). Mientras tanto, se puede usar un script de Autohotkey creado por _dave_. Para ello, es necesario registrarse en la página de PT3 y descargarlo del hilo especialmente creado en los foros de PT3.

De momento, solo funciona en PS, pero va a incorporar FTP y Party en breve. Es necesario seguir una serie de pasos para poder usarlo:
1. Tener instalado Autohotkey. Tener instalado PT3 y una base de datos de este programa.
2. Descargar pt3_hud_v0.1.zip. Extraer los ficheros a un directorio.
3. Copiar y pegar en el directorio anterior el archivo psql.exe y todos los .dll de “C:\Archivos de programa\PostgreSQL\8.x\bin“.
4. Editar “stats.ahk” y cambiar la configuración.
5. Ejecutar el archivo “pt3_hud_v01.ahk“. Sentarse en una mesa de PS y recibir una mano. En cuanto se complete la primera mano, las estadísticas deberían aparecer.
6. Colocar los paneles con el botón izquierdo del ratón. La posición se recordará para las próximas veces.

Configuración

Para configurar el programa hay que modificar el archivo “stats.ahk“:

pt3_database_name := “PT3NL100″

Nombre de la base de datos de PT3 de donde queremos sacar las estadísticas.

pt3_database_host := “localhost”

Servidor donde se encuentra PostgreSQL (por defecto será localhost).

show_player_name := 0

Si queremos que muestre el nombre del jugador en los datos poner un 1.

ignore_hero := 1

Si queremos que no aparezcan nuestros datos poner un 1.

El resto de entradas anteriores sirven para configurar una serie de datos como tipo de letra, color de fondo del panel, tasa de refresco de los datos, etc.

A partir de: “; Define stats here as SQL “SELECT” statements” se definen las estadísticas que van a aparecer en el HUD. Son consultas SQL a la base de datos de PT3 (quien quiera más información sobre el esquema de la base de datos para poder hacer las consultas, la tiene en la parte de documentación de la web de PT3). Se pueden añadir nuevas a las ya existentes (de hecho, en el hilo del script la gente ya ha mandado algunas).

statlist := “hands/*vpip,pfr*3bet/,fold3pf/call3pf/raise3pf”

La última línea es la que define los datos a aparecer en el HUD (si hay 3 de statlist es porque 2 son de ejemplo, las líneas que empiezan por “;” no se procesan, son comentarios). Es una lista de estadísticas separadas por comas (definidas en las sentencias SQL de más arriba); una coma indica una nueva estadística en el mismo panel, una barra (/) una nueva línea y un asterisco (*) en lugar de una coma, señala que se debe comenzar un nuevo panel.

En el ejemplo de arriba, tenemos un panel con el número de manos, otro con el vpip y el pfr en la misma línea, y un último con cuatro estadísticas, cada una en una línea.

Una imagen con el aspecto final de la aplicación:

En este artículo voy a describir el uso de una serie de herramientas que pueden ser de gran ayuda para todos aquellos que jueguen a póquer simultáneamente en varias mesas. En realidad, se trata de varios programitas (o scripts en inglés) que se ejecutan con una aplicación llamada AutoHokey.

Lo primero, y si no se tiene instalado ya, es ir a la página http://www.autohotkey.com/, ir a la sección de descargas, bajarse el archivo AutoHotkeyInstall.exe e instalarlo en el ordenador. A partir de aquí, se podrán usar todos los programas escritos para esta aplicación. Hay muchos y para muy diversos usos, principalmente para agilizar las tareas cotidianas creando atajos de teclado, pero eso es otra historia; el que quiera más información, tiene para aburrirse en la página anteriormente comentada. Yo me voy a limitar a hablar sobre los programas realizados sobre esta herramienta para jugar a póquer, que es que seguro por lo que estáis leyendo esto.

Los programas que se pueden correr sobre AutoHokey son ficheros de texto con la extensión .ahk. Para ejecutar uno de ellos, bastará con hacer doble clic sobre el mismo y tener instalado el AutoHokey en el ordenador. Los programas que nos interesan están en la página http://www.overcards.com/wiki/moin.cgi/AutoHotKey. En ella se puede ver un listado con todos los disponibles. Son totalmente gratuitos, aunque la mayoría solo sirven para unas salas muy concretas. Normalmente para Poker Stars (PS), Party Poker (PP) o Full Tilt Poker (FT).

En los siguientes apartados, explicaré los programas que utilizo normalmente para jugar. Éstos son Stars Planner, Table Highlighter y Stars Notes. Por si no os habíais percatado, juego en PS, pero algunos sirven también para otras salas o tienen su equivalente en la página antes citada. Otros programas interesantes son el Bet Pot (para manejar el tamaño de apuesta en NL con atajos de teclado o la ruleta del ratón), Stars Auto Reloader (carga el buy in completo automáticamente), Stars Buddy List (para buscar a los pardillos), Big Pot Grabber (almacena los botes grandes que se suceden en nuestras mesas para poder revisarlos), etc. Yo no utilizo Bet Pot porque me resulta cómoda la manera de seleccionar la apuesta en PS y porque así me obligo a pensar más que si tuviera automatizada la acción, pero creo que es bastante útil si se juega 12 mesas. Echadle un ojo a la página porque seguro que encontráis alguno más que os pueda interesar.

A modo de resumen, voy a enumerar los pasos necesarios para utilizar un programa para AutoHotkey (traducido de la página donde están listados):

1. Bajar e instalar Autohotkey.

2. Hacer clic con el botón derecho del ratón en el directorio donde se quiera guardar el programa y elegir Nuevo->AutoHotkey Script. Renombrar ese archivo “New AutoHotkey Script.ahk” a “El nombre que quieras.ahk“. ¡No olvidar el “.ahk“!

3. Hacer clic con el botón derecho del ratón sobre el archivo creado y elegir Edit Script.

4.Pegar el programa seleccionado (el código del programa está en la página del mismo), guardar y cerrar.

5. Para hacerlo funcionar, hacer doble clic sobre el archivo.

Nota: normalmente para que funcionen correctamente es preciso cambiar algunos parámetros de configuración. Las instrucciones estarán detalladas en la página del programa.

Stars Planner

Sin duda el programa más útil para PS. Con él se pueden controlar varios aspectos de la aplicación de PS. También se puede usar en PP, FT y Absolute. Cuando se ejecuta, aparece una ventana de configuración:

Si se marca Enable Keep Lobby, se mostrará siempre la pantalla principal de la aplicación de la sala de póquer (donde se eligen las mesas, el cajero, etc.), y no dejará minimizarla.

Si se marca Enable Automatic Buy In when seated, cada vez que nos sentemos en una nueva mesa nos cargará automáticamente el buy in completo.

Si se marca Dismiss Open-fold “Are you sure”?, no nos mostrará la pregunta de si estamos seguros de hacer fold y lo hará automáticamente (creo).

Si se marca Sit Out on all tables (untick to return), nos pondrá sit out en todas las mesas hasta que lo deseleccionemos.

Si se marca Enable Re-Size and Arrange Tables, nos colocará las mesas con el tamaño, orden y posición que hayamos configurado previamente. Para ello es necesario seguir una serie de pasos:

1. Abrir el número de mesas que queramos configurar y colocarlas como prefiramos.

2. Pulsar el botón Capture de Stars Planner y elegir un nombre para esta configuración (por ejemplo, 12 mesas 2 monitores).

3. Debería aparecer una ventanita con un mensaje similar a: “Found 12 Pokestars tables” (Encontradas 12 mesas de PokerStars).

4. Cerrar las mesas, no se necesita tenerlas abiertas.

5. Pulsar el botón Configure de Stars Planner y colocar las mesas en el orden en el que queramos que se vayan abriendo (lo harán siguiendo el orden numérico). Es un poco complicado colocarlas porque se mueven a otras posiciones y nos desbarajustan todo. Hay que tener un poco de paciencia y pillarle el tranquillo.

6. Una vez que estemos contentos con la configuración, pulsar el botón Save de Stars Planner.

7. Marcar Enable Re-Size and Arrange Tables para que las mesas se recoloquen con el tamaño adecuado.

Nota: para que en PS el programa vaya más rápido, es necesario añadir la línea:

f5redrawtable=1

en la sección [Options] del archivo “User.Ini” del directorio de PokerStars (normalmente “C:\Archivos de programa\PokerStars”).

Table Highlighter

Otra aplicación muy útil cuando se juega en varias mesas. Básicamente, resalta la mesa en la que nos llegue el turno de actuar. Tiene varios parámetros que sirven para configurar diversos aspectos del programa, están en la parte de configuración del archivo:

;###### Configuration ######

AQ_Ex = 1 ; poner a 0 para ignorar los botones de acción anticipada.

timeBeep = 0 ; pita una vez si te quedan menos de x segundos para actuar. 0 no pita.

timeContBeep = 0 ; beep – beep – beep – beep …

timeFlash = 1 ; parpadea la ventana en lugar del pitido (se pueden tener ambos).

shiftColors = 0 ; poner a 1 para cambiar a un rango de colores según el tiempo que quede.

style = Bar ; donde se resalta. Opciones: “Barra”, “BarraDeAbajo”, o “Chat”.

barX = 3 ; solo se aplica al estilo “BarraDeAbajo”.

barY = 550 ; son dinámicos (como el dúo). Configurarlos en una mesa de tamaño

barW = 790 ; normal, y después usarlos con cualquier tamaño de mesa

barH = 25 ;

roundCorners = 0 ; poner a 1 si se quieren esquinas redondeadas en la Barra Superior.

skipUnderMouse = 0 ; poner a 1 si cuando se pase el ratón la ventana no debe resaltar.

skipUnderMouseTitle = 0 ; igual pero solo cuando pase el ratón por el título de la ventana.

buttonFlash = 0 ; poner a 1 para que parpadee la barra si los botones anticipados se muestran.

barTopH = 0 ; establecer la altura de la Barra Superior. 0 para usar la por defecto.

barTopY = 0 ; poner la coordenada Y donde la Barra Superior debe situarse.

activate_on_mouse_over = 0 ; poner 1 para activar la tabla si se pasa el ratón y está resaltada.

flash_speed = 2 ; velocidad del parpadeo (1=rápida, 2=media, 3=lenta, etc.)

active_windows_only = 0 ; poner a 1 para que solo funcione en la mesa activa.

activate_waiting_table = 0 ; poner a 1 para hacer que una mesa en espera pase a activa.

;###### Configuration – End ######

Nota: este programa requiere de las funciones de Roland para funcionar. Para ello, ir a http://www.overcards.com/wiki/moin.cgi/RolandsFunctions , descargarse los dos archivos que aparecen y guardarlos en el mismo directorio que tengamos los programas.

Star Notes

Este programa solo funciona en PS. Sirve para mostrar las notas que tenemos de los jugadores sin tener que abrir la sección de Notes de la ventana de juego. Cuando estemos jugando en una mesa y pasemos el ratón sobre un jugador del que tenemos notas, aparecerá un cuadro con las mismas.

Para que funcione, hay que configurarlo. Cuando se ejecuta, aparece la ventana:

En Hand history directory hay que poner el directorio donde guarda PS las manos (normalmente C:\Archivos de programa\PokerStars\HandHistory\Nuestro nick en la sala).

En Notes file el archivo donde guarda PS las notas que escribimos (normalmente C:\Archivos de programa\PokerStars\Notes.txt).

Y después, si usamos el sitio preferido configurarlo.

Una vez hecho esto, pulsar el botón Submit. El resto de ocasiones que iniciemos el programa, bastará con pulsar Cancel puesto que la configuración ya estará almacenada.

Nota: este programa requiere de las funciones de Roland para funcionar.

Esto es todo por ahora, espero que os sirva.

Voluntarily Put Money Into the Pot – VPIP(Dinero puesto voluntariamente en el bote): el indicador fundamental de lo selectivo que es un jugador antes del flop, y uno de los mejores indicios sobre el rango de manos de un jugador. En microlímites quieres que el VPIP de los rivales sea lo mayor posible. Cuantas más manos jueguen, peores serán y más dinero les ganarás. El rango normal para un TAG en microlímites se sitúa entre un 14% y un 20% (más sobre esto en siguientes artículos).

Preflop Raise – PFR (Subida antes del flop): el porcentaje de las veces que un rival sube antes del flop. Este número indica cómo ajustarse al rival antes del flop. En primer lugar, si es extremadamente bajo no hay que preocuparse de que el oponente suba con una mano especulativa. Si el jugador situado a tu izquierda tiene un PFR mínimo, puedes ver con manos muy especulativas y esperar llegar barato al flop, dándote maravillosas odds implícitas. Aprovéchate de ello. Sin embargo, si un jugador con un PFR del 2% sube antes del flop, puedes tirar la mayoría de manos especulativas sin preocuparte (NOTA: si te vas a quedar solo contra un rival con el stack completo cuyo PFR es menor del 4% y ha subido 4ó 5 BB, puedes ver tranquilamente con cualquier pareja solo por las odds implícitas, porque si ligas el trío, te llevarás el stack del contrario con mucha frecuencia. Su bajísimo PFR delata sus posibles manos, y la mayoría de estos jugadores comprometerán su stack entero en una mano que es lo suficientemente buena como para convencerles de subir antes del flop). El rango normal de un TAG en microlímites se sitúa entre un 7% y un 10% (más sobre esto en siguientes artículos).

Total Aggression – TA (Agresividad Total): el mejor indicador de lo agresivo que es un rival después del flop. Antes y después del flop son dos situaciones diferentes, y no hay que esperar que un oponente se comporte igual (de pasivo o agresivo) en ambas. Hay jugadores que son muy agresivos antes del flop pero se convierten en calling stations después del flop, y al contrario, limpers recalcitrantes antes del flop que se transforman en psicópatas descontrolados después del flop si ligan una mano. Si ves un rival con una agresividad extremadamente grande, probablemente tengas que jugar pasivo ante él si tienes una mano aceptablemente buena, dejando que apueste por ti. OJO: jugadores con una agresividad muy alta se dividen fundamentalmente en dos tipos: los megaselectivos débiles y los maniacos. Los primeros son jugadores cuya agresividad es alta porque se tiran cuando algún otro apuesta y él no tiene la mejor mano. Los segundos son aquellos que tienen una agresividad alta porque apuestan y suben con cualquier mano. Si sabes distinguirlos, harás mucho más dinero (Indicio: fíjate en los tipos de mano que muestran al final. Si llegan al showdown pocas veces y con una gran mano, seguramente sean megaselectivos débiles. Si pierden la mayoría de las manos en el showdown, con gran probabilidad serán maniacos). El rango normal para un TAG en microlímites se sitúa entre un 2 y un 3 (más sobre esto en siguientes artículos).

Después de la trinidad, las estadísticas que uso en mi HUD:

Folds to Continuation Bet (Porcentaje que se tira ante una apuesta de continuación): probablemente la siguiente estadística más útil tras las tres primeras y una en la que confío plenamente a la hora de tomar decisiones. Cuanto más se tira un jugador ante una apuesta de continuación, más propenso soy a (a) subir antes del flop con ellos en la mano y (b) apostarles cuando no ligo en el flop. No veo ninguna razón para apostar cuando alguien no se va a tirar; en lugar de eso, esperaré a tener una mano legítima y machacar al contrario. Por otra parte, si un rival se tira tras una apuesta de continuación el 60% del tiempo o más, usaré mi posición sin piedad, subiéndole con mucha frecuencia y robando bote tras bote en el flop con una apuesta fuerte.

Continuation Bet – CB (Porcentaje de apuesta de continuación): un dato que puede ayudar a tomar decisiones en la primera calle. Indica la frecuencia con la que el rival apuesta en el flop tras haber subido preflop. Si tiene menos del 65% solo apostará normalmente cuando haya ligado su mano o cuando la situación parezca favorable (p.e.: estar HU con posición y un flop sin peligro aparente ante un pasivo). Un rival fácil de leer normalmente, pero atención al slowplay con cañones que se puede confundir con debilidad y cuidado también con intentar farolearle si tiene un WTSD alto y es capaz de ver con cualquier cosa mejor que un farol; entre el 65% y el 85% apostará la mayoría de situaciones que pudieran parecer favorables y evitará los flop peligrosos (con muchos proyectos o ante varios rivales sin una mano lo suficientemente fuerte); a partir de 85% apostará prácticamente siempre aunque no haya ligado, se convierte en un blanco propicio para subirle de vez en cuando y tirarle de la mano.

Raise Flop – RF (Subida en el flop): un indicador de la fuerza de las subidas del rival en el flop, ayuda a decidir si abandonar la mano. Un valor menor de 10 suele pertenecer a un jugador que solo sube sus manos más fuertes; entre 10 y 12 subirá manos hechas (a partir de TP) y proyectos muy fuertes; un número mayor de 12 indica que al rival le gusta meter presión y subir con todo tipo de proyectos (cuanto mayor este valor, más posibilidades de subida de farol).

Attempted to Steal the Blinds (Porcentaje de intento de robar las ciegas): muy útil a la hora de ver si un rival tiene en cuenta la posición. Desde CO y B, trato este número como el PFR del jugador en esas posiciones, y ajusto mi juego en consonancia. Además, si el porcentaje de robo es significativamente más grande que su PFR, asumo que el rival tiene algo más que simples nociones sobre cómo jugar a esto y le tengo algo más de respeto cuando me enfrento a él. También pienso que tengo bastante más folding equity contra ellos en general, porque los jugadores decentes son poco propensos a comportarse como calling stations y mucho más capaces de tirar una mano decente pero superable.

Folded Big/Small Blind to a Steal (Porcentaje de abandono en SB/BB ante un intento de robo): otro indicador básico de la fuerza de una mano. Si el rival se tira constantemente ante intentos de robo, sé que cuando vea desde las ciegas, tendrá una mano decente. Si suele defender las ciegas, asumo que puede tener cualquier cosa incluso aunque vea una subida considerable. Combinado con el porcentaje de abandono ante una apuesta de continuación en el flop, tengo una idea bastante aproximada de si robar contra ese oponente va a ser rentable o no.

Went to Showdown Percentage – WTSD – WSD% (Porcentaje de ida al Showdown): cuanto mayor sea este número, más calling stantion será el rival. No hay un número mágico que indique si será rentable o no jugar contra determinado oponente; por contra, me indica cómo debería ajustar mi juego ante el villano. Frente a un jugador con un WSD% muy bajo, apuesto por valor mucho menos a menudo y faroleo con mayor frecuencia.

Won Money At Showdown – W$SD (Dinero ganado en el Showdown): otra estadística bastante útil. Es una medida aproximada de la habilidad después del flop de un jugador. Cuanto mayor sea este número, más probable es que el villano tenga la mejor mano en el showdown. Me ayuda a decidir con qué frecuencia puedo apostar por valor a un rival o ver sus apuestas. De igual forma, me ayuda a distinguir entre buenos y malos LAG (Loose-Agresive), nits (roca, jugador de manual) de TAG (Tight-Aggresive), y maniacos de jugadores agresivos pero listos. Si el W$SD de un oponente es extremadamente alto, lo considero débil y le faroleo con frecuencia. También ajusto el tamaño de mis apuestas, sabiendo que no me costará mucho sacar al villano de la mano. Si por el contrario, el W$SD del rival es extremadamente bajo, apostaré con valor con cualquier mano que haya ligado, esperando que me vea la apuesta frecuentemente. Además, aumento el tamaño de mis apuestas por valor, con la esperanza de ser visto aunque muestre bastante fuerza.

Total Hands – TA (Manos totales): un número increíblemente importante. Indica el grado de confianza que puedes tener en el resto de números que muestra el HUD. Sobre unas 50, el VPIP y el PFR empiezan a ser significativos. Sobre 10.000/VPIP, puedes empezar a hacer caso a la agresividad total (p.e.: 200 manos para un jugador con un VPIP de 50, pero 500 para otro con un VPIP de 20). El W$SD no se ajusta realmente hasta varios miles de manos, así que trátalo de modo orientativo si no tienes esa cantidad; sin embargo, el WSD% adquiere valores confiables mucho antes.

Además de las estadísticas de los rivales, tengo configurado el HUD para que muestre las mías también. El programa las almacena de forma independiente en cada mesa que juguemos; así, podemos de un vistazo comprobar cómo estamos jugando en una mesa determinada, lo que nos ayudará a identificar nuestra imagen en la mesa contra un conjunto específico de rivales. Cuando mi VPIP es grande, sé que parezco un mal jugador. Cuando mi PFR es grande, sé que mis subidas antes del flop no van a ser demasiado respetadas. Cuando mi TA es grande, sé que parezco un forero de 2+2. Cuando mis intentos de robos son frecuentes, sé que empiezo a perder folding equity y debo jugar con mayor prudencia. Si estoy tirándome demasiado ante una apuesta de continuación, sé que algunos jugadores pueden empezar a hacerme movimientos en el flop. Tener en cuenta todos estos números, permite ajustarme adecuadamente a las condiciones siempre cambiantes de la mesa. Be water, my friend.

El último detalle que siempre tengo configurado en mi HUD es la información del showdown. Mostrando las cartas de la mesa y de cada rival me ahorra tener que abrir el historial de manos constantemente para ver qué tenían. Me ayuda a juzgar cómo están jugando, información de vital importancia para cualquier jugador ganador.

Una última cosa: en las ventanas emergentes (pop-up) del HUD tengo cualquier dato que se pueda mostrar. Así, si un jugador hace un movimiento infrecuentemente fuerte, tengo acceso instantáneo a cualquier estadística que pudiera necesitar. ¿Con qué frecuencia pasa en falso en el turn? ¿Con qué frecuencia ve una subida antes del flop? ¿Con qué frecuencia sube las apuestas de continuación? ¿Con qué frecuencia gana cuando ve un flop? Nunca se sabe cuándo un detalle de éstos puede acabar salvando tu stack, y como no cuesta nada tener esa información incluida, deberías configurarlo y poder acceder a ella.

Antes de empezar, dos advertencias:

1. Esta guía es para sistemas operativos del maligno, es decir, Windows. Pero para que funcione PostgreSQL debe ser un sistema operativo NT, es decir, a partir de Windows 2000; no, Windows 98 no vale ni Windows ME tampoco; y sí, Windows XP vale.
2. Nuestro sistema de archivos no deberá ser ni FAT ni FAT32. Para ver qué sistema está instalado en la unidad en la que se va a instalar PostgreSQL basta con hacer doble clic sobre “Mi PC” y pulsar con el ratón derecho y elegir “Propiedades” sobre la unidad elegida (normalmente lo instalaremos en la unidad “C:”), tal y como se muestra en la imagen:
   
   
3. Se mostrará una ventana en la que si aparece “Sistema de archivos: NTFS” se podrá instalar, pero si es “FAT” o “FAT32”, no funcionará (aunque se puede convertir si sigues los pasos indicados aquí -en guiri y no me responsabilizo de lo que pueda pasar-).

Instalación de PostgreSQL

El primer paso para usar PostgreSQL en Poker Tracker es instalarlo en nuestro ordenador; para ello hay que ir a su página web y pulsar en el enlace de descarga “Download PostgreSQL 8.2.3” que aparece en la página principal (la última versión para la que se escribe este artículo a día 09-03-2007 es la 8.2.3, las siguientes supongo que serán muy similares). Una vez pulsado, nos llevará a la sección “FTP Browser”, donde se ven una serie de carpetas; si vamos a instalarla en plataforma Windows, pulsamos en la carpeta que pone “Win32“. Aparecerán una serie de archivos, pulsamos sobre el que tiene solo la extensión zip (“postgresql-8.2.3-1.zip” es la última versión disponible) que contendrá el instalador para Windows. Seguidamente nos muestran una pantalla con muchas banderitas; no es para elegir la que más nos guste ni nuestra selección favorita (ni siquiera el lenguaje de la aplicación), sino para seleccionar desde qué servidor queremos descargar el archivo, lógicamente pulsaremos sobre el que más cerca nos pille. Una vez pulsado el país, nos mostrará una ventana de descarga de archivos y elegimos guardar (se iniciará la descarga y se guardará en el directorio que tengamos especificado por defecto para las descargas con el navegador que estemos usando).

Una vez tenemos el archivo zip en nuestro disco duro cuando ha acabado la descarga, lo abrimos haciendo doble clic sobre él. Cuando se abra Winzip, pulsamos sobre “Extract”, mostrará una ventana para seleccionar donde guardar esos archivos. Seleccionamos “All files” y el directorio donde queremos descomprimir el instalador (da igual donde lo hagamos, luego borraremos estos archivos de instalación). Una vez descomprimidos, ejecutamos el archivo “postgresql-8.2.msi” que lanzará la instalación de PostgreSQL.

Aparecerá esta ventana:

Seleccionamos el idioma en el que queramos tener la aplicación y pulsamos “Start >”. Después “Next >” hasta que nos muestre la siguiente pantalla:

Dejamos todo como está por defecto y pulsamos “Next >”

Nos muestra la pantalla de configuración de la cuenta que ejecutará el servidor de la base de datos de PostgreSQL. Lo único que debemos hacer es escribir una contraseña cualquiera (pero apúntatela para que no se te olvide o pon una facilita) en “Account password” y escribirla de nuevo para comprobar que la hemos escrito bien en “Verify password”. Una vez acabado esto, pulsamos “Next >”, nos pregunta si queremos crear la cuenta y respondemos que “Sí”, después es probable que nos diga que nuestra contraseña es débil y nos pregunte si queremos que nos la cambie por una aleatoria generada por él, tenemos que decir que “No”. Entonces aparecerá esta pantalla:

De nuevo escribimos una contraseña en “Password” y otra vez la misma en “Password (again)”. Puede ser la misma que hemos utilizado anteriormente, en este caso será para el usuario dentro de la base de datos y el que tendremos que poner en el PT, así que no la pierdas. Pulsamos “Next >”, y en la siguiente pantalla “Enable procedural languages” dejamos todo por defecto y otra vez “Next >”. Nos muestra la pantalla “Enable contrib modules” donde se pueden seleccionar módulos adicionales con funcionalidad añadida a la que viene por defecto. Dejamos todo como está (se podrán añadir después de la instalación si se necesitaran) y pulsamos “Next >”. Aparece la pantalla de “Ready to install”, eso quiere decir que ya estamos casi, pulsamos “Next >” y comenzará la instalación. Cuando acabe nos muestra una pantalla en la que nos dice que se ha instalado con éxito y para concluir debemos pulsar “Finish”. Ya tenemos instalado PostgreSQL en nuestro ordenador.

Uso de PostgreSQL en Poker Tracker

Ahora debemos configurar PT para usar esta base de datos; con este objetivo, seleccionamos del menú “Utilities->PostgreSQL Settings…”, apareciendo esta ventana, donde debemos escribir el usuario que viene por defecto en la instalación “postgres” (si no lo cambiamos en la instalación) y la contraseña que pusimos para el usuario, es decir, la segunda vez que nos pidieron en la instalación que escribiéramos una:

Ahora solo falta convertir nuestra base de datos Access a PostgreSQL mediante la función del menú de PT

“Utilities->Convert Database…” y elegir la que queramos convertir (puede tardar muuuuuucho tiempo dependiendo del tamaño de la base de datos, paciencia y no cerréis antes de acabar aunque parezca que se ha colgado).

Una vez convertida a PostgreSQL, vamos a establecer ésta como la base de datos por defecto cada vez que arranque PT. Para ello, seleccionamos “File->Maintain Database names…” y marcamos la base de datos convertida en la columna “Dflt”.

Si se desea, también se puede borrar desde esta ventana la base de datos Access antigua, aunque siempre la podemos guardar como backup.

Configuración del PokerAce Hud

Ahora, es preciso cambiar la configuración del PokerAce Hud para seleccionar la base de datos de la que queremos que coja la información. Para ello, en “Options->Preferences->Database->Holdem” o en “Options->Preferences->Database->Omaha” simplemente se marca la base de datos escogida de entre las que aparezcan:

Esto es todo, espero que os sirva.

En el primero de la serie, explicaba simplemente cómo hacer una consulta SQL en Access; y en el segundo, la estructura de la base de datos de PT para saber la forma en la que almacena la información y cómo se divide ésta en las diferentes tablas y campos. En esta tercera y última parte, se comprenderán muchas cosas que en los anteriores podían resultar confusas. Lo intentaré hacer despacito, como le gusta a las mujeres.

Si no has estado despistado, sabrás que el lenguaje con el que se hacen las consultas se llama SQL. No es más que una serie de instrucciones que sabe interpretar el motor de la base de datos y que se emplea para manipular la información contenida en ella. En este breve tutorial voy a centrarme exclusivamente en las órdenes de consulta, es decir, en la recuperación de datos.

Hay una serie de palabras que conforman el lenguaje SQL y que equivalen a instrucciones sobre la base de datos. Para hacer una consulta, se utiliza la palabra SELECT (del inglés, seleccionar). La estructura de una consulta SQL es la siguiente:

SELECT (lo que se quiera seleccionar de la BD)
FROM (la tabla o tablas donde se encuentran los datos que se quieren seleccionar)
WHERE (las condiciones que tienen que cumplir los datos que se quieren seleccionar)

La parte del SELECT es la de selección. A continuación se debe indicar lo que se desea recuperar de la base de datos. Básicamente se ponen los campos de la tabla (cuyo nombre pondremos a continuación en la parte FROM) que se quieren recuperar separados por comas (supongo que te acordarás que las tablas se dividen en campos que contienen la información del tipo con el que se haya creado ese campo); otra opción es poner “*” que significa que queremos recuperar todos los campos.

La parte del FROM es la de origen. Se escribe el nombre de la tabla donde se encuentran esos campos que queremos recuperar. La parte del WHERE es la de condición. Es opcional (no es necesario que aparezca) y funciona mediante expresiones aritméticas o booleanas que condicionan la selección.

Con un ejemplo sencillo se verá todo más claro. Poco a poco iré explicando detalles más complicados.

Voy a obtener todos los campos de la tabla game_level:

SELECT *
FROM game_level

Así de fácil. Esta consulta mostrará todos los campos de la tabla (la explicación del significado de las tablas y los campos que las componen están en el segundo artículo de la serie). Si solo se quiere que muestre los campos de identificador de nivel y su descripción, bastaría con poner:

SELECT game_level_id, game_level_desc
FROM game_level

Como se ve, solo aparecen los campos seleccionados en la parte de selección. Cabe destacar, que si no se usa la parte de condición, la selección se hace sobre todas las filas de la tabla. El número de columnas de la tabla resultado es el número de elementos que tenemos en la selección separados por comas; en este caso, dos. El título de la columna de la tabla resultado es el del nombre del campo.

En la parte de selección se pueden utilizar una serie de funciones que hacen operaciones sobre los campos, se escribe la palabra que representa a la función y entre paréntesis el campo al que se le aplica. Las funciones son:

• Max(campo): obtiene el valor máximo del campo.
• Min(campo): obtiene el valor mínimo del campo.
• Sum(campo): suma los registros del campo elegido.
• Avg(campo): obtiene la media de las filas del campo elegido.
• Count(*): muestra el total de filas seleccionadas.

Si por ejemplo se quiere obtener el máximo bote ganado en las manos almacenadas de cash habría que usar la consulta (el bote máximo sin importar quién lo ha ganado). Te recuerdo que el resumen de las manos se guardan en la tabla game:

SELECT MAX(pot)
FROM game

Si te fijas, el nombre de la columna no es descriptivo. Esto se debe a que como no es un campo, sino una operación sobre un campo, no tiene un nombre fijo asignado. Para que aparezca un título en la columna de la tabla resultado, y lo que es más importante, para que se pueda utilizar este cálculo temporal posteriormente dentro de la selección en consultas más elaboradas, es preciso usar un alias que identificará el resultado temporal. Para ello basta con escribir la palabra AS y el nombre que se le quiere asignar (también se puede utilizar con los campos para que aparezca con otro nombre la columna resultado y para volver a usar esos campos):

SELECT MAX(pot) AS bote_máximo
FROM game


Si ahora se quiere obtener el bote máximo ganado por cada jugador, se puede utilizar una nueva instrucción que agrupa las filas que tienen el mismo valor en un campo. Esa instrucción se representa en SQL mediante las palabras GROUP BY. Para hacer esta consulta, habrá que agrupar las filas que tengan el mismo valor en el campo player_id (que es el que identifica al jugador). Para que aparezca también el identificador del jugador, se añade ese campo en la selección:

SELECT player_id, MAX(pot) AS bote_máximo_por_jugador
FROM game
GROUP BY player_id

Como se puede apreciar, aparece un identificador del jugador que es un número. Esto es debido a que es así cómo se guarda en el resto de tablas que no es la de jugadores (players) para diferenciarlos. Si se quieren obtener más datos del jugador, hay que mirar también en la tabla players, pero eso lo dejo para más adelante.

Ahora voy a tratar la parte condicional de las consultas. Hasta aquí, las consultas estaban realizadas sobre todas las filas de la tabla. Si se quiere seleccionar sobre solo una fracción de ellas, es preciso usar la parte del WHERE. A continuación es preciso establecer las condiciones que debe cumplir la búsqueda. Para ello se usan los campos o los alias (entre corchetes) de la parte de la selección y las relaciones entre ellos. Estas relaciones pueden ser de comparación: mayor que, menor que, mayor o igual que, menor o igual que, distinto, igual (>, <, >=, <=, <>, =); lógicas: y, o, no (And, Or, Not) y otros operadores como intervalo (Between And), filas diferentes (Distinct), similares (Like), conjunto (In, Not In), si el campo es vacío (Is Null), etc.

Para entenderlo mejor, voy a hacer la consulta del máximo bote de cash menor de 50:

SELECT MAX(pot) AS bote_máximo
FROM game
WHERE pot ‘<’ 50
Si se quieren ver los datos de un jugador como todos los identificadores de jugador, los alias y las salas que se corresponden con un nombre de usuario (en mi caso suelo usar “spainfull“), bastaría hacer la siguiente selección (estos datos se encuentran en la tabla players, que almacena en cada fila los datos de un jugador en una sala; el identificador de sala es un valor que se corresponde con una sala que se puede ver en la tabla poker_sites):

SELECT player_id AS jugador_id, main_site_id AS sala, alias_id AS alias
FROM players
WHERE screen_name = “spainfull”

Si se quieren ver todos los identificadores de un jugador, la sala a la que corresponde ese identificador, el nombre de usuario en esa sala, conociendo el número empleado como alias_id (en mi caso 1) se pueden obtener con la siguiente consulta:

SELECT player_id AS jugador_id, main_site_id AS sala, screen_name AS nombre
FROM players
WHERE alias_id = 1

Como en la fila del identificador original que se emplea como alias_id, el campo alias_id está vacío, no aparece en los resultados. Para que así suceda, es preciso añadir una condición además de la que se ha puesto en el ejemplo anterior, que el alias sea 1 o que el identificador del jugador sea 1:

SELECT player_id AS jugador_id, main_site_id AS sala, screen_name AS nombre
FROM players
WHERE alias_id = 1 OR player_id = 1

La siguiente consulta será el bote medio conseguido por mí en cualquier nivel de juego almacenado en la tabla:

SELECT SUM(pot)/COUNT(game_id) AS bote_medio
FROM game
WHERE player_id = 1

Se suman todos los botes y se divide por el número de filas en las que he ganado (en el campo player_id de la tabla game se almacena el ganador de la mano). Si además se desea saber el bote medio obtenido en un nivel concreto (los niveles se guardan en la tabla game_level), por ejemplo en $1/$2 que corresponde con identificador 5 (game_level_id establece el nivel de la mano en la tabla game):

SELECT SUM(pot)/COUNT(game_id) AS bote_medio
FROM game
WHERE player_id = 1 AND game_level_id = 5

Si además se quiere ver el total y el número de botes ganados para que quede más informativa y clara la consulta:

SELECT SUM(pot) AS bote_total, COUNT(game_id) AS botes_ganados, [bote_total]/[botes_ganados] AS bote_medio
FROM game
WHERE player_id = 1 AND game_level_id = 5

Como se puede comprobar, sabiendo qué campos elegir y cómo hacer condiciones, con todo lo visto hasta ahora se pueden hacer consultas sencillas.

Para obtener datos que se encuentran en más de una tabla que están unidos por un identificador (como por ejemplo player_id en varias tablas) hay que utilizar lo que se conoce como unión. Por ejemplo, si en la consulta realizada anteriormente del bote máximo de cada jugador se quieren obtener más datos por jugador, hay que mirar en la tabla players. Si por ejemplo se quiere mostrar además el nombre del jugador al que pertenece ese identificador, habrá que obtenerlo de esa tabla. Para conseguirlo, en la parte de selección se señala de qué tabla proviene cada campo anteponiendo al nombre del campo el nombre de la tabla a la que pertenece y un punto. En la parte de origen, se ponen los nombres de las tablas separados por la instrucción INNER JOIN y se especifica qué campos son los que unen las tablas (los que significan lo mismo, son del mismo tipo aunque puedan tener distinto nombre) tras la palabra ON:

SELECT game.player_id, players.screen_name, Max(game.pot) AS bote_máximo_por_jugador
FROM game INNER JOIN players ON game.player_id = players.player_id
GROUP BY game.player_id, players.screen_name

Esta consulta se podría poner de otra manera en la que se ve claro lo que hace el INNER JOIN:

SELECT game.player_id, players.screen_name, Max(game.pot) AS bote_máximo_por_jugador
FROM game, players
WHERE game.player_id = players.player_id
GROUP BY game.player_id, players.screen_name

Por último, voy a diseccionar la consulta que mostré como ejemplo en el primer artículo, que calculaba las veces que mejoraba nuestra pareja a trío en el flop:

SELECT gp.hole_cards AS Par, count(*) AS Veces, SUM(
IIF(left(g.flop_1,1)=left(gp.hole_card_1,1),1,
IIF(left(g.flop_2,1)=left(gp.hole_card_1,1),1,
IIF(left(g.flop_3,1)=left(gp.hole_card_1,1),1,
0)))) AS [Trío en flop]
FROM game_players AS gp INNER JOIN game AS g ON gp.game_id = g.game_id
WHERE gp.player_id = (select pref_value from prefs where pref_key = ‘RP’)
AND gp.pair_hand = 1
AND gp.saw_flop_n = 1
GROUP BY gp.hole_cards, gp.card_order1
ORDER BY gp.card_order1 DESC

Antes de empezar a hacer una consulta se debe tener claro qué es lo que se quiere conseguir y dónde están esos datos. Lo que se pretende es ver cuándo nuestra pareja de mano ha mejorado a trío. Las cartas comunes de cada mano se guardan en la tabla game, pero las cartas de cada jugador en cada mano se almacenan en la tabla game_players. Por lo tanto, está claro que habrá que usar estas dos tablas. El campo que une estas dos tablas es el game_id, que identifica unívocamente cada mano. Así, tenemos la parte de origen que queda de la siguiente manera:

FROM game_players AS gp INNER JOIN game AS g ON gp.game_id = g.game_id

Se emplea un alias para cada tabla para no tener que volver a escribir el nombre de las tablas antes de cada campo y que quede demasiado largo.

En la parte de selección se detallan las columnas que se quieren visualizar como resultado. En este caso, la pareja de mano que se tiene (en la tabla game_players el campo hole_cards indica la mano que tiene el jugador), el número de veces que se ha dado cada pareja cuando se ha visto el flop, y el número de veces que ha mejorado a trío. Si se hiciera la consulta sin la parte condicional, la selección se haría sobre todas las manos de la tabla game, pero lo que se quiere es que se trate de una mano nuestra, que sea una pareja de mano y que se haya visto el flop. Pero volviendo a la parte de selección, tenemos:

SELECT gp.hole_cards AS Par, count(*) AS Veces, SUM(
IIF(left(g.flop_1,1)=left(gp.hole_card_1,1),1,
IIF(left(g.flop_2,1)=left(gp.hole_card_1,1),1,
IIF(left(g.flop_3,1)=left(gp.hole_card_1,1),1,
0)))) AS [Trío en flop]

Los dos primeros elementos están claros, la mano inicial (que serán parejas por las condiciones que se pondrán después) y el número de veces que nos han repartido esas parejas cuando hemos visto el flop (también significará esto por las condiciones de la parte WHERE que se añadirán). La tercera columna es más sencilla de lo que parece; para que nuestra pareja se convierta en trío, precisa que una de las cartas del flop sea igual a cualquiera de las que tenemos en mano; eso es lo que indica la expresión que está dentro del SUM.

Las cartas que nos han repartido están en la tabla game_players en los campos hole_card_1 y hole_card_2 y las del flop en la tabla game en los campos flop_1, flop_2 y flop_3. Estos campos son alfanuméricos (letras y números) y cada carta se representa por su valor (un número del 2 al 9 o una letra mayúscula si es un A, T, J, Q o K seguido de una letra minúscula que indica el palo); por tanto se debe obtener el valor de la carta sin importar el palo, es decir, el primer carácter de los campos a seleccionar. Para ello se cuenta con la instrucción de SQL left(campo, x) que obtiene x caracteres empezando por la izquierda en un campo alfanumérico. En este caso nos interesa mirar si el valor de una de nuestras cartas de mano (como es una pareja no importa con cuál comparemos) es igual a cualquiera de las tres del flop. Con este objetivo se utiliza left(gp.hole_card_1, 1) para nuestra mano y se compara con left(g.flop_x,1). IIF evalúa una condición y si se cumple se da el primer valor, y si no el segundo: IIF(condición, valor_1, valor_2); en este caso, si coincide la comparación que se hace entre nuestra carta de mano y la primera del flop, el valor es uno y se suma y se sale de la expresión (como vez que conseguimos trío, se suma porque se emplea SUM encerrando a la expresión completa), si no coincide se mira la segunda del flop, si coincide se suma y se sale de la expresión, si no se mira la tercera y si coincide se suma y se sale de la expresión, y por fin, si no es que no se consiguió trío y el valor que se obtiene y se suma es 0. Puede parecer complicado, pero con un poco de paciencia se entiende sin problemas.

Ahora la parte de la condición:

WHERE gp.player_id = (select pref_value from prefs where pref_key = ‘RP’)
AND gp.pair_hand = 1
AND gp.saw_flop_n = 1
GROUP BY gp.hole_cards, gp.card_order1
ORDER BY gp.card_order1 DESC

La primera condición es que sea nuestro jugador. Se podría poner el número que se ha obtenido en una de las consultas anteriores, pero en este caso se ha anidado otra consulta (se debe escribir entre paréntesis) que coge de la tabla de preferencias prefs nuestro identificador de jugador, almacenado en el campo pref_value y que se asocia al valor “RP” del campo pref_key. La siguiente condición es que sea una pareja de mano, aspecto almacenado en la tabla game_players en el campo pair (1 si es pareja de mano, 0 si no). La siguiente, que yo haya visto el flop, guardado en el campo saw_flop de la misma tabla (1 si se ve el flop, 0 si no). Por último, se agrupan las cartas de mano que sean iguales y también por el valor de la mano. Para mostrarlas ordenadas por el valor de la mano se emplea la instrucción ORDER BY (y para seleccionar que en orden inverso de valor la instrucción DESC -el valor de las cartas en el campo card_orderx va del 2 para el 2 al 14 para el As-).

Con esto se acaba el tutorial de cómo realizar consultas SQL en la BD de PT. Espero que te haya servido de algo. Hay mucha información disponible sobre SQL en la red que cubre aspectos y funcionalidades que no he tratado y que pueden resultar interesantes. De todas maneras, si tienes alguna duda, ¡pregunta coño!

Estructura de la base de datos de Poker Tracker

Para los menos iniciados en la informática, es preciso recordar que una base de datos no es más que una manera de almacenar información. Cada tipo de base de datos tiene una forma propia de guardar esos datos y acceder a ellos. Se hace así con el objetivo de recuperar lo almacenado con mayor rapidez, mantener una gran cantidad de datos eficientemente y para facilitar la inserción de nuevos elementos; todo esto es posible porque hay implementados una serie de interfaces (protocolos, medios de comunicación entre programas) que permiten realizar estas operaciones de manera mucho más eficaz que si se guardaran los datos, por ejemplo, en un simple archivo de texto.

Hay muchos tipos de bases de datos. Seguro que te suenan palabras como Access, Oracle, SQLServer, MySQL, PostgreSQL… Todas identifican bases de datos muy diferentes entre sí, cuya construcción interna no se parece en absoluto, aunque tienen cosas en común. Básicamente, todas ellas almacenan la información en tablas, cada una de las cuales tiene una serie de campos que definen atributos de lo representado por la tabla. La forma de acceder a estos datos es distinta en cada caso ya que suelen poseer su propio lenguaje, pero las consultas SQL que voy a crear se pueden utilizar en todas ellas con pocas modificaciones (SQL es el lenguaje base usado por la mayoría de bases de datos de la actualidad).

Access no es diferente y también guarda los datos en tablas. Una tabla se identifica por un nombre que debería ser descriptivo de la información que contiene. En cada tabla los datos se agrupan en campos que contienen los detalles de lo que se quiere almacenar. Por ejemplo, si se es un poco maníaco-obsesivo-exitoso y se desea tener una base de datos de ligues, habría una tabla de nombre “Pibitas” (si es muy obsesivo probablemente el nombre sería “Chochos“) que contendría seguramente los campos “Nombre“, “Teléfono“, “Altura“, “Edad“, “Peso“, “Cara” (nota asignada de 1 a 10), “Tetas” (nota asignada de 1 a 10), “Culo” (nota asignada de 1 a 10), “Sexo” (vamos, que si folla) , “Casada” y “FechaPrimeraCita“. Los campos son las columnas de la tabla y, cada nueva conquista, sería una nueva fila en la tabla que tendría unos valores en los campos que la definirían. Advertir que la elección de los campos ha sido totalmente arbitraria; se podrían haber definido otros atributos o características (y no, no tengo una tabla como ésta hecha).

Los campos pueden ser de distinto tipo dependiendo de la información que vayan a guardar. Los tipos básicos disponibles son: numéricos (con decimales o sin decimales), alfanuméricos (letras y números, es decir, texto), moneda, fechas y booleano (datos que son verdadero o falso, por ejemplo “Sexo” y “Casada“). Como se puede comprobar, hasta aquí no es nada complicado. Ahora que conoces las bases, voy a desmenuzar las tablas de PT y el porqué de cada una.

En una base de datos suele haber más de una tabla para lograr definir los objetos que participan en el problema a solucionar; además, los datos que contienen están interrelacionados entre ellas. Las consultas se pueden hacer sobre varias tablas a la vez ya que si no, se limitaría mucho la búsqueda. La creación de bases de datos en sistemas complejos es una tarea ardua y complicada puesto que hay que tener en cuenta muchas variables y factores. Pero tranquilo, eso es otra historia y, como me dijo un profesor de la universidad la primera vez que hablaba con él: “eso a ti te la suda”.

Ahora “solo” vas a aprender la estructura de la base de datos de PT, así que presta atención. Si se abre la base de datos de PT tal y como comenté ayer, y se selecciona “Tablas” en los “Objetos“, aparece una imagen como la siguiente con todas las tablas de PT:

La mayor parte de las tablas son bastante auto explicativas, y sus campos logran definir cada aspecto que el programador de PT ha querido reflejar. Hay algunas tablas que son de definición: de niveles, salas, ciegas, etc.; otras que detallan cada mano del juego con todos los datos posibles; otras que son resumen de valores para que la recuperación y visualización en PT sea más rápida (como por ejemplo la tabla de las sesiones jugadas); y, por último, otras que sirven para la configuración del programa.

Para ver los campos de cada tabla, basta con seleccionar la tabla de la que se quiere ver su estructura y pulsar el icono de “Diseño” o hacer clic con el botón derecho del ratón sobre la tabla elegida y pulsar sobre “Vista Diseño“:

Si se hace lo dicho, aparece una ventana que lista los campos que contiene la tabla y el tipo de cada uno de los campos. También puede contener observaciones acerca del contenido de cada uno de los campos que se utilizan para hacer aclaraciones sobre el mismo (solo tiene valor informativo). Un apunte, en la creación de la mayor parte de las tablas se define un campo identificador que distingue unívocamente a una fila de la tabla del resto de filas; la mayoría de las tablas de PT tienen un campo de este tipo, que suele ser un entero positivo (se declara en la base de datos para que cada vez que se añade una fila se incremente automáticamente, aunque éste es un detalle que no nos importa demasiado). Estos identificadores son muy útiles para enlazar valores entre tablas (esto se verá más claro en el siguiente capítulo en el que haré las consultas):

Voy a agrupar las tablas de PT según la función para la que han sido creadas. Ésta es una clasificación que he establecido para que se vea más claramente la utilidad de cada una de ellas, pero no significa que sean de distinto tipo sino simplemente que las he ordenado para no mostrar todas seguidas; solo hay un tipo único de tablas aunque se usen para almacenar diferentes tipos de datos. Los datos de cash y torneos se guardan en tablas separadas.

La mejor manera para seguir la explicación de las tablas es abrir en Access la base de datos e ir abriéndolas conforme se detallan (basta con hacer doble click sobre la tabla que se quiera visualizar).

♣ Tablas de definición de datos:
Son todas aquellas que definen entidades que se utilizarán en otras tablas.

♠ Tabla blind_structure.
Define los distintos niveles en un torneo. Contiene los campos siguientes:

• blind_structure_id: identificador del nivel de ciegas.
• blind_structure_desc: estructura de ciega pequeña y ciega grande.
• big_bet: tamaño de la ciega grande en relación a la unidad (una ficha es la unidad más pequeña).

Puede que te preguntes por qué los valores están desordenados. Esto es debido a que en cuanto PT lee un nivel nuevo de ciegas, añade una línea a esta tabla y le asigna un identificador que comienza en 1 y se va incrementando automáticamente como expliqué anteriormente. Seguramente inicié el PT con un torneo comenzado o la importación automática de torneos la hizo de manera desordenada; esto no tiene ninguna importancia ya que se sabe qué nivel es por el identificador; por ejemplo, el identificador 6 corresponde al nivel de ciegas 150/300, y no importa el orden en el que esté insertada la fila en la tabla.

♠ Tabla game_level.
Define las ciegas en las mesas de cash. Contiene los campos siguientes:

• game_level_id: identificador de la cantidad de las ciegas.
• game_level_desc: descripción de la ciega pequeña y la ciega grande.
• game_level_big_bet: tamaño de la ciega grande en relación a la unidad (la unidad más pequeña es una unidad de moneda ($, € o GBP).
• pl_nl: 0 si es limit, 1 si se trata de NL o PL.

♠ Tabla hand_rank.
Define las posibles manos en el showdown en Holdem. Contiene los campos siguientes:

• hand_rank_id: identificador de la jugada.
• hand_rank_desc: descripción en texto de la calidad de la jugada.

Como se puede apreciar, esta tabla sí está ordenada de peor a mejor jugada, esto es debido a que es una tabla con los datos completos antes de capturar ningún dato el programa, o rellenada automáticamente al crear una nueva base de datos (en Holdem el ranking de jugadas es fijo e inmutable).

♠ Tabla players.
Define a los jugadores en cada sala de póquer. Cada fila identifica a un jugador en una sala. Se utilizará en todas las tablas que contengan datos de juego. Contiene los campos siguientes:

• player_id: identificador del jugador en la base de datos de PT.
• screen_name: nombre en la sala que se ve en pantalla del jugador.
• location: lugar de origen que el jugador se ha puesto en la sala.
• general_description: notas sobre el jugador.
• treeview_icon: identificador del icono del jugador que aparece en el árbol de jugadores del PT (se refiere a los dibujicos que representan cada tipo de jugador).
• site_id: utilizado en los jugadores con alias para indicar el identificador de la sala al que correponde el alias asignado.
• alias_id: identificador del jugador al que corresponde éste alias.
• main_site_id: sala para la que está definido el jugador.
• hide_ind: si no se muestra al jugador de cash en las ventanas del PT.
• ring_player: si es jugador de cash en la sala (significa si se tiene alguna mano de él jugando cash).
• tourney_player: si es jugador de torneos.
• tourney_hide_ind: si no se muestra al jugador de torneos en las ventanas del PT.
• last_icon: último icono del jugador.
• last_auto_rated: fecha en la que se hizo la última clasificación de jugadores automática.
• last_batch_rated: fecha en la que se hizo la última clasificación de jugadores.
• icon_before_batch_rate: icono anterior a la última clasificación de jugadores.
• no_auto_rate: si a éste jugador no hay que clasificarlo.
• icon_file: fichero donde se almacena el icono del jugador (para personalizaciones).

Destacar que, como seguramente conoces, para agrupar las estadísticas de un jugador que tiene datos de diferentes salas hay que utilizar los alias de PT. Ahora puedes ver cómo funcionan. Cada jugador tiene una fila por sala en la que juega. Si se usan los alias, a través de los campos “site_id” y “alias_id” el programa sabe que son el mismo jugador y combinará sus estadísticas.

♠ Tabla poker_sites.
Define las salas de póquer para las que funciona PT. Contiene los campos siguientes:

• site_id: identificador de la sala.
• site_abbrev: nombre abreviado de la sala de póquer.
• site_name: nombre completo de la sala de póquer.

♣ Tablas de datos:
Almacenan los datos del juego en sí.

♠ Tabla game.
Define los detalles generales de cada mano de cash. Cada fila identifica una mano jugada e importada en el PT. Contiene los campos siguientes:

• game_id: identificador de la mano.
• game_number: otro identificador de la mano (usado para salas como Prima).
• site_id: sala donde se juega la mano.
• date_played: fecha en la que se juega la mano.
• game_level_id: nivel en la que se juega la mano.
• flop_1: carta primera del flop.
• flop_2: carta segunda del flop.
• flop_3: carta tercera del flop.
• turn: carta del turn.
• river: carta del river.
• pot: bote que se lleva el ganador de la mano (antes de descontar la comisión).
• rake: comisión que se lleva la casa en la mano.
• player_id: identificador del jugador que gana la mano.
• import_date: fecha en la que se hizo la importación de la mano.
• game_notes: notas de la mano.
• table_name: nombre de la mesa en la que se jugó la mano.
• winning_hand: calidad de la jugada de la mano ganadora.
• real_player_id: identificador real del jugador (si se utilizan alias, éste será el identificador del jugador en la sala, no su alias).
• players_saw_flop: jugadores que han visto el flop.
• number_of_players: número total de jugadores de la mano.
• ub_game_number: identificador de mano en UB.
• ub_kill_game: si es una mesa kill de UB.

Es un resumen de cada mano jugada. Los detalles por jugador están contenidos en la tabla “game_players“.

♠ Tabla tourney_game.
Define los detalles generales de cada mano de torneo. Cada fila es una mano de torneo jugada e importada por PT. Contiene los campos siguientes:

• tourney_id: identificador de la mano.
• game_number: otro identificador de la mano (usado para salas como Prima).
• date_played: fecha en la que se juega la mano.
• blind_structure_id: nivel de ciegas en la que se juega la mano.
• game_level: nombre del nivel en el de ciegas en el que se juega la mano.
• pp_game_number: identificador de la mano (creo que para PP).
• flop_1: carta primera del flop.
• flop_2: carta segunda del flop.
• flop_3: carta tercera del flop.
• turn: carta del turn.
• river: carta del river.
• pot: número de fichas que se lleva el ganador de la mano.
• player_id: identificador del jugador que gana la mano.
• import_date: fecha en la que se hizo la importación de la mano.
• game_notes: notas de la mano.
• table_name: nombre de la mesa en la que se jugó la mano.
• winning_hand: calidad de la jugada de la mano ganadora.
• real_player_id: identificador real del jugador (si se utilizan alias, éste será el identificador del jugador en la sala, no su alias).
• players_saw_flop: jugadores que han visto el flop.
• number_of_players: número total de jugadores de la mano.
• heads_up: si se trata de un torneo Heads Up.
• ub_game_number: identificador de mano en UB.

Como se puede comprobar, esta tabla es similar a la anterior pero usada para torneos.

♠ Tabla game_players.
Define los detalles de cada mano desde el punto de vista de cada jugador que participa en la misma. Contiene los campos siguientes:

• game_id: identificador de la mano.
• player_id: identificador del jugador.
• seat_number: posición en la que está sentado el jugador.
• button: posición que ocupa la posición de button.
• hole_card_1: primera carta de las dos del jugador.
• hole_card_2: segunda carta de las dos del jugador.
• suited: s si es suited, o si no.
• pre_flop_bet: cantidad apostada antes del flop.
• flop_bet: cantidad apostada en el flop.
• turn_bet: cantidad apostada en el turn.
• river_bet: cantidad apostada en el river.
• total_bet: cantidad apostada en el conjunto de la mano.
• total_won: cantidad total ganada en la mano.
• when_folded: cuando tiró las cartas en la mano.
• player_notes: notas del jugador en la mano.
• final_hand: calidad final de la mano del jugador.
• hand_rank_id: identificador de la calidad de la jugada de la mano ganadora.
• all_in: si el jugador ha ido all in en la mano.
• hole_cards: cartas del jugador en formato texto.
• card_order1: ranking de la primera carta de mano en relación a su fuerza individual (2->2,…, As->14).
• card_order2: ranking de la segunda carta de mano en relación a su fuerza individual (2->2,…, As->14).
• card_order3: 1 si son suited, 0 si no.
• connector_hand: 1 si están conectadas, 0 si no.
• pair_hand: 1 si es una pareja de mano, 0 si no.
• won_hand: 1 si el jugador ganó la mano, 0 si no.
• session_id: identificador de la sesión en la que se circunscribe la mano.
• off_the_button: número de posiciones de diferencia con el button.
• number_of_players: número de jugadores en la mano.
• big_blind_n: 1 si es big blind, 0 si no.
• small_blind_n: 1 si es small blind, 0 si no.
• went_to_showdown_n: 1 si llegó con la mano hasta el final, 0 si no.
• saw_flop_n: 1 si vió el flop, 0 si no.
• attempted_steal: 1 si intentó un robo, 0 si no.
• raised_first_pf: 1 si subió el primero antes del flop, 0 si no.
• real_player_id: identificador real del jugador (no su alias).
• chip_count: dinero con el que el jugador comenzó la mano.
• ub_kill_blind: 1 si es la ciega kill en una mesa kill de UB, 0 si no.

Hay muchos otros campos booleanos (valores cierto o falso, 0 ó 1) que definen cada una de las posibles acciones que el jugador ha podido realizar en cada una de las calles (call, check-raise, bet-raise, etc.) y que servirán para mostrar las estadísticas en las ventanas del PT.

♠ Tabla tourney_game_players.
Define los detalles de cada mano de torneo desde el punto de vista de cada jugador que participa en la misma. Contiene los campos siguientes:

• tourney_id: identificador del torneo.
• game_id: identificador de la mano dentro del torneo.
• player_id: identificador del jugador.
• seat_number: posición en la que está sentado el jugador.
• button: posición que ocupa la posición de button.
• hole_card_1: primera carta de las dos del jugador.
• hole_card_2: segunda carta de las dos del jugador.
• suited: s si es suited, o si no.
• pre_flop_bet: cantidad apostada antes del flop.
• flop_bet: cantidad apostada en el flop.
• turn_bet: cantidad apostada en el turn.
• river_bet: cantidad apostada en el river.
• total_bet: cantidad apostada en el conjunto de la mano.
• total_won: cantidad total ganada en la mano.
• when_folded: cuando tiró las cartas en la mano.
• player_notes: notas del jugador en la mano.
• final_hand: calidad final de la mano del jugador.
• hand_rank_id: identificador de la calidad de la jugada de la mano ganadora.
• all_in: si el jugador ha ido all in en la mano.
• hole_cards: cartas del jugador en formato texto.
• card_order1: ranking de la primera carta de mano en relación a su fuerza individual (2->2, …, As->14).
• card_order2: ranking de la segunda carta de mano en relación a su fuerza individual (2->2, …, As->14).
• card_order3: 1 si son suited, 0 si no.
• connector_hand: 1 si están conectadas, 0 si no.
• pair_hand: 1 si es una pareja de mano, 0 si no.
• won_hand: 1 si el jugador ganó la mano, 0 si no.
• session_id: identificador de la sesión en la que se circunscribe la mano.
• off_the_button: número de posiciones de diferencia con el button.
• number_of_players: número de jugadores en la mano.
• big_blind_n: 1 si es big blind, 0 si no.
• small_blind_n: 1 si es small blind, 0 si no.
• went_to_showdown_n: 1 si llegó con la mano hasta el final, 0 si no.
• saw_flop_n: 1 si vió el flop, 0 si no.
• attempted_steal: 1 si intentó un robo, 0 si no.
• raised_first_pf: 1 si subió el primero antes del flop, 0 si no.
• real_player_id: identificador real del jugador (no su alias).
• chip_count: stack con el que el jugador comenzó la mano.
• blind_amt: cantidad de fichas pagadas en la mano en concepto de ciegas (0 si el jugador está fuera de las posiciones que pagan ciegas).
• ante_amt: cantidad de fichas pagadas en concepto de ante.

Hay muchos otros campos booleanos (valores cierto o falso, 0 ó 1) que definen cada una de las posibles acciones que el jugador ha podido realizar en cada una de las calles (call, check-raise, bet-raise, etc.) y que servirán para mostrar las estadísticas en las ventanas del PT. Esta tabla es similar a la anterior pero orientada a torneos (por eso algunas columnas diferentes como la de los antes).

♠ Tabla tourney.
Define los datos generales de los torneos. Cada fila identifica un solo torneo importado en PT. Contiene los campos siguientes:

• tourney_id: identificador del torneo en la base de datos de PT.
• site_id: identificador de la sala en la que se juega el torneo.
• tourney_number: número de identificación del torneo en la sala.
• tourney_start: fecha y hora de inicio del torneo.
• tourney_end: fecha y hora de fin del torneo.
• buy_in: dinero que costó la entrada al torneo.
• fee: dinero pagado como comisión a la sala de póquer.
• tourney_type: tipo de torneo (si no concreto más es porque no tengo apenas torneos guardados en la base de datos y no tengo ni puta idea de cuáles son los valores).
• table_type: tipo de mesa (ídem. a la anterior).
• summary_text: resumen en formato texto del identificador del torneo.
• target_tourney_number: si es un satélite, indica el identificador del torneo en la sala al que se opta si se consigue una plaza.
• number_of_players: número de jugadores del torneo.
• tourney_notes: notas del torneo.
• summary_loaded: si se ha importado en el PT el resumen del torneo.

♣ Tablas de resumen de datos:
Guardan los resultados de ganancias y otras estadísticas agrupados.

♠ Tabla session.
Define los datos de una sesión de juego (desde que te sientas a una mesa hasta que te levantas). Contiene los campos siguientes:

• session_id: identificador de la sesión en la base de datos de PT.
• player_id: identificador del jugador.
• session_start: fecha y hora de inicio de la sesión.
• session_end: fecha y hora de fin de la sesión.
• table_name: nombre de la mesa.
• seat_number: posición dentro de la mesa.
• session_notes: notas escritas de la sesión.
• game_level_id: identificador del nivel en el que se juega.
• amount_won: cantidad ganada total (o perdida, excepto para Caminante que solo tiene valores positivos en este campo).
• total_hands: número total de manos jugadas.
• site_id: identificador de la sala.
• vol_saw_flop: este valor en el conjunto de la sesión.
• pre_flop_raise: este valor en el conjunto de la sesión.
• att_steal: este valor en el conjunto de la sesión.
• chance_to_steal: oportunidades de robo en el conjunto de la sesión (ya sabes, triste es pedir…).
• won_hand: número de manos ganadas en la sesión.
• went_to_sd: este valor en el conjunto de la sesión.
• won_at_sd: este valor en el conjunto de la sesión.
• real_player_id: identificador del jugador (distinto del anterior si usa alias y no es la sala primera en la que PT definió al jugador).
• tot_players: número total de jugadores en el conjunto de la sesión (suma los totales en cada mano, sin importar que sea el mismo jugador; es decir, si juegas una sesión maratoniana de 2 manos contra los mismos 9 tíos, este campo valdrá 20).
• tot_saw_flop: número total de jugadores que han visto el flop en la sesión (mismo comentario que en el campo anterior).
• tot_pot: cantidad total de dinero en todos los botes de la sesión (la suma de todos los botes generados sin importar quién los ganara).

♠ Tabla tourney_summary.
Define datos de los torneos desde el punto de vista de un jugador. Un torneo tendrá en esta tabla tantas filas como jugadores hayan participado (siempre que se hayan importado los datos a PT). Contiene los campos siguientes:

• tourney_id: identificador del torneo en la base de datos de PT.
• place_of_finish: lugar en el que acabó el torneo el jugador.
• player_id: identificador del jugador.
• amt_won: cantidad ganada por el jugador.
• real_player_id: identificador del jugador (por si se utilizan alias).
• sat_seat_won: el equivalente a dinero que cuesta la entrada al satélite que ha ganado este jugador.
• actual_buy_in: dinero pagado total como entrada por este jugador.
• actual_fee: dinero pagado total como comisión a la sala de póquer.
• total_rebuys: número total de recompras realizadas en el torneo.
• rebuy_amt: cantidad que costaba cada recompra.
• total_addons: número total de addons realizados en el torneo.
• addon_amt: cantidad que costaba cada addon.

♠ Tabla player_winnings.
Define los datos de ganancias entre los jugadores de cash. Cada fila identifica el dinero que le ha ganado un jugador a otro durante una sesión. Contiene los campos siguientes:

• date_played: día en el que se contabilizan los datos de la fila.
• game_level_id: identificador de la cantidad de las ciegas.
• site_id: identificador de la sala.
• player_id: identificador del jugador que ha ganado dinero en la sesión a opponent_id.
• session_id: identificador de la sesión.
• opponent_id: identificador del jugador que ha palmado pasta en la sesión a manos del jugador player_id.
• won_from: cantidad ganada por el jugador player_id a opponent_id.
• times_beat: veces que player_id ha ganado a opponent_id en la sesión.
• real_player_id: identificador del jugador ganador (por si usa alias).
• real_opp_id: identificador del jugador perdedor (por si usa alias).

Esta tabla sirve como base para mostrar la información de ganancias y pérdidas entre jugadores que tantas veces hemos tenido que volver a mirar varias veces por parecer increíble que ese jugador, con lo malo que es, nos haya ganado tanto dinero.

♣ Tablas de configuración:
Almacenan los datos de configuración del PT. En este apartado se encuentran las siguientes tablas (no merece la pena extenderse en ellas):

• dst: rangos de fechas que utilizará para cálculos internos del programa.
• datawindow_prefs: preferencias del programa.
• exrates: tipo de cambio entre dólares, euros y libras que va a utilizar en los cálculos.
• error_msgs: mensajes de error del programa.
• version_info: número de versión del programa.

Con esto concluyo la revisión pormenorizada de las tablas de PT. Espero que aclare algunas dudas y facilite la creación de consultas que abordaré en la siguiente entrada.

Por defecto, el programa PT almacena los datos que captura de las diferentes salas de póquer en un archivo de base de datos Access. Éste archivo tiene la extensión “.mdb” y no es más que una manera de guardar la información. Esta información la obtiene PT de los historiales de las manos que se almacenan en nuestro disco duro en los directorios de las aplicaciones de las salas de póquer creados a tal efecto (la ruta que tenemos que poner en las ventanas de auto-import del PT para que pueda leer las manos). Lo que hace PT es leer esos ficheros de texto que contienen las manos jugadas, interpretar la información que de ellos se puede sacar (jugadores, stacks, nuestras cartas de mano, cartas comunitarias, apuestas, ganador de la mano, etc.) y escribirla en la base de datos de manera apropiada para que después pueda ser procesada.

PT da la opción de guardar la información en otro tipo de base de datos llamada PostgreSQL. Es totalmente gratuita y su código está disponible para todo el mundo. Tiene algunas ventajas sobre Access como son no tener limitación de espacio, ser algo más rápida, más estable y más robusta. El inconveniente es que hay que instalarla y configurar algunos parámetros en el PT para que funcione, pero tampoco nada demasiado complicado. Ahora bien, si no jugamos un número excesivo de manos, se puede usar Access tranquilamente. El problema de las bases de datos de Access es que tienen una limitación de tamaño de 2GB y hay que compactarlas de vez en cuando para que no se haga muy lento el acceso a los datos que contienen. Una solución es crear varias bases de datos de Access en PT, aunque es un poco latoso tener que estar cambiando de una a otra según donde quieras guardar los datos de juego.

El método que voy a explicar a continuación solo es válido para aquellos que guardan los datos del PT en una base de datos Access. Para realizar consultas SQL sobre ella, se necesita algún programa que tenga esta función incluida. En principio, se pueden utilizar tanto Microsoft Access como Microsoft Excel, aunque si no se dispone de estos programas, es posible bajarse algún programa gratuito que nos permita hacer consultas Access como por ejemplo SQueAl. En primer lugar mostraré simplemente cómo hacer la consulta sin entrar a analizar en detalle otros aspectos un poco más complejos que dejo para más adelante.

Ejecutar una consulta con Microsoft Access

Antes de comenzar una advertencia: Microsoft Access es la aplicación nativa para las bases de datos Access de PT, con lo que cualquier cambio que se haga sobre la tablas o borrado de elementos por error pueden provocar daños irreparables que implicarían la inutilización de la base de datos; así que cuida donde metes las zarpas y no pulses aceptar sin leer el mensaje. En principio, si sigues los pasos indicados no hay ningún problema, pero por si acaso, ten siempre una copia de seguridad de tu base de datos (basta con hacer una copia del archivo “.mdb“ donde tengas la base de datos).

La consulta que se va a hacer es la de parejas que han mejorado a trío en el flop. El código SQL para esta consulta es el siguiente (ten en cuenta que esto no es un tutorial ni de SQL ni de Access aunque posteriormente explicaré algunos conceptos, pero si quieres más información la red está llena de tutoriales sencillos):

SELECT gp.hole_cards AS Par, count(*) AS Veces, SUM(
IIF(left(g.flop_1,1)=left(gp.hole_card_1,1),1,
IIF(left(g.flop_2,1)=left(gp.hole_card_1,1),1,
IIF(left(g.flop_3,1)=left(gp.hole_card_1,1),1,
0)))) AS [Trío en flop]
FROM game_players AS gp INNER JOIN game AS g ON gp.game_id = g.game_id
WHERE gp.player_id = (select pref_value from prefs where pref_key = ‘RP’)
AND gp.pair_hand = 1
AND gp.saw_flop_n = 1
GROUP BY gp.hole_cards, gp.card_order1
ORDER BY gp.card_order1 DESC;

Para empezar, arranca la aplicación Microsoft Access. En el menú “Archivo“ escoge la opción “Abrir…“ y en la ventana que se presenta, navega hasta seleccionar la base de datos sobre la que quieras hacer la consulta. Por defecto, la base de datos de PT es “ptrack.mdb“ (puede que no aparezca la extensión “.mdb“) y se encuentra en la ruta: “C:\Archivos de programa\Poker Tracker V2” (también se puede abrir pulsando dos veces sobre el archivo “ptrack.mdb” en el explorador de Windows.

Aparecerá la siguiente pantalla. Debes pulsar en “Consultas” (“Queries” si tienes el programa en inglés) y a continuación en el menú de la ventana mostrada seleccionar “Nuevo” y en la nueva ventana “Vista Diseño“ (o directamente “Crear una consulta en vista Diseño“).

Aparecerá una ventana de “Consulta de selección” y sobre ella una ventana de “Mostrar Tabla“.

Cierra esta última ventana y nos quedamos con la ventana de consulta. Ahora debes pulsar el icono “SQL” que se encuentra debajo de “Archivo” o seleccionar “Ver->Vista SQL“.

Ahora ya solo nos queda copiar (o escribir) la consulta a realizar en la ventana y pulsar el icono “!” o seleccionar “Consulta->Ejecutar” para que obtengamos los resultados.

Se puede guardar la consulta para no tener que copiarla cada vez que queremos obtener la información; para ello basta pulsar el icono del disquete o seleccionar “Archivo->Guardar” y darle un nombre a la consulta, almacenándose junto con el resto de consultas previas en el apartado de “Consultas” de la base de datos visto en la primera imagen. Lo que se guarda es el texto de la consulta, no el resultado; si se quiere guardar el resultado habrá que copiarlo y pegarlo en otra aplicación (Excel, Word, Block de notas, etc.).

Una última consideración, de las instrucciones SQL que se pueden ejecutar, solo “SELECT” no tiene como resultado modificar las tablas de las bases de datos (simplemente muestra información), así que no copiéis y ejecutéis consultas que incluyan palabras como “DROP“, “INSERT“, “UPDATE“ o “DELETE“ y, en general, consultas sospechosas no verificadas por otros usuarios más duchos en la materia. En el siguiente apartado explicaré en detalle las tablas de la base de datos y un poco de SQL (no demasiado, necesitarás un tutorial más completo) para que puedas hacer tus propias consultas.