For example, select sum(timesseen)įetch the total times you’ve played real money ring games select sum(timesseen)įetch your vpip percentange in real money tournaments since September 1st, 2009 select sum(vpip)*100/sum(timesseen)įetch your vpip percentange with decimal points in real money tournaments since September 1st, 2009 select sum(vpip)*100.0/sum(timesseen) This will cause the database to use a good index. Include in your where clause at a minimum dayid, ishero, istournament, and isplaymoney. This allows much faster querying than with regular date types.

Instead of date/time/timestamp fields, Poker Copilot often uses a integer field called dayid. Use this if you need a finer granularity than day. This contains ungrouped data, one row per player per hand. There is a secondary fact table called gameplayersummary. You should use this table most of the time. This contains data grouped by day, as well as several other key criteria: playerid, isplaymoney, tablesize, gametypeid, positionid, stakelevelid, and tournamentid. You’ll mostly use one table with redundant data, the so-called “Fact Table” in data warehouse terminology. Queries will seldom join more than two tables together. It follows loosely the concept of a data warehouse, optimised for ad-hoc queries that “roll up” data. Poker Copilot’s database schema is heavily de-normalised. If you perform updates, inserts, or deletes, you may upset Poker Copilot. If you are comfortable using SQL, here’s some helpful info.

Using poker copilot