iPhone: Connecting to database over Internet ?

Question

I've been talking with someone about the possibility of a iPhone development contract gig. All I really know at this point is that there is a company that wants to make an iPhone app that will hit their internal database. I'm not sure what the database type is( Oracle, MySQL, etc...).

I've wanted to know if the database type was Oracle or MySQL if there is a big learning curve for connecting to one of these across the internet?

If it's a real pain I may do more research before accepting the conract.

Answer 1

You can easily perform the connection over the internet, the same way you would locally, but you are opening the database up to attacks if it will accept communication from any remote IP address. Typically you will just connect via a socket open to the server's remote IP address over the open port, MySQL's default port is 3306.

I would recommend against this sort of system in general unless there is some critical reason they want their internal database exposed to the world's hacker community.

Answer 2

I would advise against directly accessing the database from the iPhone application.

Usually, you would create a web service which accesses the database, and then you consume that web service from the iPhone application.

Answer 3

What I am doing is creating a web service using Sinatra to access the online database.

Answer 4

Create a web service. This allows you to make the iphone app more of a thin client. Let the application push commands to the web service for processing and interaction with the database returning only the data needed by the app.

This option is better for the app, the database, and the customer's security.

Answer 5

Those answers from 2009 are mostly obsolete now.

http://ODBCrouter.com/ipad (new) has XCode client-side ODBC libraries, header files and multi-threaded Objective C objects that let your apps send SQL to server-side ODBC drivers and get back binary results! This reduces the need to stop and separately maintain SOAP/REST servers that can get pretty frightening anyway after you have a large number of live users. The ODBCrouter stuff is not free, but it is always cheaper than the cost of building SOAP/REST services and the matching Cocoa Touch glue, little known maintaining it.

The XML schemes were okay for transferring static configurations to mobile devices "every once in a while", but XML was meant for infrequent inter-company type transfers in a "server environment" (with power cords, wired networks and air conditioning) and is definitely not efficient for frequent database queries coming in from n-copies of a mobile app. There are third-party JSON libraries that help things, but even with JSON, everything has to be encoded (and decoded) from the binary representation in the database to text representation on the server (only fine if it's going to be shown to the user in a web browser anyway, but not fine if the mobile app is going to translate it right back into binary so that it can perform calculations "behind the scenes" to what is going on with the user). Aside from the higher network overhead and battery power the mobile CPU will draw with XML and JSON, it will also make you buy more RAM and CPU power on the back-end server faster than just using an ODBC connection to the database. That said, always make sure your queries are efficient (try to only call stored procedures instead of running ad-hoc queries and only select columns you need, avoid wildcards or asking for large numbers of rows all at once). The new multi-threaded Objective C objects in the ODBC SDK are kind of cool though in that they won't block your App when ODBC queries or transfers are taking place (all of the threading glue is done for you) and they'll even kick-off "waiting spinners", if you let them, whenever those queries or transfers exceed some predefined amount of time --defaults to 1.5 seconds or so.