![]() |
|
#61
|
|||
|
|||
|
[ QUOTE ]
Honestly, my BS detector went DING DING DING after a few posts of OPs in Microlimits and there are a few hints in this thread that do the same. Feel free to read previous posts such as his first post and make up your own mind. quote] Have you actually looked at what the AAAI Computer Poker Competition is? |
|
#62
|
|||
|
|||
|
[ QUOTE ]
As for my points of a centralized DB I still sitck by them. If everyone wants it local it can be done but its just not the best solution. [/ QUOTE ] JT, you are 100% wrong in your valuation of a centralized DB vs a local one. Centralized DBs are good in situations where there is far less writing than reading, but a hand tracker will have ALOT of writing going on all the time, by most users. Network traffic to the DB would be a bottleneck, and there would be so many hands in the database that even the simplest queries would run painfully slow. Indexes only help so long as the index is small enough to fit in and out of RAM as needed - once you get over 2 million rows it is likely your server wouldn't be able to fit it's incexes in ram, and query execution slows considerably... |
|
#63
|
|||
|
|||
|
JT, you have seemed very willing to listen to everyones different suggestion and asking people to give more information about issues they have mentioned. Why do you feel the location of the DB as being a non-negotiable issue, despite many others listing valid reasons and counter-arguments against your position?
|
|
#64
|
|||
|
|||
|
I have never said its no negotiable if you look I said that if thats what everyone wants that I would do it. I just don't agree with some of the reasons that people have given. My job is working with Databases and network traffic between them I currently works on DB's that have millions of records and houndred thousands of transactions back and forth to it each day. What I asked for was suggestions about what people wanted not the architecture of how the application should be designed. I can understand the reason for local database because of issues with poker sites not wanting a centralized db. So lets not focus on that anymore a local DB will be fine. Lets focus on the features that people want to see. If someone wants to discuss application architecture they can contact me through PM or I can create another post for questions regarding that.
|
|
#65
|
|||
|
|||
|
Jt, maybe I overreacted with the tone of my previous post and whilst I am still sceptical and puzzled/baffled by some of your stat posts it could be that I just don’t understand your background or your motivations for wanting to take on such a mammoth project at this point in time. So I what I’ll do will wish you luck with this tool because I do you think youll need it – I think anyone would need luck and an incredible amount of motivation in coming up with the next pokertracker/pokeroffice utility.
so, you have the ball...go ahead and prove all the sceptics like me wrong, mkay. Btw yes, I read that post about AAAI and even googled them. I think there is a slippery slope between writing a bot for a academic purposes and using bots to play real money poker. |
|
#66
|
|||
|
|||
|
Thank you for the repost AussieBattler. Just a bit of background for you of why I am doing this. I am a programmer by profession. I started using PokerTracker and saw that it could be improved and that it would be a good project to work on. As you mentioned you were baffled by my stats quetions. I have never said that I am a pro at the poker stats and that is why I have asked questions.
BTW should have screen prints or demo video here soon. |
|
#67
|
|||
|
|||
|
one other thought to me that definitively settles the local or central server issue.
since, in order to not get banned by the site, you would have to limit a persons ability to view stats to only those he played in, it would make the product worth very little to those who have vastly more information in their own databases than just hands that they play in. in other words, those who have large amounts of mined hands on their local machine, would have to give up that information for any application(s) your program would provide via a central server that limits them to played hands only being usable. |
|
#68
|
|||
|
|||
|
a single hand import could require as many as 20 writes per player. so up to 200 writes for a single hand. what happens when you have 5000 users each playing 2000 hands per day? that's a lot of writes per day.
even leveraging stored procedures for virtually everything you can, reads are going to be a couple orders of magnitude higher. if you have any sql/oracle experience whatsoever, you should realize how insane a central database is for this project. |
|
#69
|
|||
|
|||
|
I have already said I will do a local database. If you still want to dicuss this please PM me. Lets keep this thread for actually functionality that you would like to see.
|
|
#70
|
|||
|
|||
|
Screen prints have been posted
http://forumserver.twoplustwo.com/showfl...c=1#Post9017277 |
![]() |
|
|