I wouldn't want to use the MySQL database open to public (port 3306 public available).. By default, MySQL database server remote access disabled for security reasons.
You can set up trusted hosts if you know which computers that are going to login to your database....
Maybe consider using a VPN to get encryption on that connection.
But.... I would probably use PHP to script server side and then PB for client side.... Or PB server side and PB client side... That way you can get more specific functions and just get the data you need over the connection instead of much much more then you need.
I simply installed a mySQL ODBC driver on the computers that would access the online database then used standard PB database commands to connect and manipulate data.
The ODBC driver is where you would enter the web address, database name, port, etc.
They are console server applications that can take procedure calls (I did a large stint on xml-rpc a long time ago) which the servitors do the magic of talking between my app and the sql database - sometimes it's just a sql query list, othertimes, I have to do some massaging of data in both directions before client and sql understand each other.
The beauty of servitors, is that they do all the hard work - so actual work done by the sql database is very minimal, and as I can simply scale up the servitors to use multiple machines or multiple ports on the same machine, and the client randomly chooses a servitor to connect to. This has a *major* benefit that many people don't realize:
At work, we use .net, but we've implemented this strategy. Now I've give you the picture:
23 Sites nationwide - equates to approximately 400 computer users.
1500 Customer clients - customers key in, file import, and edit and manage their own data, all day, every day.
150 vehicle trackers, pinging away the gps location every second, plus photo & signature capture on deliveries & attempted deliveries
Okay, so that's a lot of data - but it's all being routed through our servitors - there is nothing with a direct connection the database.
Here's the key: 1 server (1.7ghz, 2 dual core cpu, 8gb ram - it's been running since 2004) hosting SQL Server 2000.
Same server is hosting 10 servitors all on different ports.
The total average concurrent database connections: 35
The maximum concurrent database connections: 63
And here's the killer fact: Average server CPU load: 5%
We can attribute this due to the fact that the servitors are offloading the work from the sql database doing all the hard work, and just doing simple data transformations in the servitors. Sql databases were designed for searching and retrieving data. Programs were designed for data manipulations.
Now, to contrast that to when we used websites that had direct connections to the database and a measly 500 users - 500 connections to a database that was spread across 3 servers, with an average cpu load of 85%.
And if a programmer forgot to close a database connection on a highly used bit of code? Within 30 minutes everything would crash as there is a limit of 750 concurrent db connections in SQL Server 2000.
Thanks Foz!
See I readin Game INformer about the new Diablo 3 release and how it is going to be essentially a CLOUD game... All data and characters stored on Blizzard Servers etc. Obviously this has been a large part of the delay in its release.
But I wondered about that... In my game engine we use a MySQL DB to hold the graphics and a second DB to hold the level in a formatted string.
So if I CLOUD it... the graphics could be held in the users computer and updated ONLY if version check said to update. And the actual game data AKA your character and level strig could be stored server side and flushed out to the user as needed. That should prevent undue manipulation and make sure that only registered users get to play. Microtransactions could also happen and for small payments better equipment or small side quests
How about creating a CGI server running on Apache that access the MySQL database and use Json or XML-RPC to comunicate the client application with the CGI server, I have done a similar application with Rails-Flex and works quite well. I dont know what TCP/IP ports use ODBC but http is standard on port 80 and most proxy and firewall permits this kind of traffic