I am planning to write an iPhone app and I am weighing in the options to either make the database local (on the device) or host on my server and access it through web services. What are the advantages/disadvantages of these two different approaches?
advantages of a local database
alwayws avaliable (also with no networkconnection)
fast because you don't need a networkconnection
secure because the data won't fly over the net
disadvantages of a local database
remotely change values (you cant change uservalues)
no statistical overview
Related
We have SAAS multitenant Web Application for hotel reservation and Key issuing, that can work both in Online and Offline modes.
The user needs limited features like making the reservation and issuing keys for Guest through the webapp, in case he is offline and full feature access when he becomes online again. I thought of the following options:
Make the hotel host a server locally that will replicate event from the cloud database to the local
Create a light version of limited feature of the App to host locally with the replicate Database
Create a shortcut URL to local computer but Only allow access to the local web app when Internet connection down
Save all message(CRUD from feature table) to a Queue in the local server(Linux box)
When internet is back, send these to the cloud for data Sync
This seems like a good solution since it is cover the scenario and it integrates a local server, relational datastore and a queuing messages to send to cloud
Very easy solution when it come to mobile , but since this is a web, we seems to be limited by available technics.
Has anyone worked/working on such an application. Ideas welcome.
I am going to build an in-house application within a company. I was told that the data sample is located on the DMZ network, so how can I connect to this? The main task is going to surface data and display it. I have no idea about DMZ network and is there sort of API available to achieve this?
There is not any API for direct connection to Database(as per my knowledge)
create a local web-service, which will accessible only in DMZ network.
User those web-methods to communicate with database.
As the access of web-service is within DMZ, user will have access of data within DMZ network
My app reads data from two sources, a local sqlite file and a remote server which is a clone of the local db but with lots of pictures. I do not write to the server database, but I do need multiple simultaneous fetch operations.
What DBMS should I use for storing information on the server?
It needs to be very easily used from an iPhone app, be reliable, etc.
Talking to a remote server should not be tied to any platform like iOS. If you have control over the remote db server, the best bet IMO is crafting a RESTful API which you express your queries in, the server processes it and sends you the pictures/records using proper content type. If you do NOT have such control over the remote db, you'll have to stick to the API the db hoster provides. There are plenty such "on the cloud" db hosters (including NoSQL solutions) that give you a web-services interface to your db. MongoLabs is one such provider for MongoDB(which is a NOSQL db - meaning no schemas, no bounds on the structure of a "table"). You can continue to stick to SQLite on the client side.
You seem to have two sources of data local storage and a remote server.
This question on SO might help you to decide approaches of storing data on the server.
Once you have downloaded data using something like NSURLConnection class the images could be stored in the filesystem using writeToFile or the likes.
- (BOOL)writeToFile:(NSString *)path atomically:(BOOL)flag method.
You might like to save the rest of the data in sqlite. We used sqlite and the CoreData framework to save data for one of our applications and it worked fine for us. CoreData allowed us to interact with the database without actual SQL queries.
The iPhone client resides on the phone while on the server side we might have a database and a webservice interacting with the db. Webservice itself might be implemented in python or php like scripting language. The client interacts with the webservice that might return data in formats like XML or JSON. Thus there is no direct communication between the client and db. However, the client does implement network communication code to communicate with the webservice.
This page shows how to consume an XML based web service.
For putting together a site from scratch, what are the advantages and disadvantages of using external database services, e.g. MongoHQ, Amazon RDS?
Advantage: you don't have to fix it yourself when it breaks.
Disadvantage: you can't fix it yourself when it breaks.
My take on this is simple:
If you have an application hosted on Amazon then you should go for Amazon RDS or MongoHQ(which also is hosted on Amazon). The rational is, since both your application and the database are on the same network (internally) you will get a significant performance advantage.
If your application is hosted else-where then go for a local install.
a couple more points
for
do not have to administer the Hardware
I guess they take care of security, software updates of the server (Software admin)
saves room. you do not have to find room in your building for a database cluster
disadvantages
depending on your internet speed, the speed you transfer data can be affected. if the application and data are in the same network you could say that you have 1gbit speed vs a 50mbit internet connection. times this by 1000 concurrent users?
you have to work to their release schedule. if you use a 3rd party and they update the database version which has a breaking change. You will be forced you update. if you host it yourself this upgrade will be under your terms.
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.
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.
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.
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.
What I am doing is creating a web service using Sinatra to access the online database.
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 a while 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.