Thanks for reminding me, need to whip out the C64 for this game alone. Who made it? Firebird? Never got the hang of docking, but my first ship upgrade was always a docking computer, if nothing else than the graphics and listening to the Blue Danube? waltz while kicking back w/ a Mountain Dew.
Unfortunately, this probably is not feasable outside at the JDBC, ODBC, DBD level for a database cluster that handles reads and writes simultaneously. Imagine for example you have a DBD interface that behaves similarly to the C-JDBC tool and they are both writing at the same time to the same table on a cluster of DBs. Because the two access methods do not know anything about each other, there can be no garuantee that writes occur in the same order across al databases in the cluster. Auto-increment columns become worse than useless. Updates are even worse.
What somebody really needs to do is strip away all parts of the database server excepth that which recieves client requests. This code could then be modified to forward those requests on to a cluster of normally functioning servers. The benefit here is client side code for all languages remains the same. Any application that can connect to the original database server can also connect to this proxy app. The hard part is setting up load balancing, fail-over, etc. Fortunately, the code to do this is available in java. A developer savy in both java and the native language used by the database software developers could probably easily accomplish this.
Slashdot Mirror
And then get in line behind these guys, who have evidently seen this coming for a while.
Taxware
mySQL definitely has its issues, but issues related to row count haven't surfaced for me.
mysql> select count(*) from tblLog;
+-----------+
| count(*) |
+-----------+
| 195336556 |
+-----------+
1 row in set (0.00 sec)
Thanks for reminding me, need to whip out the C64 for this game alone. Who made it? Firebird? Never got the hang of docking, but my first ship upgrade was always a docking computer, if nothing else than the graphics and listening to the Blue Danube? waltz while kicking back w/ a Mountain Dew.
Unfortunately, this probably is not feasable outside at the JDBC, ODBC, DBD level for a database cluster that handles reads and writes simultaneously. Imagine for example you have a DBD interface that behaves similarly to the C-JDBC tool and they are both writing at the same time to the same table on a cluster of DBs. Because the two access methods do not know anything about each other, there can be no garuantee that writes occur in the same order across al databases in the cluster. Auto-increment columns become worse than useless. Updates are even worse.
What somebody really needs to do is strip away all parts of the database server excepth that which recieves client requests. This code could then be modified to forward those requests on to a cluster of normally functioning servers. The benefit here is client side code for all languages remains the same. Any application that can connect to the original database server can also connect to this proxy app. The hard part is setting up load balancing, fail-over, etc. Fortunately, the code to do this is available in java. A developer savy in both java and the native language used by the database software developers could probably easily accomplish this.