PokerTracker: The Next Generation (NEW SOFTWARE DISCUSSION)

[DMoogle]

[ QUOTE ]
[ QUOTE ]
please dont integrate 3-betting and 4-betting into this.

[/ QUOTE ]

I'm probably being leveled but it will be in there. If you dont want it you dont have to have it. <Subtle hint>

[/ QUOTE ]
Never knew that was there. Unfortunately there isn't support for FTP yet. I guess this is because the notes aren't saved in a simple format. However, I know they can be found in the [username].dat file in the FTP folder. I wonder if some of the code can be deciphered so that it would be able to be imported?

[Shoe Lace]

[ QUOTE ]
Postgres is known as feature rich database but it isnt the fastest db in the world.

[/ QUOTE ]

For complicated queries postgre is one of the best free db engines out there. For non-complicated, quick and to the point queries it slacks pretty bad though -- mysql will tear it apart in most cases.

Perhaps PT v3 could be designed with db simplicity in mind, and move over to mysql?

[_dave_]

[ QUOTE ]

Perhaps PT v3 could be designed with db simplicity in mind, and move over to mysql?

[/ QUOTE ]

MySQL... you jopke surely???

It is at least a sensible option compared to the suggestion of MS SQL Express with the 2GB RAM / 1 CPU restrictions [img]/images/graemlins/smile.gif[/img]

Without loading up on MsSQL Vs. PGSQL flamewar ammunition lol, MySQL is out because of weirdo licensing conditions... PT can not link against mysql without becoming GPL, unless fork out silly $$$$$ to license MySQL AB or something like that - I can't remember a great deal from the old PT forum threads.

Besides, I'm fairly sure RVG just demonstrated PGSQL can be plenty fast enough for a tracker app once the SQL is wrapped in transactions etc. - I still stand by my earlier statement that PT's database speed problems stem from the MS Access default / going through ODBC - I believe vast performance increases could be achieved if that was dropped for version 3, alternatively totally seperate code used to read/write different DB engines.

Would be very interesting if PT & PA-HUD abstracted the DB layer somehow (PERL maybe?), thus allowing the user to implement almost any DB backend... then we could see some seriously interesting DB performance comparisons etc.

Very much looking forward to a new generation of apps [img]/images/graemlins/smile.gif[/img]

dave.

[Shoe Lace]

[ QUOTE ]
PT's database speed problems stem from the MS Access default / going through ODBC - I believe vast performance increases could be achieved if that was dropped for version 3

[/ QUOTE ]

Yeah. I have a DB with nearly 30k hands (I know, not very many). Originally it was access. Speed wise, I had no complaints. It was fast enough that it wasn't annoying.

But I switched over to postgre because I wanted to fiddle with HM. After converting my PT db to postgre it was like a totally different app speed wise (for the better).

I won't get into any flamewars, don't worry. [img]/images/graemlins/laugh.gif[/img]

I never looked into mysql licenses since most of the work I do with it is hosted on web hosting services or personal local use.

I do recall an article not too long ago that showed mysql really doing well with simple queries compared to many others.

Btw please never mention the word Perl again when talking about implementing it as a middle man.

[matt42s]

[ QUOTE ]
For non-complicated, quick and to the point queries it slacks pretty bad though -- mysql will tear it apart in most cases.
Perhaps PT v3 could be designed with db simplicity in mind, and move over to mysql?

[/ QUOTE ]

You say most cases, but it would be very difficult, if not impossible to write an application such as PT using non-complicated queries. Subqueries and joins are required for nearly every useful operation and mysql falls over pretty quickly in those circumstances.
The licensing isn't a trivial problem, either open the source to PT, pay $600 per server per year or run the risk of a court battle.

[matt42s]

[ QUOTE ]
PT's database speed problems stem from the MS Access default / going through ODBC

[/ QUOTE ]
It stems from Pat knowing little about databases when he wrote PT.
[ QUOTE ]
Btw please never mention the word Perl again when talking about implementing it as a middle man.

[/ QUOTE ]
I though you would have known this dave.

[APerfect10]

[ QUOTE ]
[ QUOTE ]
Postgres is known as feature rich database but it isnt the fastest db in the world.

[/ QUOTE ]

For complicated queries postgres is one of the best free db engines out there. For non-complicated, quick and to the point queries it slacks pretty bad though -- mysql will tear it apart in most cases.

Perhaps PT v3 could be designed with db simplicity in mind, and move over to mysql?

[/ QUOTE ]

You basically repeated what I said. Postgres is feature rich and can do a ton more but it isnt the fastest.

Sorry, MySQL is not an option. For two reasons:

1. As dave pointed out, their licensing will not work.
2. I believe Postgres is far superior to MySQL and I have a ton of experience with both. I prefer MySQL for web backend but thats about it. For a stand alone app, with the database the size of a potential poker database, Postgres is by far the better choice.

Access will also not be a part of PT3. I also believe that MSSQL will not be an option because we want PT3 to be portable. We have something up our sleeves =)

[APerfect10]

Why all the perl bashing? Perl still has its place...

[HighSteaks]

I datamine a fair few hands and use the "don't store the actual hand history option". It would be nice for users who use this option to be able to "trim" their observed hand db. For example, you could have an option along the lines of "delete all observed hand statistics for any one player over and above 2000 hands. This would insure that the stats on all players are recent and allow a far more complete db overall.

[aislephive]

[ QUOTE ]
I datamine a fair few hands and use the "don't store the actual hand history option". It would be nice for users who use this option to be able to "trim" their observed hand db. For example, you could have an option along the lines of "delete all observed hand statistics for any one player over and above 2000 hands. This would insure that the stats on all players are recent and allow a far more complete db overall.

[/ QUOTE ]

The problem with this though is that individual hands affect everybody who was at the table. Say you have player x with 2k hands and you only want to keep the most recent 2k hands. If somebody at the table has less than 2k hands do you delete their hands as well? I might be missing something but I thought that was the reason why you can't do that currently with PT.