Help retrieving/sending data to/from a server on iOS (C#, Mono, .Net)

Question

I'm sorry in advance if this is a silly question.

I'm currently working on getting something running where I can grab information from a server. My goal is to make the data I'm retrieving (or sending, for that matter) as small as possible -- both for speed and bandwidth.

To make matters more complicated, I'll be needing two sets of data:

Global: Something that doesn't house a lot of data, but needs to be synced every time. (News, status, etc.)

Personal: The user's data. (Points, scores, etc.) This isn't a lot of data either, but I thought that a database would be ideal for this. Doesn't this then mean that I'd have to retrieve the whole database, and then filter it? (i.e. transmitting too much data)

The server would be as small as possible (for cost), so it should only house data, and not do any (or almost any) of the work itself, so it would essentially just be storing the files.

Is a database the best way to go about this? Should I use two databases (global, personal)?

Would SQL be best for this? Or could I use REST and just grab the data I need (not the whole file)?

---

I'm sorry if this seems like a lot. I've been googling for a few days now, and I'm unsure of what I should do. If this is unclear, please say so and I'll try to clear things up. If it's too broad, I will narrow it down more.

---

EDIT: Thanks for the answers thus far, but they aren't quite what I'm looking for. So, I'll go into more detail.

I'm thinking of using Amazon for the server, mainly because it's pay-as-you-need and scalable. Furthermore, I've found this article which is specific to MonoTouch, but I'm still not sure what's easiest. I will not have a ton of data, so if I can grab either a small file, or query a database, that would be great. I'm all for using third-party libraries, if it's possible, but mainly I'm not sure how I should do what I want to do.

Sorry for being so thick. Obviously I can understand it better with example code, but it's not a requirement for an answer. (And I want to make it explicitly clear that I'm not asking for hand-outs.)

Answer 1

Higher-level protocol - design around your functional requirements. Think about what data the client will need to have, to show the user what he's expecting to. If your tababase is small, and your user is able to set up different filters to query the data - then "retrieve the whole database, and then filter it" will work OK. If however your DB is large and/or user only [typically] need a small subset of your DB - then client is better to ask your server for the filtered dataset.

Lower-level transport protocol - based on your requirements, I'd choose between Microsoft's NET.TCP binary XML (if you're ready to run your server on Windows which is not free) and Google's protocol buffer (GPB) atop of either TCP (if you need callbacks from server) or HTTP (of you don't need callbacks). IMO, GPB is a bit easier to code on client, harder on server.

SQL vs NoSQL vs plain file storage - the answer mostly depends on your data access patterns. Client needs complex queries, especially with joins? Use an RDBMS for sure. Only need to download/upload blobs? Use NoSQL or just file system. Expect complex concurrency problems with multiple users competing to update a single record? Only consider RDBMS or carefully chosen NoSQL that is OK with that (e.g. ESENT if your server is on Windows).

Answer 2

Short answer: You can setup a cheap Linux box, setup MySQL, setup the database schema, populate your tables, and write the code to connect and query the data however you see fit.

Long answer: Depending on how you want to expose that data, you could set up web services (SOAP/REST) with various endpoints on a web server (which would in turn connect to the database). You could also simply connect directly to the database from your client and bypass the whole web services setup. It's really dependent on what your use case is.

Both the "global" and "personal" data can be stored in a database like MySQL on a Linux box for little cost. I wouldn't split them into separate databases unless that's a customer requirement. Even then, I would question it. The reason is because you never know when you might want to tie in the "global" data with the "personal" data. For example, what if you want to let the user customize a news feed so that the global "news" can be tied to a specific "user"?