iOS & Databases

If your database is going to be small enough and not have a lot of people writing to it concurrently, you may find just throwing a database on Dropbox is adequate. It probably violates their TOS, but oh well.

 

Been looking at Dropbox datastore API for a project as well. There is also ParcelKit open source project as well which wraps that API to work as a backing store for core data which might be of interest to you.

There seems to be few of the of Cloud Stores that now have database API's that work with iOS now. Although if your only talking 2 even 3 dedicated devices and only one to start with then why not bog standard core data to start with, then work out the best way to handle multiple devices later.

 

Time keeping. You have some SERIOUS legal requirements to consider.

Don't modify a DBMS in real time. What you are going to have to do is keep a LOG FILE the maintains a list of all the sign-in sign-out events and keeps some kind of PROOF that it was the employee who did it and also some kind of proof that the log file is not tampered with. You can use checksums to show non tempering and as for proof of the right person the web cam seems like an ideal solution.

If some one disputes their pay you are going to have to prove your case.

A SQL DBS is a dynamic thing. Even a table holding "events" with times is not a log file. Because at any time records of events can be inverted or removed.

I think you want the iPad to be a simple terminal that send events over an encrypted link to a sever machine. You could have any number of iPads.

Have the iPad(s) send the event (and wait for a reply) but also keep a log locally. If you use a DMBS at all that is all on the server side.

Be sure to keep a mirror of the data and logs in real time off site

It's hard to believe that you need to write this yourself. Sounds like re-inventing the wheel.

 

Just wondering if you have a more "ready made" solution. I'm considering a project (not time based) like this.

 

I can't see how Dropbox would be appropriate here unless there is going to be one DB per person which is then integrated into a master DB. My understanding of Dropbox and services like it is that it allows transfers of files. This isn't appropriate for a multiuser DB.

 

As I said, if users aren't going to be writing to it concurrently, it should be adequate. The main reason I suggested it is it costs nothing and is very easy to set up. Google Drive would be another possibility, although Google halfasses everything they do so I'd be surprised if their APIs are anywhere near as good as Dropbox's.

 

Well, that isn't exactly what you said; "not have a lot of people writing to it concurrently". The highlight suggests more than one concurrent users. You can't do multi user writes to a file and expect good results.

The real point is for the OP. If multiple users are likely to try to update the DB at the same time, then a proper multi user DB setup is required.

 

Forget about dropbox.

There are a number of commercial cloud database providers that have REST APIs that can be used from iOS and which can be free for small databases.

Look at parse.com, mongolabs.com, and others.

 

My suggestion would be to build or find a server-side script that accepts POST requests from authenticated devices. Then create an Objective-C class with methods to send each request out. Do make sure that file is signed with a certificate or has a checksum.

Also, you might consider creating a local file.