7.10.2025 – Torsten Ahlemeyer
Slides/Demos: Downloads – arelium – Wir holen mehr aus Ihren Daten heraus

English Version

So einen Typen wie Torsten Ahlemeyer triffst du nur selten. Ein echter Algorithmen-Geek, leidenschaftlicher Datenbankentwickler und zu jeder Schandtat mit dem SQL Server bereit. Ob Trickfilme animieren, Volksfest-Taschengeld strategisch investieren oder komplexe Logikrätsel lösen – Torsten bringt nicht nur technische Finesse, sondern auch eine gehörige Portion Kreativität mit.

Sein Motto? „Warum nicht?“ – und das lebt er. Schach auf dem SQL Server? Klar. Poker? Auch. Dieses Mal ging es genau darum: Poker. Und wie immer machte Torsten es schon bei der Einleitung spannend. Mit den Worten:

„Ich dachte, das sind ja nur 52 Karten und das wird ja wohl nicht so schwer sein.“

Doch es erwies sich als harte Nuss. Eine, die er – ganz ohne KI – an einem Sonntagnachmittag geknackt hat. Und wie!

Tipps zum schnellen Start

Wer direkt loslegen will, folgt am besten dieser bewährten Reihenfolge mit den Skripten:

• Skript 001: Anpassen und ausführen – hier werden die Grundlagen gelegt
• Skript 901: Das komplette CMD-Setup im sqlcmd-Modus ausführen – wichtig für die Umgebung
• Skript 951: Play a Game starten – jetzt wird’s interaktiv
• Und dann: EXECUTE [Game].[prcRevealTheFlop] – der Flop wird aufgedeckt, das Spiel beginnt!
  

Rechtlich: Glücksspiel. Praktisch? Strategie pur.

Klar, juristisch gilt Poker als Glücksspiel – weil die Entscheidung angeblich allein vom Zufall abhängt. Aber das greift zu kurz. Vor allem bei Texas Hold’em sieht die Sache anders aus:
Ein einzelnes Spiel mag Glückssache sein. Aber über mehrere Hände hinweg – besonders im Turnier – zählt die Gesamtstrategie. Wer richtig spielt, hält den Zufallsanteil deutlich unter 50%.

Gute Karten? Gewinn maximieren. Schlechte Karten? Schnell wegwerfen und Verluste minimieren.
Pokern heißt: Wahrscheinlichkeiten einschätzen, Position bewerten und entscheiden, ob man investiert oder aussteigt.

Wahrscheinlichkeiten: Nicht einfach nur ausrechnen

Der Versuch, alle Möglichkeiten durchzurechnen, ist mathematisch spannend – aber praktisch nicht zielführend:

• Pik-Wahrscheinlichkeit: 13/52 = 0,25 – korrekt, aber trivial
• Mischen? Die Anzahl möglicher Kartendecks: 52! ≈ 8×10⁶⁷ – riesig, aber irrelevant für Spielentscheidungen
• SQL Server unterstützt maximal 2⁶³ – also keine Chance, alle Permutationen zu speichern

Entscheidend ist nicht die absolute Wahrscheinlichkeit, sondern die relative Bewertung von Situationen:
Wie viele „Outs“ habe ich? Wie hoch ist meine Equity? Wie verändert sich meine Gewinnchance, wenn andere aussteigen?

Eröffnungshände: Bewertung nicht dynamisch berechnen

Ein häufiger Fehler in der Umsetzung: Die Bewertung jeder Eröffnungshand (z. B. 7♠ 2♦ oder A♣ K♠) wird im Code dynamisch berechnet. Das ist ineffizient und unnötig.

Besser: Eine feste Tabelle mit vorkalkulierten Handwerten – basierend auf Position, Anzahl der Spieler und Turnierphase.
Beispiel:

• A♠ K♠ in früher Position = stark
• 9♣ 8♣ in später Position = spielbar
• 7♦ 2♣ = fast immer Fold

Diese Tabellen basieren auf Millionen von Simulationen und sind in der Praxis viel zuverlässiger als spontane Berechnungen.

Position und Timing: Der unterschätzte Faktor

Die Position am Tisch ist oft wichtiger als die Karten selbst:

• Spieler in früher Position müssen zuerst entscheiden – ohne Infos
• Spieler in später Position sehen, wie andere agieren – und können besser reagieren
• Beispiel: In 6-Handed Games hat jeder Spieler zu Beginn eine theoretische Gewinnchance von 16,67% – aber die verändert sich mit jeder Aktion

Ein häufiger Fehler: Wahrscheinlichkeiten werden unabhängig von der Tischdynamik berechnet.
Dabei ist entscheidend, ob jemand vor mir erhöht hat, ob ich im Big Blind sitze oder ob ich short-stacked bin.

Bluff, Outs und Risiko korrekt modellieren

Ein Bluff ist kein „Glücksspiel“, sondern eine kalkulierte Entscheidung basierend auf Gegnerverhalten, Tischbild und Stackgrößen.
Wenn ich bluffe und verliere, verliere ich nur das, was mein Gegner auch einsetzen kann – das Risiko ist begrenzt.

Outs korrekt berechnen:

• Beispiel: Ich habe einen Flush-Draw mit 9 Outs
• Noch zwei Karten kommen → Gewinnchance ≈ 35%
• Formel: 1 – ((38/47) * (37/46)) ≈ 0,35

Diese Berechnungen sind sinnvoller als globale Wahrscheinlichkeiten wie „Royal Flush = 0,003%“ – denn die helfen im Spiel nicht weiter.

