> JDBC is designed to be used on devices with lots of RAM, lots of CPU > speed, comparatively unlimited storage space for application code, > full-time AC power, to connect to local databases and database servers. > JDBC drivers are often/usually used with remote databases (this is the simplest meaning of 'n' tier).
> > Why would you not want to interface the built-in SQLite engine > > through JDBC? > By Java API standards the JDBC API is pretty compact and some of the drivers are very small. But then you need a different driver for each database and the drivers would be duplicated in every application unless they were built into the platform (which databases would you vote to exclude?). JDBC by itself has verbose syntax. It require knowledge of SQL and is not object oriented which has lead to a plethora of ORM's like Hibernate and more recently to standard JPA (OpenJPA). All those drivers and all those ORM's would be a blot of cement on an Android platform. So for the intended use it seems like SQLite is a pretty good alternative. -- 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
