Why Poker Copilot Doesn’t Use MySQL…
Loyal customer KeithX asks:
Why doesn’t Poker Copilot use MySQL or (shudder) Postgres?
There’s two main reasons:
- User Experience
- Speed
User Experience
Consider iTunes. iTunes is, fundamentally, a database with lots of data. The data is in the form of thousands of files that encode sound frequencies. In my case, iTunes has 13 Gigabytes of music in 2517 files. Plus 920 Megabytes of podcasts. Plus 14 Gigabytes of TV shows.
iPhoto is, fundamentally, also a database. This time the data is in thousands of files encoding photos.
In neither iTunes nor iPhoto is the end user expected to first install an SQL relational database system. The database is hidden from the user and managed so that the user simply sees what’s important.
I aim for Poker Copilot to have the same seamless experience one finds in iTunes and iPhoto. The complicated database management is hidden from the user.
Speed
Using an embedded database engine – which Poker Copilot does – has the potential for greater speed than a separate database server like MySQL or PostgreSQL. To get all technical, communication between a piece of software and a database server involves (in common scenarios) creating a TCP socket connection, encoding the query in a standardised manner, sending the query over the socket, retrieving the results over the socket, decoding the results, and disconnecting. Often the overhead of connecting and communicating is the most time-consuming part of the process. (There are ways to speed things up somewhat, such as connection-pooling and client-side query caching.)
An embedded database engine, if engineered for speed, can operate faster.
Poker Copilot uses a Java-based embedded database engine called H2. It is open source, offers high performance, and uses SQL. It can be configured to offer high concurrency.