Fazit: Poker ist Berechnung, aber nicht brute force

Die Kunst liegt nicht darin, alle Möglichkeiten durchzurechnen, sondern die relevanten zu erkennen.
Position, Stackgröße, Gegnerverhalten und Turnierphase sind entscheidender als reine Kartenkombinationen.

Was Torsten gebaut hat, ist beeindruckend – aber der Weg über Datentypen und SQL allein reicht nicht. Besonders bewundere ich ihn für sein Faible für Algorithmen und große Experimentierfreudigkeit.

Eröffnungshände sollten tabellarisch bewertet werden, Wahrscheinlichkeiten kontextabhängig und Entscheidungen dynamisch angepasst.

Und ja: Der Dealerbutton wandert weiter.
Die Wahrscheinlichkeiten verteilen sich neu.
Das Spiel beginnt von vorn – aber die Strategie bleibt.

Holt euch den TSQL Code und spielt doch mal selbst Poker auf dem SQL Server.

English Version

You don’t meet someone like Torsten Ahlemeyer every day. A true algorithm geek, a passionate database developer, and always ready for any SQL Server mischief. Whether it’s animating cartoons, strategically investing pocket money at the fair, or solving complex logic puzzles – Torsten brings not only technical finesse but also a healthy dose of creativity.

His motto? “Why not?” – and he lives by it. Playing chess on SQL Server? Sure. Poker? Absolutely. This time, it was all about poker. And as always, Torsten made it exciting right from the start, with the opening line:

“I thought, it’s just 52 cards – how hard can it be?”

Turns out, it was a tough nut to crack. One he managed to crack on a Sunday afternoon – without any help from AI. And how!

Quick Start Tips

If you want to jump right in, follow this proven script sequence:

• Script 001: Adjust and execute – this sets the foundation
• Script 901: Run the complete CMD setup in sqlcmd mode – essential for the environment
• Script 951: Start Play a Game – now it gets interactive
• And then: EXECUTE [Game].[prcRevealTheFlop] – the flop is revealed, and the game begins!

With these steps, you’re ready for your first poker round on SQL Server.

🎲 Legally: Gambling. Practically? Pure strategy.

Sure, from a legal standpoint, poker is considered gambling – because decisions are supposedly based on pure chance. But that’s an oversimplification. Especially in Texas Hold’em, things look different: A single hand might be luck. But over multiple hands – especially in tournaments – overall strategy wins out. If you play correctly, the luck factor drops well below 50%.

Good cards? Maximize profit. Bad cards? Fold quickly and minimize losses. Poker means: estimating probabilities, evaluating position, and deciding whether to invest or fold.

📊 Probabilities: Not just about calculation

Trying to calculate every possibility is mathematically fascinating – but practically useless:

• Probability of drawing a spade: 13/52 = 0.25 – correct, but trivial
• Shuffling? Number of possible decks: 52! ≈ 8×10⁶⁷ – huge, but irrelevant for gameplay
• SQL Server supports up to 2⁶³ – so no chance of storing all permutations

What matters isn’t absolute probability, but relative evaluation of situations: How many “outs” do I have? What’s my equity? How does my winning chance change if others fold?

🃏 Starting hands: Don’t calculate dynamically

A common mistake: evaluating each starting hand (e.g., 7♠ 2♦ or A♣ K♠) dynamically in code. That’s inefficient and unnecessary.

Better: a fixed table with pre-calculated hand values – based on position, number of players, and tournament phase. Example:

• A♠ K♠ in early position = strong
• 9♣ 8♣ in late position = playable
• 7♦ 2♣ = almost always fold

These tables are based on millions of simulations and are far more reliable than spontaneous calculations.

📍 Position and timing: The underrated factor

Your seat at the table often matters more than your cards:

• Early position players must act first – with no info
• Late position players see how others act – and can respond better

Example: In 6-handed games, each player starts with a theoretical win chance of 16.67% – but that changes with every action.

A common mistake: calculating probabilities independently of table dynamics. But what really matters is whether someone raised before you, whether you’re in the big blind, or whether you’re short-stacked.

💡 Bluffing, outs, and risk – modeled correctly

A bluff isn’t “gambling” – it’s a calculated decision based on opponent behavior, table image, and stack sizes. If I bluff and lose, I only lose what my opponent could have bet – the risk is limited.

Correctly calculating outs:

Example: I have a flush draw with 9 outs Two cards still to come → win chance ≈ 35% Formula: 1 – ((38/47) * (37/46)) ≈ 0.35

These calculations are far more useful than global odds like “Royal Flush = 0.003%” – because those don’t help in actual gameplay.

🧠 Conclusion: Poker is calculation – but not brute force

The art isn’t in calculating every possibility, but in recognizing the relevant ones. Position, stack size, opponent behavior, and tournament phase matter more than pure card combinations.

What Torsten built is impressive – but data types and SQL alone aren’t enough. I especially admire his love for algorithms and his bold spirit of experimentation.

Starting hands should be evaluated via tables, probabilities should be context-aware, and decisions should adapt dynamically.

And yes: the dealer button moves on. Probabilities shift. The game starts anew – but the strategy remains.

🎮 Grab the T-SQL code and try playing poker on SQL Server yourself!

Disclaimer

This article was created based on my personal notes with support from Microsoft Copilot. While Copilot assisted in structuring and refining the content, all technical details have been carefully reviewed and developed by me. All credit for the session goes to Torsten Ahlemeyer.