Brion gave some good suggestions, so let me address this from a more architectural standpoint.
You don't WANT to access the tables direction. A web service acts as an intermediary -- it sits between your application and the database. This allows more control over how the application can access the information. You can limit the application to change only certain fields, or apply different security models. It also allows you to CHANGE your database. For example, to split a table into two linked tables to achieve better normalization. If the application could access the database directly, the SQL queries would need to change (especially for updates). You would face an impossible situation, as you simply cannot force people to upgrade their applications. This is perhaps the biggest reason why web services are so popular, and direct database connections are almost never used in end-user applications these days. It also allows better performance -- through caching, connection pooling, and other techniques. Database servers are simply not designed for huge numbers of connections. A web service has direct connections to the database. It has as much access to the tables as it needs. It's up to the web service what that data looks like to the client application, and how much access the client has. It can certainly present a model that parallels the database schema. With a RESTful interfaice, you could have URIs that denote tables, returning a list of URIs denoting primary keys in the table, and those URIs in turn would return the content of the rows, etc. But usually it makes more sense to operate at a somewhat higher level, where the URIs in the interface denote domain entities. For example, a music service might have URIs that denote albums, composers, artists, tracks, etc. Or, more likely, it would not have 'tracks' at all, and asking for an album would return EVERYTHING about the album that the application might need, because you can do that in a single step, without repeatedly asking the server. This allows much better scaling, and much better performance and reliability in the application, than asking for the same information one piece at a time. This is yet another example of why you want a web service, rather than accessing things at the database level. On a phone in particular, there is a lot of latency. Each time you ask a question, you have to wait for the information to flow both ways, and all those delays add up. The web service has very fast connection to the database, and can do all that quickly, so you only need to ask ONE question, and get a faster answer. When designing a web service, it is entirely up to you what form the data comes back in. You can construct whatever JSON or XML objects that are convenient representations for the data the service provides or uses. Whether you use JSONObject or an XML parser is up to you. > From: uday kiran <uday.pic...@gmail.com> > Date: Mar 22, 8:15 am > Subject: Accessing External Database > To: Android Developers > > > So, if we r using RESTful webservice is it possible to access the > Tables present in the database??? > and doing some operations on the database i.e) Adding/Deleting a row/ > column into the database table?? > > I saw one example which uses JSON Object for getting the stream.. > So if i want to access databases which class we need to use?? > > If u have any related code regarding this please let me know... > > Expecting more information regarding example code... > > Thanks in advance > > --Cheers > Uday Kiran Pichika -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe from this group, send email to android-developers+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
